Fusion Lifecycle Admin 101

TONY MANDATORI: OK, so this course is Fusion Lifecycle Administration, and it's meant to be the basics of administering Fusion Lifecycle.

There are two presenters. I'm Tony Mandatori, and this is Hagay Dvir. And between the two of us, we have a lot of experience with PLM. And it should come as no surprise that we actually have experience in other PLM products as well. OK, so we know what the industry is with PLM, we've been doing it for a few years, both with this product and other products as well.

I want to get a show on the room. How many people have been implementing PLM for more than a year? OK, and more than five years? You're going to get tired.

OK, so two people more than five years. More than 10 years? OK.

So you weren't using Fusion Lifecycle if you've been doing it more than 10 years. Yeah, OK.

So, good. So we have some people with some experience with PLM. This is meant to be a basic class, so if we don't get into some of the topics that you really want to hear, please email us. Those are our email addresses, tony.mandatori@autodesk.com and hagay.dvir@autodesk.com.

The presentation and a handout is available to you. We're going to try and go through some simple demos to show specifically what the power of Fusion Lifecycle is. And what the power is, is it's really simple to get your system up and running in a very short period of time. OK?

So PLM typically-- and Joe can probably nod his head-- is expensive, it's an expensive endeavor. You don't get it right the first time, you iterate. That's kind of changing. We're kind of changing the industry with Fusion Lifecycle, and that's why we're so excited about it.

So I've been a solution architect, I'm a solution architect in the field. I'm a consultant, I do engagements, so I keep it real. Hagay is a product manager. Anything else that we should say about Hagay?

HAGAY DVIR: Yeah, I'm the senior project manager for Fusion Lifecycle. And so any questions, again, feel free-- this is my email. Just feel free to email me.

TONY MANDATORI: And the dynamics, the way it works on accounts-- I tend to talk to customers, try and get the requirements right, try and do as much as I can, and then Hagay sets me straight, right? So I say, Hagay, this is what we need to do. So OK, this is the way we strategize together on how to do things.

OK, so let's get into some of the-- so the class summary. The class summary switched a little bit. We were going to talk about Fusion Team a little bit. This is not Fusion Team at all, this is all Fusion Lifecycle, and it's going to be with the classic user interface.

The key objectives is to basically learn how to map your requirements into some workspace configuration. So with the experience I've had, I've seen certain things in PLM, and I want to share that real experience with you a little bit and show how I would configure Fusion Lifecycle if I was trying to configure it from scratch.

So the ability of creating your workspaces is pretty simple. So what I want to do is I want to show that some of the things that are pre-configured, you can use them or you can try and recreate them. It's not that difficult to recreate them.

OK, so that's what the gist of this presentation is, is really to show you how to map some requirements and expose them inside of PLM 360. Workflows, relationships, and attributes are the big ones.

So Fusion Lifecycle is all-encompassing. PLM actually is all-encompassing. When a business wants to do PLM, it's probably because they want quicker time to market. They want to get their products out there quicker and they want to have fewer defects.

So it kind of spans the entire life cycle of the product. You start with designing the product, but then even all the way to service you want to make sure that your product has quality in it, if there's defects that you track all the defects, that you have the right people communicating with each other.

So communication is the key. The reason you have this system in place is to make sure that people are talking to each other, to get the product developed quicker, to get the product improved quicker so you have a better product in a shorter amount of time.

So in the industry, what I've noticed is the reason people paid millions of dollars for their PLM implementation is because they wanted that hedge against the other company. When Boeing's designing an aircraft and it's taking them a year to develop it, Airbus is already out with a newer aircraft.

What you want to do is you want to get quicker time to market. I want to get it down to six months, I want to get it down to three months if I can. OK, that's why people pay big bucks for it.

OK, so the different aspects over here. You can see them on the page there. There's different areas of the business that are going to be affected by PLM. Eventually you want everybody communicating with each other, tracking everything they're doing in the same system.

Issue management-- I think in a previous session, we had [INAUDIBLE] talking about quick wins. [INAUDIBLE] said, try and do your implementation quickly. Try and get something out there as quick as you can, so people become comfortable with using Fusion Lifecycle. OK. So that's what we want to do. We want to start off small, but then let it grow. Let people start using it. Let people start sharing information and working with each other.

So what you're going to notice is that Fusion Lifecycle, or PLM, is going to be managing a lot of different aspects of your business. You want to get the right information to the right people, quickly. So if somebody needs to approve a change, don't clutter his inbox with a whole bunch of other changes that he needs to improve. Get him focused on that one change. OK. Then, when he clicks on that change, give him the links to go somewhere else-- go somewhere else quickly. And so that can easily be configured in a few different ways. We'll show a couple of them here.

So we talked about some of these already. I kind of wanted to show you a definition that SIM data has on what PLM is. OK. So, not a product. And that's the big thing. It's not just a product. It's a way of trying to make sure that your processes run efficiently. So I tried to highlight the major points here-- strategic business approach, and it's spanning the entire life cycle of your product. And it's the complete set of product definition.

So I think with the aircraft industry, when I worked in that, you have to supply a configuration statement for the aircraft. So you want to have everything that's on that aircraft-- so complete product definition. Then your aircraft changes before a first flight. You find some issues in it. So what you want to do is, you want to make sure that all the changes that you've made appear inside of another configuration statement that you supply. Everything that's defined for that product is something you want to put together and keep in one single system. So it's not a technology. So that's the biggest point that you want to hear. It's more of a business process. It's more about making sure that all your product data is linked together properly.

So now I'll talk more about Fusion Lifecycle. And the things about Fusion Lifecycle-- the first thing you notice when you look at the user interface is workspaces. And other products, other PLM products-- what they'll try and do is they'll try and build containers. They'll try and build containers because maybe that's the way people sort of organize data in their mind. They have a desktop. You have folders on your desktop. You try and create these folders. Those folders-- we kind of think a little bit differently. The workspace in Fusion Lifecycle is a way of defining your configuration, as well as compiling everything into a location that you can easily search.

But if we were to folder it up, what's going to happen is that you're going to start defining to people on a way to search their data. And you kind of don't want to do that. You don't want to limit their definition by saying you have to follow my folder structure. What you want to do is, you want to give it to them and then say, filter as you need. So you filter the data as you need to look for it. So instead of using folders, or instead of thinking about workspaces as a place to store your data, and then creating a whole bunch of them for different types of data, put them all in one place so that you can easily filter them.

So the workspace is a way of defining what the different types of objects that you have-- items and bombs. I might have items that serve different purposes, but I'm not going to put those different items into different workspaces just because I want to collect them together. Put them all in one workspace. We're really efficient on how we can scan through 40,000, 100,000 objects in a workspace. Use filters to narrow in on what you need.

And I'll show you a little bit of a demo how filters look like. You probably already know this, but if I look at the items in bomb workspace-- in the items in bomb workspace we have a filter defined to say, just show me bills of materials. So use your filters instead of looking to create different definitions or different locations to store your data. Some people would have said, hey, I kind of want to store my data in a different workspace. Bad idea. The good idea is, use your filters.

And the filters basically give every user the ability to look at the data a different way. So in this case, I want to search for some attribute equals to bomb. But other users might say, well, instead of doing that, I want to search for things that are assigned to me, or something else in the definition. They can easily do that with the filter definition.

So try and keep, according to the slide here-- try and keep your definition-- focus on the definition. Split up your workspaces with the different types of objects you have. Typically in PLM, change objects, change order, change request problem report and items. So these are the different types of objects that you see.

So designing a workspace-- so when I look at a workspace, I see tabs across the top. I see a bunch of fields. And there is a temptation, I think [INAUDIBLE] talked about in her lecture as well. There's a temptation to kind of go overboard. There's a temptation to put a whole bunch of attributes in there, not because you think they're really good attributes, but just because you think, well, maybe I'll use it. The idea is, try and make it look like something that you typically do. So if I have a change order, you have a piece of paper that's your change order. Typically you're trying to put a lot of the information on that one piece of paper, but it's organized efficiently.

So if you're using change orders in your industry, you've probably already organized in such a way that it looks good. Grab all those attributes. They're probably really important attributes that need to be on that page-- put 'em on your change order. Organize them in such a way that people will relate to the different sections that they're using. So that's the idea of making it simple. Don't over-convolute your your workspace with attributes you're not going to use.

If you do need to have some extra attributes for calculations, that's OK. Hide them. No need to see attributes that are purely only used for different reports, et cetera. So try and keep it as easy to use for the new user as you possibly can. Keep as few attributes that you can get away with. If you need some extra attributes for a calculation, don't clutter the interface. Try and remove them into an admin section to hide them.

There's a few different types of workspaces that we have in Fusion Lifecycle. There's six of them. And they're listed out over here. You start off by considering that there are basic objects, objects that you kind of just want to use in reference lists. Maybe a list of-- if you're doing an aircraft, ATA chapters. So a basic workspace would be something without a workflow, without the capability of revisioning. And that's the first type.

If you're adding workflow, or if you need to add workflow, you'd use the second type. So it's an object that you need to get approved-- maybe a new product introduction. That's where the basic with workflow comes in. And what it does is it builds upon your basic definition of an object with all of its tabs, to having now a new object that says, I need to put it through a set of states. That's the only difference between basic and basic with workflow.

The next type of object that we have-- let's see, which one is it? Revision controlled object. So this is kind of different from some of the other PLM products that are on the market. But the idea of a revision controlled object is no workflow, but I do have the ability to revise it from A to B to C, or from one to two to three if it's an internal design revision.

Then those objects that are in the revision controlled workspace, they have to be identified as unreleased, released, maybe under review-- something like that. So the idea is that you'd put it through a lifecycle state. And we'll talk about how to do that. But that's where the fourth one comes in. The way you move something from unreleased to released is by using a change order or a revisioning object which has the capability of moving items from unreleased to released, or from one lifecycle state to another. So there's a different concept here of lifecycle state, different from workflow state.

The two at the bottom or for managing suppliers. And they have capabilities where, if you want to identify suppliers on a sourcing tab-- if you identify a workspace as a supplier workspace, you're able to choose that supplier on the sourcing tab, and then able to see all the supplied items for that supplier on the supplied items tab. So it's some special functionality with these two over here. And you can choose whether you want a workflow or not on that supplier object. So basically your first step in defining a workspace is to say, what type of workspace do I need? Is it basic? Does it need a workflow? Is it revisioned? Or is it the object that actually goes out and does the revisioning on those other objects?

So what I'm trying to show here is that there is a main menu designer where you decide how you want your things to appear in the menu. So I didn't show the menu over here, but the menu is configured a certain way if you go to Fusion Lifecycle. In that menu you have control over what you see here. So we've called it product development in this case. And we have items and bombs. We have products. We have tasks inside this product development.

But you can change that configuration. And the way you change the configuration is by going to the main menu designer. And that's what I was trying to show you on that slide right here. So you can configure your main menu as to the order, the grouping. If it works for you, the way it is by default. That's great, but you can add more as well.

So the next thing is aspects on the workspace. So you've defined the type of workspace you wanted. And now what you want to do is you want to add different functionality to the workspace. And the one thing that, for me was kind of a surprise, is that you have the same aspects for every workspace. So you can, if you wanted to, turn on all these tabs for every single workspace. It doesn't make sense.

Some of the tasks have very specialized capabilities. So if I look at a workflow tab, for example, does workflow make sense on a basic object? That's right, no. It doesn't make sense on a basic object. Does bill of material make sense on a change order? It depends. If you're going to structure your change orders in such a way that you need parent-child change orders, where there's a mother change order and some children change orders, the change orders made up of other change orders-- that's an interesting concept, but it's not the basic definition of what we see with items and bombs. So items and bombs-- the bomb, the build material tab is going to be something that you only put on to items and bombs typically, or to maybe a product, calling up an item.

So there's specific functionality that's exposed in each one of the tabs. And you typically wouldn't turn them all on, on every workspace. But you could. So that's the way we expose functionality inside of fusion lifecycle. You turn on one of the tabs. You have the functionality inside the tab. You remove the tab, you don't have that functionality.

And some of the interesting ones that we have here-- item details. Typically on every object that I create, I'll probably have an items in details because that's the one that holds the attributes. The bomb, typically only for items and bombs. The grid-- I need some sort of a tabular notation. I need something that identifies objects in a tabular way.

So the default configuration of Fusion Lifecycle has certain workspaces predefined. And that's someone's vision. It's our vision how you could do product or PLM, product lifecycle management, in a very simple way. So it has simple workflows, some scripting involved with some of the workflows. And the functionality over here is exposed through tabs. You have bill of material exposed in the items and bombs. You have workflows exposed in the change order, et cetera. So it's the way you could do product lifecycle management. So there's some semantics on each of the pages, which we use to our benefit to actually come up with a PLM system or to build a PLM system.

So now, let's talk about the industry again. What's an item? And I tried to find out a definition for an item that would kind of make sense. And we use the word item-- it's an overloaded word inside of Fusion Lifecycle. Everything in our workspace is an item. But that's not what I'm talking about here. I'm talking about items in which workspace here? You can't answer. Don't worry about it. The PLM item is in which typical workspace? Items and bombs. You win the prize! You know what that prize is? Respect by everybody else over here-- you got it-- including myself.

So typically when you look at an item, you typically think of an owning organization, an identifier, a revision, a name, a creation date, and some other attributes that go along with it. But those are the important ones. The owning organization-- cage code maybe. So you might want to put a cage code. Something that defines who is responsible for that item.

So typically in smaller companies we leave that out. But that's something that you could say, I have an item that I've defined, but this item is something that another company has defined. So you have this ownership concept on the item. Typically the reason we leave it out is because we're defining all our items, and those are the only ones we care about. So that's typically why we don't see it in fusion lifecycle.

Now, the other thing to understand here-- and I've seen this a few times in a lot of engagements that have gone on, is that there's a notion of a drawing or a model. And the drawing or model is not the item. The item might be very well described by an attachment that we want to put on there called a drawing or a model. But a lot of people really say that it's not the same thing.

You might have a couple of drawings that describe that item. You might have a couple of models that describe that item. There might be a relationship there that you might want to manage. So just realize that it doesn't have to be the same thing. Again, we'd like to keep things simple. So for simplicity, we'll put them on the attachments tab. But it doesn't have to go there. It could be another object which would have a relationship.

So, another thing that we want to do is, we want to kind of take away the guesswork when someone's creating an item. We want to take away the guesswork when people are using the system. So what you want to do is, you want to control what they're doing. You want to make it easy for them to use a system. They just have to hit a button, and then every attribute they see makes real sense to them. That's why you don't want to over-clutter your interface.

So the creation, the numbering, the versioning-- probably automatic. You probably want to keep that automatic and unintelligent. So that's another thing that's in the industry. Intelligent numbers-- they served a purpose way back when. And maybe they still do serve a purpose so we can put the intelligence in the number if you like. But in order to make it simple for people to use, you probably want to take that away. The versioning as well-- you probably want it to be automatic. We don't want to think about, should B come after A? Can we let people put A after B? We don't want to go into that. It's too complex. Keep it simple for the user to define.

Consistency and control-- if you change the item, we want to make sure it goes through an appropriate process where people are able to look at it and say, do I really want everyone in the company looking at this change? Does it make sense? Does it make sense to waste the time of 20 engineers in a CIB meeting for this one change or not? So you want to make sure that you go through a standard workflow.

And the last thing that you want to do is you want to make sure that people have a way of relating all the items together and all the supporting material. So they're one click away from the information. You go to the change. What are the objects on the change? What are the affected items? You're one click away.

So we have this in Fusion Lifecycle. So these are the good practices in PLM. We have this in Fusion Lifecycle. Here is an example of an item. You see the item and you see the change order on the bottom which references that item when it's being changed. It's automatically numbered. It's version controlled. And actually I think I have some animation on this slide. Yeah, there we go. Automatically numbered-- that number that came up was generated somehow.

We have version control. So on the change order, if you don't change the configuration it automatically identifies that we're going to the B version. It has a life cycle state, or a life cycle transition. So on the change order it's going to be a production revision when I go. And that's why I chose B. And it shows that this is a production released object. It has a cut-in effectivity.

We're now going to talk too much about effectivity, but this is super important. When you're looking at an item structure, you want to know, how does it look on this day? The date that I'm looking at the bill of material, there's a context there. So we have the cut in effectivity. Whenever something is released or created through a change order, the version is created. We have an effectivity date that cuts it in.

So Fusion Lifecycle items-- I think you might have seen a piece of this in Brian's presentation . We copy off each other. We like each other. But the idea is that there's a certain hard-coded revisioning scheme inside of Fusion Lifecycle. We do this to make it easy. Again, we don't do this to make your life difficult. We think that alpha indicators, A, B, C, they kind of mean the big release, the real release that you want to ship to customers. One, two, three, that's kind of the internal releases. It's kind of ready for some things but not ready for other things. And then we have a working state where we see what the next version of the object is going to look like. If we want to change some attributes, it's available to us to change right away. So that's the versioning scheme.

In automatic mode, it can't be changed. So some customers say to me, well, I want to automatically assign the next version. And I don't want it to be off. I want it to be numeric. We don't do that. We want to keep it consistent. But you can switch to manual mode. And then in manual mode you can identify manually what that revision is going to be. So this is probably stuff you already know, but I'm just recapping it here.

So I also wanted to say, typically the type of attributes that I don't see in the Fusion Lifecycle definition or the default definition that I want to add-- and those typical attributes-- part type, whether it's an assembly or component. We have classification. So we can do it that way. But sometimes you want to put that in and attribute just to make some of your other scripting a little bit easier. The source, whether it's make or buy. Again, you can argue on whether that one's needed or not. Typically the ones I see though.

So typing, again, we talked about the different ways that you can type objects. The first one we said, don't do it. Don't try and put them in different workspaces just because it's a bill of material and you want to identify or segregate your bills of material another way. The other way you have that you can do this is classification. And the classification-- we have the classification baked into Fusion Lifecycle now where you can choose a classification and then extra attributes can be added on the object after you choose the classification. I think I have a slide on it. We're not going to really get into too much more than talking about it in this presentation.

And then you have a type attribute. So quite simply, you can give it a type attribute. And the way the old style classification works is it's a filtered list of types. And you can filter in. We will talk about filters a little bit more-- filtered lists. We'll play with that a little bit.

The last point on this slide-- again, super important. The reason we don't recommend trying to move things into separate workspaces for different typing is because they're generic holding areas. It's for our definition only. The view filters are what you use to narrow in. So again, concentrate on your view filters. It'll make your life a lot easier. Put everything in the same workspace for the same type of items. Put them in the same workspace, typically if you can.

And what's this? Oh, this. Is good. This is going to lead into the demo that we're going to play with a little bit. And this is an example of using a view filter. And I was talking about aircraft stuff before. Aircraft usually uses ATA chapters to define the different areas of the airplane. And typically you have different engineers working on the different areas of the aircraft. If I'm a propulsion expert, I wouldn't be working on wings. I'd be working on engine of cells maybe, or something like that. So that's where I was trying to give you the concept of using a view filter in the context of this ATA example.

Another thing before we get into the demo is permissions and security. And I was talking to Joe about this a little while ago. But the way you define permissions-- we have a certain rigid structure inside of Fusion Lifecycle. And what I try to do is I try and put it in Excel. And in order to communicate it to people I try and give them an idea of the way I'm going to define things, and help get them to help me out with the definition.

Again, as administrators in the system, getting those requirements and trying to communicate well on the requirements with users that have never seen the system is really, really difficult. This is the way I do it. I have an ACL matrix. And across the top is going to be roles, all the time. So whether you're looking at this one or this one, the differences is roles. What do you see that's different between the two sides here? I kind of give it away at the top here. Across the top is always roles, but what's different about these two spreadsheets? Don't all speak at once.

AUDIENCE: [INAUDIBLE]

TONY MANDATORI: Group versus permissions. Yeah, I kind of gave it away. But over here, one thing that I noticed in PLM 360 is I have really discreet permissions. I have about 70 of them. So for a given role, not only can I create, read, update, delete, but I can create, read, update, delete on every tab that I have inside the workspace. So I have tabs-- the aspects of the workspace. And I can decide who can see the tab, who can update on that tab. And that's what permissions are.

What I try to do is I try to spell out some of the ones that are out of the box. Actually this was an implementation I was working on. So in another one-- we'll use another one for the example that we're going to demo. But the idea over here is that typically we have a read-write role for a given workspace. Really, really subtle here. But I have read-write, not on everything, but for a specific workspace. So I have a role. My roles are specific to workspaces. And I think Brian-- again, he showed this in his. But he really didn't narrow in on that point.

In that point though, for that role, for that workspace, I have certain permissions that I can do. And I have people that can write or read-write, and people that can only read. And the difference is, which permissions I turn off for the different users. Now, I want to group those into groups. And what I typically see in the out-of-the-box product-- and what I don't like doing is that people try and equate the two. They try and equate a role to a group. Well you're not taking full advantage of that if you're doing that.

What you really want to do is you want to create an everyone group. To make your life easy as administrators, when somebody is hired in the company, I just want to throw them into the everyone group. Everyone gives him the ability to see the data. He's internal. He's OK. We can trust him. So let him see all the data that he needs to see. And maybe if I don't want to show him every one, because it's too much, it's overwhelming, well that everyone group can remove a couple of those workspaces so he doesn't see those workspaces because he might get confused.

Maybe I don't want the quality guys seeing some of the stuff that the engineers are doing. OK, no problem. Then what I'll try to do is by function. So I'll try and say, OK, now if I am someone that's doing document control-- actually that's a bad one. But if I'm an engineer, what do I need to see? And in this case engineers need to see the change order, and they need to see drawings, but they really didn't need to see this other stuff-- [INAUDIBLE]. They didn't need to see that, so I'll hide it from them. They didn't need to update it. So they only need to update these two objects.

So you have read-write on both the change orders and the drawings, but because they're part of everyone as well, they get the read permissions. Make your life easier. There's a different way that I could have done this, which you typically see in the out of the box product which is, I can create groups that are exactly the same as the role. But I'm handcuffing myself. I'm kind of going down a path that's going to be difficult to administer. So use your groups to kind of make life easier for you, is what I'm trying to preach here. OK, I'll get off my soapbox. But I hope you kind of understand these graphs that I was putting together. And we'll use them a little bit later as well.

The other real cool feature about Fusion Lifecycle is the ability to import from the UI. And yeah, it's got a couple of glitches, or a couple of limitations. One, it's a single workspace. You can't import across multiple workspaces. I can't import a change order and then tie all the items to it as affected items. I can't do that in this interface. But what I can do is I can import items extremely quickly. So this is your quickest way of importing. So if you're doing a data migration, what you want to do is use your item import functionality inside of Fusion Lifecycle as much as you can. Once you do that, it'll quickly get your stuff in there. And then tie the relationships together using your scripting, using your API, whatever convenient way that you define on your project. But this is super important that you try and use this as much as you can, because it's quick. Yes, sir.

AUDIENCE: [INAUDIBLE]

TONY MANDATORI: Not like this. How do you import attachments, Joe?

AUDIENCE: [INAUDIBLE]

TONY MANDATORI: That's right. And that's currently the only way of doing that. And is that going to change with Fusion Team? Yeah, you bet it's going to change. You're going to have to update your code. But that's a discussion for another day. Good question though. Thanks for asking. So you cannot import attachments through this UI.

So now, since we talked a lot, it's time for me to sit down, take a break, maybe do a demo. So what I want to do is I want to get to a workspace that I haven't done anything to. And this is my PL2207 workspace. And as you see here it's got the basic configuration. And what I want to do is I want to build something like this to hold my ATA chapters. And so earlier on we talked about what ATA chapters were. And ATA chapters were a way of dividing out the areas of the aircraft. I have a spreadsheet that I'm going to try and import. And this is going to serve as reference data for another example that we're going to do later on.

So the point of this demonstration is just to show you how simple it is to create a workspace. And hopefully I don't get it wrong. But again, typically when I go through demonstrations, the demonstrations-- I'll miss something, and that's OK. Typically as administrators you'll miss something too. But just to make sure that I have completeness in this and that I don't miss anything. And Hagay's going to stop me if I do anything wrong. New workspace. We'll call it ATA. Yeah, we'll say ATA.

And what kind of workspace do I need? Do these things need a workflow? Probably not. So I'm going to say, basic workspace. And I'm just going to save that. So that's the first step complete. I created the workspace. And that was the workspace settings tab. Now I'm going to go to the add in details tab and I'm going to add in a section.

AUDIENCE: [INAUDIBLE]

TONY MANDATORI: Yes, but, what don't you get when you do that?

AUDIENCE: [INAUDIBLE]

TONY MANDATORI: Ah. Thanks. OK. So the question was, can I add workspace workflow later on? So when I create a workspace, and I create it as a basic workspace, can I add workflow later on? The answer is, no you can't. And there's a good thing to note about that. If you think that you're going to need a workflow later on, all the objects that you create in that workspace before you convert it to a workflow-- a basic workspace with workflow-- will never, ever, ever, ever, ever get a workflow state.

So those objects will exist-- without workflow, the ones that you've created-- so just to be clear, the objects that you created before you went to basic workspace with workflow will never get a workflow state. So if you think that your workspace might need a workflow in the future, create it with a workflow right away.

AUDIENCE: [INAUDIBLE]

TONY MANDATORI: It's not really data corruption it's just that what's happening behind the scenes I think is that-- and Hagay can correct me here, but behind the scenes that I think what is happening is that these objects are being initiated and they're just not pointing to the workflow that they need to. So we'll never have one. It's not the type of object that are being created. Then you change the workspace. It says, OK, all the new objects that you create are going to get workflow. They're going to get that extra piece whenever the object's created. It's going to have that extra piece of code that runs that it links it to a workflow. So it's not really a corruption, it's just missing.

AUDIENCE: [INAUDIBLE]

TONY MANDATORI: Yeah. No, it's bad. It's bad, you're right. So is it corruption? I'll say no because I'm a happy guy and I'll try and mull things over. But yeah, these objects really should have a workflow state and they don't. So that's why, if you ever think that the objects will absolutely need a workflow state in the future, create one. Create it with workflow. It doesn't hurt to have a workflow and then hide the tab. That doesn't hurt.

If you do it this way-- the reason I'm using this one is because I don't need it. I don't think I'll ever need it. So it might be a bad idea. You might choose as a strategy for your administration to say, every object will get a workflow bar none. That's OK too. Go ahead, do it. I didn't choose to do it here but it's a good point. Thanks for bringing it up.

You kind of threw me off a little bit but I think I can recover. Section, number, chapter-- I think I want that. So I'm going to have section. And we're not going to get too fancy here. We're going to make 'em all single line texts. And section, maybe a about 50, just to make sure I have enough. Step one complete. Add field. And I think I made this one an integer so we'll do that here.

Field length-- I don't think I need more than five. So what you should be seeing here-- this is super simple. Had to do this in another product-- wouldn't be this simple. I'm not trying to sell you anything, just saying. As an administrator, I like it. This one should be longer. This one's got to be like 100, because some of those are really long chapters. So one thing you've got to remember to do is, save your layout.

Now, will I see it in my menu? Not yet. If I update my page, will I see it in my menu? Not yet. What have I forgotten to do? Somebody other than Joe, because he's going to talk all day long if I let him.

AUDIENCE: [INAUDIBLE]

TONY MANDATORI: Turn it on. Access control, that sounds better. OK, good. System configure-- ah, security. I always get that wrong. So, I need to create some roles. And what I'm going to do is, I'm going to create a new role. Not new user. What am I doing? New role. And I'm going to follow the convention with ATA read. Again, the role is specific to a workspace. Subtle here, but you've got to keep in keep that in mind.

Create role and add permissions. So the only permission that I really need here-- for the read guys, they've got to be able to view it. That's it. They've got to be able to view items. That's all I want them to do. Now, I need a read-write. Right So I need to give the administrators a way of actually making changes here. So ATA, read-write.

And you can argue with me that, you know what, it's probably only read. We have a convention of always using read-write, so I'm just going to follow it. And with these guys, not only do I want to view the items-- and I probably don't have to do that because I'll put myself in that everyone group as well. But I'll definitely need to add, edit, and delete items.

And for all the users that are defined, I want to create a group. Like I said, a good practice. A new group, let's call them everyone. Create and add users to the group. Yeah, there's only two people in here. We'll add 'em both.

AUDIENCE: [INAUDIBLE]

TONY MANDATORI: They're additive. Yeah. So there's no way of doing negative permissions inside this product. Why? Because we want to keep it simple. So, yeah, no negative permissions here. If I'm a member of multiple groups, I get everything. Combine it all together. Use that to your advantage. Again, I'm stressing that again. Use it to your advantage because what's going to happen is, it's going to simplify your administration.

Does a guy need to be changing items? OK, if he does, I'll put him in the engineers group or something. I'll make sure that I try and identify what his role is. I'll talk to him, say, what exactly were you hired to do? And I'll get you to that point over there. So again, the question was, are the permissions additive? Yes, they are. When you're a member of one group you get all those permissions. There's no subtractive permissions. You threw me off again. But OK, I can recover.

So we create a group. Did we create a group? Everyone group. Yeah, my everyone group. So I added users, but as Joe pointed out-- thank god Joe's here. Because I want everyone to have read. I don't want them to have read-write, just want them to have read. They've got to be able to see it. Admins though, OK, roles.

Got to have him to be able to read-write, because he's got to be able to administer it. Added my user, added the roles. I think I've got everything. Let's hit the button, see if it works. Main menu. Where is that guy now? Well, what's he doing there? Kind of don't want him there. All right, not a problem. Main menu designer. Where are you? Let's put you in the right place. OK.