Save
OK, so now we have taken a look at what your default Item lifecycle scheme looks like, lets focus on whats new in terms of creating your new item lifecycle scheme.
Why do we need more than one item lifecycle scheme though? Good question. Many users won't, but if you are importing purchased components from third parties there may be a different default state for those items and different rules about file access. Likewise for library files or non-CAD based items.
To accommodate these changes we can build a separate Item Category with its own rules and assign an alternate lifecycle scheme OR add multiple lifecycles to one of the default item categories and we can change lifectycle schemes on demand as we do with files:
In terms though of creating your lifecycle scheme, for the most part this is as it has always been, we specify the scheme name, specify the states we want, how and who is allowed to transition between the states and who has access to the object(s) when we are in each of the states.
To build your new scheme you can copy one of the existing schemes (Copy option in the Lifecycle Definitions dialog) or just create new and enter in your new states – each state should have a name and a description (preferably ones that make sense).
You likely should have a "working" state where users can make changes to the item, at least one released state and an archive state for obsoleted / unused items that are used as a reference. Typically one or more review states are used, but that really comes down to your company process.
Once we have identified some states we need to control how to move between states. Unlike the old process where there was a rigid path between states and limited actions (bump revision or not), here we can choose our own adventure and control what occurs on transition.
As we mentioned in the previous post, traditionally anyone that had Item level permissions could transition an Item between states, but this was very inflexible when we consider a large organisation with different divisions and areas of responsibility. To work with that the administrator can now specify groups or specific users with item permission to progress item approvals.
In order to restrict transition between two states and define the correct release process, the administrator simply blocks all users from making that transition (Everyone = Deny).
The next thing to address in the transitions is to specify some rules, this is a combination of the criteria and actions which must be satisfied before the transition is allowed.
From a criteria perspective, the administrator can now select Item properties to filter down just to item details and ensure for example that the Item has a description or a title, or that all item properties are compliant (filled out correctly) before the Item can progress.
Now the administrator can select the actions on transition, there are 4 new options on this tab that deal with items as well as the new obsolete state for files, folders and items.
Firstly the administrator should specify whether or not all child items need to be in a specific released state (or at least not obsolete) prior to transition, the legacy behavior of course required all items to be released and it is typically best practice to ensure that you do not release an item with dependents that are not also released.
Administrator should then check if the item file links are up to date, the legacy requirement here was that all attached files should be the latest before you release an item. Again this is a pretty good practice to follow (so consumers are seeing the right linked files), but you can choose now which states this really matters for and also what type of links matter – it may only be "primary" links you care about (the file which the item was created from or extracts all its data from).
Another new feature is "Check that associated item file links are released" which makes sure that, if desired, the files linked to your item are all released by their own lifecycle definitions, and you can restrict this by link or file type as well (Primary Link, Design Document etc).
Finally, we need to decide when to bump the Item revision – this too is now managed on the transition tab, simply select the state change that will prompt a revision change (be it primary or secondary/tertiary) and enable it.
Once these settings are configured for every possible state transition (or the transition disabled) we can start to look at the actual state behaviors including the new linked file security, but we will save that for part 2!
-Allan
