Fusion Lifecycle Features you aren't using - but should be

BRIAN SCHANEN: All right. I think that's it. They've sealed the door. All right. You're stuck, we're stuck together. All right, so welcome everybody. That is loud. Maybe I'll tone it back a bit. Everybody hear me well in the back of the room? All right.

These slides, these commercial slides that we have running, take pictures. They're just meant to let you know what's coming up. Where we're going to be. Answer by our quick bio on everything. So if we need to run these again at the end, if you want to take a picture of the next class or anything that's on here, just let us know. But I think it's time to start with, start with the class. And here we are.

So my name is Brian Schanen. I've been with Autodesk a long time. Since the before time, since 2005. Before that I actually worked at a reseller for seven years. And in my tenure here I've always done data management. Actually I joined Autodesk just to do Vault and product stream at the time. PLM came along, and I turned my sights to that, although I still do love Vault. And who doesn't, right?

But I've been here, and I've been teaching at AU since 2000. I've been doing something. It's always in the realm of data management with maybe a secondary, like Inventor or something like that.

With me is Ms. Michelle Stone. Michelle Stone, I'll let you introduce yourself.

MICHELLE STONE: OK, I haven't been at Autodesk as long as Brian. Actually interviewed for the job at AU 2011 when they launched the PLM product. Actually went on Craigslist looking for another job in PLM, and like why is Autodesk popping up? Came kind of old school, PLM, client servers. So I've been working in the industry since the late '90s, PDM, PLM.

And I said, oh, they're going to this new solution. So I was intrigued, and I talked to them. And well, here, I am. I've been on the product team for about five years now, and I'm really excited to share some of the features in the product that you guys may not know about. I know, I recognize a lot of you guys. You may have been administrators working with the product for a while. So this is a great chance to give you more information.

BRIAN SCHANEN: So the class is called, features you're not using but you should be. And I thought I'd get a catchy title out there. Now we have, if you take a look at the handout, all right. There the handout. Thank you, Michelle, for the handout, by the way. I was-- we're professional procrastinators, so the handout was, it was uploaded, I think, yesterday or the day before.

Long, lengthy handout. The slides that I uploaded. There's over 100 slides. Now, I know the rule with slides. I know that. If you sat through long presentations. I cut that way down. The good news is, the presentation we have here, I have a lot of stuff removed. But the slides are yours. All right, so if you are an administrator, if you're a prospect, if you're a customer, if you're a reseller, if you're an independent consultant, use these.

And actually, let's go over to-- the whole idea of this class is meant to give you some tidbits. Over the years, as a product manager, as a customer success engineer, and as somebody who is outward facing to customers and to resellers, I pick up on tidbits. In fact, Michelle Stone, part of the street team, has all of these. And so the idea is to take 60 minutes and give you some of these that are in our head. Little known secrets and things inside of the product.

We're not going to get to everything, but when we do have something, we're going to see a nugget. All right, this is a little nugget of information that we're going to drop on you. So when you see a nugget, that means we're probably going to stop on it and talk about what it is.

So I've been working with our internal pre-sales team, and been working on an idea for a long time called workspace theory. So inside a fusion lifecycle, we have these things called workspaces. You can have as many as you want. How many do you need? Well, that depends. You have tabs. Well, which ones do you use? You have fields. How many fields do you put on a page? Hundreds, right? No, no.

So the field theory, tab theory, and workspace theory is just something that I'm working on. So that's what I put up here, I want you to come away from this, if you're not in fusion lifecycle yet, these are good tidbits for when you start to go. If you're already in, this might help you wake up that other workspace. Go and get into that other department. And along the way, Michelle is going to chime in because we both do PLM talk. We both do-- which is a quarterly? Quarterly. Well, it's quarterly. Let's say it's quarterly.

Used to be monthly. We used to have these webinars. So if you go out to the support forum for fusion lifecycle, you can actually see prior webinars. They're recorded on GoToMeeting. Go to webinar. We also have the Virtual Accelerate user group.

So when we get these ideas, we like to get these out. These shouldn't be secrets, okay? You shouldn't have to wait once a year. So we always have a way of getting out these best practices, and ultimately we want to use fusion lifecycle. That is, that's really my goal is to make sure everybody is using Fusion lifecycle and using these products to the best of its ability.

So let's talk about fields and field theory. So we have fields. These are also known as attributes. If you're new to fusion lifecycle, you might also know this as properties. In Vault we call these i properties. It's just data. All right?

And we have a number of different ways that we can use it. So we've got some best practices built in here. So you can have different types of fields inside of each workspace. But what you can do with the fields varies. OK, and you can get a lot of power out of it so.

Different fields are defined-- no one workspace has every field type. Just like either you want to divide up that type of information. So another thing to remember, when you make a field, it's actually unique to that particular workspace. It's something that's not global. So you don't have to worry like, oh, I used the word description. Can't use again. Now you can actually use it across or use the name over and over again.

So just as a reminder, this isn't really a nugget, just a reminder. We have a number of different property field types. All right. And the field types range from just single-line text, think free text, to integers to floating values to date fields to-- we even have some special field types. So by special mention, pick lists, derived fields, linking pick lists, and I have some examples for you.

We have URL, CSV, are comma separated values, and how you use these. This is where we get into field theory. So here's the first little nugget for you. We have this computed field, so you can drop in a particular field, and we could basically we could do some math.

This could be an iFrame mash up from another system. You might see this if you integrate with an ERP system or another, maybe a homegrown system. So you can actually drop in a little bit of code and build out a field. Give it some space. And it could be something just punches out. As long as you can authenticate to another location, you can bring this type of information in.

We also have validations on those fields. So that's the other little nugget that we want to put on here. Often goes, you know when you go make a field, you make it quick. You give it a name. But this is one of those things, make sure you go back and take a look at the types of validations that you have.

So you can make it, the easiest one you think is mandatory. But there's some other ones in there for uniqueness and dependency on other fields. And this is where, the whole goal of this, the so what, if you will, is to make sure that people are filling out the right information. Because any time you're making a record and somebody says, well, it doesn't seem to be mandatory. Or you leave that up to them.

You could actually put in some validation. So look at that. It's at the bottom of the page, nicely out of sight for you usually, when you're filling it out. But the idea here with the fields and validation is to make sure you're taking a look at these, so you can go and add some other uniqueness.

You've taught this before right? In the PLM talks?

MICHELLE STONE; Yeah you know, the one that comes up a lot, you know, we've seen dependency. If somebody fills out this one field, then make sure they fill out the next field. Another one I've seen fairly often, minimum length requirements. If you want to make sure people are giving meaty details, you can include that if you've got a field.

Just don't want them type one or two things. So you at least want 50 characters, you know, like an RMA if you have a problem. You can kind make sure that your end users are giving you the right information that you need in there. I think those are ones that are done a lot.

BRIAN SCHANEN: All right. Now, another little-- I thought we'd throw this in. I think most people know this, but if you get into building a matrix out or you're building a workspace out, there's a clone button. So the word clone is used across the product. We can clone a workspace. Technically, when you get a new tenant, that's a clone that we do on the back end of this tenant.

We can also clone fields. And the idea of cloning is you hit the ground running with most of the same basic parameters. You just get to choose a new name. And it's a good way to rifle through. So make sure you're using that. It basically speeds things up a little bit. You know, you just feel like you're working faster.

And yes, when you're building out a matrix, it's especially nice to go and have that same field type. You just rifle right through it. So again, a little bit of a little nugget there for you.

This one. The descriptor. So the descriptor, by the way, every record in the system has a given name. It's a descriptor. How is this known? So on a lookup or a search or anything else, what is it called. Usually it's the one thing. It's in bold and blue. It's at the top of the page.

But what we find sometimes is people make a descriptor, but what's in the descriptor, they don't make them required. What does that mean? So you do a report. You do something, it's like, well why is this not looked up? And if you're like me, I like things to be in a certain order. So if something is going to be part of a descriptor, make sure people fill it out. Make it a, getting back to the uniqueness. This is one of those things that-- just a best practice. So for the admins in the room, remember this. If you're going to have something in a descriptor, make sure it's a field. This is one of those little tidbits we like to make sure everybody knows.

MICHELLE STONE: Yeah I, think on that one, again, yeah, just making it a good user experience. Because you guys are all in here probably as PLM cheerleaders at your company. So you're going to be deploying this to the rest of your company. And they're going to be relying on that descriptor as that link to go to other parts of the system.

And just a pet peeve of mine, when you put in your test records, and it's just like a dash. Think about what the end user is going to see. I like to tell folks that I'm onboarding. I really like to see field 1 and field 2 to be either required fields or an auto number or something so it's not blank when you're navigating through the system. It just makes a better user experience.

BRIAN SCHANEN: Yeah, nothing looks worse than that one with the dash. Because the fields are all separated by a dash. There's a lower level setting under System Wide Configuration where you can tell it what kind of a separator do you want. And by default, inside of all these tenants, most tenants it's a dash. You don't want to see an empty dash just sitting there, hanging out. Sticks out like a sore thumb.

By the way, up to four different fields can be used as a descriptor. Now watch out for that. Because you can have any field that you want except for paragraph. No paragraphs. Otherwise your descriptor would be like long, long. So you can have-- I really don't see too many people even going beyond three. It's rare that we see that.

Another little tidbit. Not everybody uses or implements it. I think you use it. If you're using the current tenant, it's in there. It's what's known as a derived field. It's the ability to prevent, you go and select a record or select a value, and then other values fill in. It's meant to overcome tedious, monotonous or duplicate data entry. It's a great feature in the product. And not many people maybe even know about like how do you go in and build this and create it.

But it's there. In fact, you can reverse engineer some of the fields out there. I'm thinking, so the approved manufacturers list in items and BOMs, it has an example in there. So derived fields are good. It draws in additional information. You drop down like a customer name, it brings everything else along with it.

Anything?

MICHELLE STONE: That's good.

BRIAN SCHANEN: We don't have a nugget on this one. We have a nugget on this one. All right, the other one in here that's really nice, and this is a little bit of a foreshadowing to what we call in workspace, we'll talk about helper workspaces or reference workspaces. It's what's known as the filtered pick list.

So if you've ever gone out to a site and filled something out and it asks you to pick from this pick list. And then the next set of values is contingent on the prior set. And the next set of values after that is contingent on that. You've just used a filtered pick list. And inside of here, it's exactly what we call it.

Now to set this up, I have actually-- I'm going to probably punch out to Fusion Lifecycle and show this here. So a great example, and this will be something that you can easily go and replicate yourself. I have it set up like a cooking show, so it's actually already done. But zip codes.

So if you're going to fill out somebody's state or province, and then the postal code or the city and then the postal code. You know how that drops down. You don't want to have to choose through all of the postal codes. This is actually a good place where if you can get that type of information, and it could be product information. It could be anything that you have out there in Excel. This is a good candidate to upload and bulk imports.

I'm going to have a seat and show you what I'm talking about. So in this case, I actually created-- there's a whole category here inside of Fusion Lifecycle in this demonstration tenant called reference. Reference. This is where the admins play.

Sometimes you have a workspace just to help out a workspace. And sometimes that workspace helps out another workspace. So more about that a little bit later.

But we have a workspace here called zip codes. Why would you have that? Well, you don't want to have to go out and leave PLM to go and pull this in. But here it is. Here's all the zip codes. And this was actually a nice-- this was a good test to throttle Fusion Lifecycle I did a import of 42,000 records, and that's cool. As a data geek, I just love that kind of stuff. I was just it go, yeah. You know, you can throw as much at it as you want.

But the idea here is, you take a look it's-- zip codes are sort of descending. I think you get the idea. Basically goes all the way from Alaska to the east coast. All right. But what? So what? All right, so what does one of these look like?

So there is a-- there's actually the descriptor that I put on this, in this case, Alaska, Healy, and then there's the postal code. There is a state name. Abbreviation. The city. The zip code. And then, just because it was in the spreadsheet that I was able to get, I brought in nickname. I don't know what I'm going to do with that, but probably something fun a little bit later.

But what did that look like? Well, it started like this. It started as a great big 40,000-record Excel spreadsheet. So what do we do?

Well, you make a workspace, and you bring it in, and you map things over. By the way, we're going to cover importing a little bit later. I have some best practices on how to import. So you have state, abbreviation, city, we're not using that. Latitude, longitude. Just in case anybody wanted to know the city center. And then, of course, the numeric postal code in this case.

So where does that play? Well, if I come over here to the customer's workspace. Again, this is like the cooking show. So let me show you how it works. If I were to say, let's go, and I'm going to say, let's call [INAUDIBLE]. Good. I practiced this once before.

So this is what a filtered pick list manifests itself as. If you've ever thought, you know, in our catalog. I want people, or a product or a workspace, I want people to choose, and then choose on something, and then choose something else, and narrow in.

It works like this. If I were to say, well, we'll go with Michigan. That's my home base. But if I go here, notice it basically narrowed it down a little bit. So there's Novi. Somebody tell the fun fact about Novi. Never mind. Basically, so it narrows it down to the yes, that's really the number six. Yes. It's an embarrassing part of our culture.

So it narrows it down to the four zip codes that are in the-- how was that done? How was that done? So let me take you to the-- basically I'm going to pop the hood and show the back end of this.

So this is a workspace called customers. But it could be anything. Customers, distributors, manufacturers, vendors, anything where you have some information about it, and then you just, you have, by the way, it's 4375 if anybody's interested.

So how does that manifest itself? So I'm going to take you into Journey as an admin. We can get into the Workspace Manager. So this is a great example of how you can chain workspaces together and how one workspace feeds into another one.

There's a workspace here called zip codes. And that's the one that I had. Pretty straightforward. Pretty easy. You have a number of fields. So single line, single line, everything's single line text. Notice I didn't make single line text, or I didn't make the postal code or the zip code numeric because, you know, North America. We get to take it actually, Canada. Yeah, those crazy Canooks.

So how does that manifest itself over here? Under customers, I'm going to go into the item details. And this is where I started to build out. We've got the name, the logo, the notes. Good stuff. All right, website, revenue, stock ticker, all right.

By the way, stock ticker, that's a good example of where you can go out, punch out, grab that information, and bring it back. What's Autodesk at? I think we almost hit 75, right? Today. Rock on.

All right. So how do we-- so address. So the street is a single line text, but notice the state country is from a filtered pick list. Let me show you this. So the filter pick list, you tell it first of all, it's a data type. You do have to make a pick list based off of a workspace, and all that means is, it's a list that exists and it taps in. It taps into a given workspace and looks at all the values in there, and tell it that it's filtered and tell it which one. So it will actually pick it up.

So based on state name, then the next one down is the city and town, so based off of the previous, it will go down to the city and, of course, the zip codes. So we're essentially going from a macro down to a micro level and searching on that.

So one more piece. I did mention it. We have a system wide what's known as the pick list manager inside a Fusion Lifecycle. And this is within your tenant. These are-- the good news is the product-- when we clone out, when you get a PLM and site, there's a lot-- Sorry, I said PLM. Fusion Lifecycle site. There's actually a lot of pick lists already in the system.

And these are ones that you can take a look at. These are just static pick lists, and you can add values here. But any one that has a WS in front of it. It's a little bit of a best practice. There's another good nugget for you. Best practice, put that WS prefix. That means that this pick list is going to look into a given workspace, and all values in there are now going to be available as a dropdown.

What does that look like? When I come back here, and I go in and I choose the state, city, zip code, it's going to narrow it down. So again filtered pick lists. You might have used one already. If you're using maybe the original old classification. But if you want to use it, coming up is a very good example.

I actually did not upload this. But I could upload this after the class if anybody wanted to go and--

MICHELLE STONE: Yeah, put a note to do that.

BRIAN SCHANEN: All right, so we'll upload this. It will be under the additional materials. So there's the handout, the presentation, and then we'll add this in as well. All right, so again, it's a good nugget. I wanted to stop on-- Yes?

AUDIENCE: [INAUDIBLE]

BRIAN SCHANEN: Yeah, you can. So the question was, sorry, we should have-- I do have a microphone, since we're recording the class. But yes, you could start, you could enter that, and it will fill in the information. If you knew the exact zip code, it would have filled in like Novi in Michigan.

AUDIENCE: [INAUDIBLE]

BRIAN SCHANEN: Yeah, yeah. All right, cloning field, let's get back to where we were. All right. So what? The so what of this is, you can ensure that people can and do choose properly and choose accordingly to what they need. You can actually guide people in to make sure that they're choosing something that's actually part of a real configuration, part of a real option. That's really the so what.

By the way, I threw on these so-what slides because I like to get to the point. Somebody is probably thinking so what, right? This is the so what. You get better data entry. You get people filling out the record better. Make sure that they do this. And if that's feeding into a descriptor, well, there's your so what. You have a much better, much more intelligent record that you can use later on. Good. Demonstration we did. How we doing on time?

MICHELLE STONE: Got to go a little faster.

BRIAN SCHANEN: Little faster? All right. Tab theory. We could probably do a whole class just on this. We could probably do a whole class on the tab. So here's what you need to know. Inside of Fusion Lifecycle we have a number of different tabs. OK? Now, no one workspace gets all the tabs. I know what you're thinking. But inside of here, the idea is to use the right tab in the right workspace. Sometimes you might need to make a secondary workspace. Sometimes you can get a little bit creative with what you do on the Item Details, or maybe the Grid tab or something else like that.

So we have a number of these. We're not going to go verbosely through every single one of these. We don't have the time. But what I do have are some nuggets. So there's a Change Log. If you could appeal and tenant, you log in as the admin. You take this for granted, but there's that last tab over there and it's called Change Log. That's actually a running record. Think versions, but don't think version-- but think it's going to record everything that you do-- edit, save, edit, save, edit, save. Everything is going to be recorded there.

Now that's not something that everybody gets to see, by the way. There's a permission on this. In fact, there's a permission just about on everything, even the fields I was showing you. You can put a permission on the section. But make sure you take a look at this. Go through it. It's a running record of everything that occurred within that one particular item or seal-- record. So take a look if you're using it. Make sure that you are using that.

The other nugget that we have on here often overlooked is the Action Notification. So within PLM, one of the best parts of it is the workflow. Workflow process notification. You get an email. If you're on the list, boom, you get an email. You have something to do. What do you do with the people that you want to let them know, but you don't want them to do anything? It might be long lead. It might be somebody that's on the outside or in orbit around Fusion Life Cycle.

The Action Notification tab. We can pop this on with a permission, let it be seen. And you can actually put a watch-- basically put a watch state on either a transition or a state. And the nice part about this is they'll get an email, because email still-- right now that's our primary communication mechanism. This has reached the state. There's nothing for you to do. Just want you to know. Show of hands, who here, is anybody using this right now? It's there. It's something that you can just enable, but I think it goes often overlooked. I think it might be on by default on the change request, just to let somebody know like, hey, this got to this point.

AUDIENCE: [INAUDIBLE]

BRIAN SCHANEN: We have a microphone there for you so we could capture the--

AUDIENCE: Does that allow users to sell subscribe to the watch, or does the admin have to assign the watch?

BRIAN SCHANEN: You get the choice. So the admin has to turn it on, but somebody could be-- you could put a person or a group on that, or you could, if you had the permission to-- so yeah, I want to watch this. I want to be notified as this completes. Does it get canceled? Is it on hold? Something like that so-- Question?

AUDIENCE: Is it possible to actually set it up? Would you type the notification that you get? Because right now that's one of the problems that we have is that we get-- if you want one notification, or you get them all?

BRIAN SCHANEN: For workflow?

AUDIENCE: Yeah.

BRIAN SCHANEN: In the action notification, you actually will get-- depending on what you choose-- you get to choose the transition or the state. You get to choose what you want. That's the nice part about this. And if you are getting too many notifications, you may want to take a look at a few things. First, part of your personal profile, you can go in-- you can go into my profile and then see what you can see. If you're getting too many, it might be a configuration. Oh yeah, there's me. So here's the manage electronic notifications. I think I pulled the slide out, but as long as you had asked about notifications, you can tune what you see.

If you really wanted to see everything, you could actually go into something, like subscribe to everything, like every edit, every move. That's a whole lot of information. But if you're having that, chances are we should probably talk after the class and take a look at your workflow notifications. You might have a couple checks on every state, and you may not want all that. So people are getting spammed, then what do people do? They shut it off. They shut down. They start to ignore it. Great question though.

MICHELLE STONE: And I'll be able to answer more in the next two days, if you want to come up and talk about it. And I left a lot of this in the handout as well. But for the action notifications, the way I employ it-- we use it internally-- to drink your own champagne concept. A lot of times I'll do it similar to if you used your watcher list. If there's certain people that may not be in the workflow but I want them to know when something's been completed, I often just set it on when I hit state, complete.

And you can do it, not just users, but even groups, because sometimes you might want to let a whole group know this happened. They're not involved in the workflow, so they're not getting the workflow notifications, but they do want to know what happened. And then we can also talk about those manage electronic notifications where you might want to subscribe to certain events and get a daily summary.

BRIAN SCHANEN: Good question. All right, the next one. I don't think we have a nugget on this one, but what often goes overlooked, the Affected Items tab. So let's talk about it. Every change that goes to a revision controlled workspace has to have a revisioning workspace. Other way to say it? Items and BOMs, ECOs. All right. On the ECO, we have a tab called Affected Items, also known as Managed Items. You can add fields to this. I think a lot of people say, no, we have to put all these fields on the item details. You can actually put some of those fields that might be unique to a particular row off-- take some fields off of item details, get them here on the Managed Items. It's something that the administrator can do.

So you can actually add other columns in here. And it could be a dropdown. It could be a picklist. It could be a free field. It could be anything else that you want. So you have your static fields, and you're going to have a name, the effectivity, life cycle, that kind of stuff, but you can actually add other fields. In other words, you're building up this list of proposed, affected, or as I sometimes-- infected items. That's why they're going through a change.

So basically you can add other columns to this. Again, I don't know that everybody knows that, so that's another one of those little tidbits that I like to throw in so there's a fun fact in there.

AUDIENCE: Does those attributes [INAUDIBLE] with network space?

BRIAN SCHANEN: Yes.

MICHELLE STONE: Yes.

AUDIENCE: [INAUDIBLE]

BRIAN SCHANEN: That's right. They would live there. In fact, they would live because during that ECO for that amount of time, it's something unique to that change, and then if you went-- and that was revision D, and you want to look at everything, well, why revision D? It would be something that lives right there. So it doesn't have to live on the item because you might not want to have that information there.

The other tab-- and I'm a big fan of this one. As Michelle mentioned, we do use PLM and Fusion Lifecycle internally. We have this site, and we manage a lot of stuff there, all the tenants. Every class that I teach, I actually have a class and have a list of the students. The Relationship tab is a great way to take two workspaces and join them together. This one knows that one; that one knows this one. Basically like a wormhole between them. You go into one, and you can see things in the other one. And you set this up on the back end.

But the Relationship tab, it's another one of those-- not that popular for some reason, but it's there. It's the ability to make sure that from one workspace, you can get to another. Just a very easy, superficial relationship between two. In this case, I have Chris who's in our team. I have a training attendees and training, like classes, that I've done on Fusion Lifecycle. So I can actually go in there as two different workspaces. I can look at a class and see the attendee. I can look at the attendee and see how many classes. So you can do that. If you ever have two workspaces and you just want to join these two, wake up the Relationship tab as a permission. Make sure that they can see one another. Again, something you do on each workspace in the workspace relationships area. And poof, that's it. It's very easy to just go in and set this up.

Tab orders. Another best practice. And this is something we tried to do in the latest tenant that we have. Tab names, make them consistent. Tab orders, make them consistent. Couple of givens. You always have item details at the first. That's the first one. It's on the far left. Change log should be last. But what happens in between if you have grid tab? If you rename workflow and you call it something like process? Do that on every workspace. Your users will appreciate it. You'll have better and quicker adoption.

I know the product, all the workspaces. It does look the same. I get that. But a big best practice-- and one of the reasons we have that nugget up there is just establish some consistency. However you want to document your rollout of Fusion Lifecycle, just have consistent standardization. That's what we're here for anyway, right? Data management and PLM, so best practice. This actually I think came in right from you and the street team. Yeah.

All right, let's talk about tabs. You can turn on every single tab on a given workspace, but no one workspace needs, nor is it logical, to have them on. So just because you can, you probably take a workspace, turn them all on and the permissions, get it out of your system, and take a look at what that looks like. But now it's not pretty. Basically you just have a whole-- all the tabs turn on. No one workspace has workflow and bill of materials and where used and sourcing and suppliers, and, and, and. So again, have a talk with somebody about tabs and what tabs are appropriate. This is all part of tab theory. How many do we need? When do we need it? When do I need a tab? When do I need another workspace? When would a print view or a report suffice?

And so what? The whole so what about tab theory is to make sure you're getting the most out of a given workspace. People ask a lot-- I teach a lot of questions-- should I make a workspace? Should I have another tab? Should we be using a different software? It depends, but the so what here is I want you to get the most out of it. So the handout and the presentation-- the 100 slide presentation I uploaded. I have a few more tidbits.

Getting into workspace theory. This all leads up to you have to understand properties and fields. You have to understand the tabs and the different powers that they have. And then workspace, let's talk about this a little bit. If you're new to the concept and new to Fusion Lifecycle, a workspace is an area where you have like-minded records. We call them items. I'm going to call them records because that's what it is. It's something without a file extension. It's just a collection of data that's unique. Change requests and change orders, items, accident reports, nonconformances-- these are different workspaces. They are limitless. You can have as many as you want. But there is a logical limit, I think, to how many workspaces you'd have inside of any given tenant. But the fact of the matter is, we don't license per workspace, so you can actually have a number of them. You can have workspaces that help out other workspaces that help out other workspaces, as I said before. But the idea here is, just as a definition, workspaces are a collection of objects with common properties across them.

A couple of tidbits. You can make as many different categories and groupings of them as you want. Inside of the default tenant that we stand up, these are grouped by-- the way you see it, they look like they're grouped by department. I look at it as a discipline or a persona. But you can rename these and group these however you want. You could just have one category and list all the workspaces all the way down, if you were so inclined. We generally implement with the department or the team or the discipline, the quality, the supply chain, the engineering. It could be anything else.

And then, of course, we have the reference. So always have-- for those admins in the room, have your own stash. That reference, that's where you keep your stuff-- lists, and just helper workspaces. So it's always a good idea to have that. They are definitely permission-based. Not everybody gets to see all the workspaces. As an admin, when you go in you're going to see everything. When you go and add people to other groups and they're not administrators, they're only going to see what they need. Two different logins will give you two different views. Same tenant, but different views depending on what you want again. I think if you understand that--

Reference workspaces. Talked about this a little bit, but there's a few others that you should know about. Currently in Fusion Lifecycle we have a classification engine that's actually core that's built in-- true classification to help you categorize anything. You initially think items and bill of materials, but it could be suppliers and vendors and manufacturers. It could be what type of change do you want? Change order, change request, change notification.

But we do have an old classification engine in there. It's probably in most of your tenants that you have right now. Even if you have it turned off, it's there and it's dormant. By the way, it's a good example of filtered picklists, if you wanted to go and reverse engineer and see just how are those built, how are they used.

The other ones that are in there, we have approval lists. The approval lists workspace is just simply-- it's a workspace that collects a routing list of the users in your system. And then given a particular routing and a change request or a change order, it will be available as a dropdown. So use these. Use helper workspaces. Don't be afraid to make another workspace that's just a list. It doesn't have to have workflow or revisions. It doesn't have to have any special powers. It could actually just be a list.

The other one that you'll see from time to time-- generators, description generators. We actually used to have a part number generator, but now we have that taken care of core inside of the system. But you might have a description generator. You might have a template. This project task template right here is something that we have on some generations of sites. And what that allows you to do is, you make a new record and actually automatically fills in all of the tasks, basically automating some process for you.

Helper workspaces and reference workspaces, again, very powerful. Make sure that you're using this and leveraging it if you're-- and if you weren't aware of it before, that might be what's behind-- we have a nice build here.

Workspaces and then apps. Let's talk a little bit about collections of workspaces. Workspace could stand alone, but usually a workspace is there to be part of a process, to be a link in the chain. You can bring together workspaces, so what happens in one workspace might feed into another one. There are a couple of ways that we can do this. It could be through spawning. The linking picklist example with the zip codes and the customer's workspace is another example of it. But the tenant that you have-- if you have Fusion Lifecycle, if you have a trial-- actually has a lot of this built in. So we have the ability to chain together workspaces. In fact, I like to say if a workspace is sitting there all by itself, what's it actually doing? Every workspace should be pulling its own weight inside of the system.

For examples of other workspaces, I think a lot of people know about this, but I'd encourage you to go and take a look at this. If you're an admin, you can go out to the app store-- it's under the Administration menu-- and install one of the apps. It's something that takes a couple of seconds. Go and read about it and just install it. And actually as the admin, you're the only person that sees it initially, so you can actually do a little bit of careful, lightweight sandboxing of a new app.

Now an app could be one workspace. It could be five workspaces. There's no hard and fast rule. The idea of an app in the app store is it's a solution. It's a theme. It's a collection of these. I'd encourage you to take a look at these, maybe throw them in another reference category or another category off of that main menu and play around with some of these. I like to say, install it and make a record in every workspace. There's a lot of information that comes along with this.

By the way, in addition to the workspace, you get roles. You get scripts. You get picklists sometimes. It's basically turnkey. All you need to do is allow it to be seen. And I know that we've had PLM talks and other webinars on how to do this. I think we have some videos up on our YouTube channel, PLM TV, as well. But if you've not used this before, I'd suggest you go out there and take a look at this.

And so what? So what is all of these workspaces? They're meant to do and solve a particular solution. In these workspaces you can have, as I said before, as many as you want. So don't be afraid to go and create some extra ones, maybe cloak them from most people, test them out, and then roll them out and deploy them.