Parent page: Server Items
Each Item in a managed content server is comprised of a series of revisions, with a new revision used to accommodate new data, each time that data is modified and committed/uploaded/released. The revision therefore reflects the progress of the Item as it undergoes changes. Or to say that the other way around, if the data entity represented by the Item changes, the revision must be incremented to reflect that.
For any revision of an Item, it is also important to reflect the current state of that revision - what stage of its 'life' it has reached. This status is referred to as the Item Revision's Lifecycle.
The lifecycle allows a company to manage the Item from a business perspective, and in accordance with company policies and practices. With this lifecycle information, people that need to use an Item in a Server - from a designer contemplating reuse of a released design 'building block', to the supply chain needing the data to fabricate and assemble a board - are able to see, at-a-glance, what stage a revision of an Item has reached in its 'life' and therefore what it can be safely used for.
Modeling the Lifecycle
While different organizations may choose to model or label the lifecycle of design items slightly differently, they will all follow a similar theme. For example, the general cycle of a product’s life will be something like: it starts as a design idea, then becomes a prototype, then goes into production, then at some point becomes obsolete and is no longer made or sold.
Using lifecycle status information on every component of a design helps to ensure that a design can only be promoted to a higher state if that new state is less than or equal to the lowest-state component within the design. For example, if a design is ready to move into production, it should only be allowed to do so if all components within it are also in production - i.e. components that are still In Prototype (or New From Design) must be promoted to In Production before the design as a whole can be promoted to that level.
In many cases, the revisions of Design Items will progress through the various lifecycle states linearly however it should not be assumed that this is the only path that can be taken. For example, some Item Revisions may end up being abandoned before they have even reached the prototyping stage. In managed content servers, the allowable states that an Item's revision can move between are defined by a Transition table included in the lifecycle definition.
A managed content server supports two levels of lifecycle management: Simple or Advanced. These essentially determine the style of management, upon which the lifecycle definitions themselves are then built. For a lifecycle definition based on the Simple management style, only states and state transitions are involved. For a lifecycle definition based on the Advanced management style, states can be further clustered into defined stages.
Both the Simple and Advanced lifecycle management styles support the same set of States (the different points at which an Item's revision can exist in its life), and Transitions (how an Item's revision moves between those States).
States, Stages and Transitions
Related page: Accessing the Detailed Item View
Each point in an Item Revision's lifecycle is referred to as a State, for example In Production. When an Item's revision changes state it is referred to as a Transition, which can only be to another State.
Lifecycle definitions based on the Advanced management style support States being clustered into Stages. Stages allow labels to be created that identify where an Item's revision is in its development. For example, it could be in Design, or in Prototype, or in Production.
An example lifecycle definition whose states are clustered into three stages.
The image below shows a snippet from the detailed Item view for an Item that employs a 3-level Revision Naming Scheme: Model, Prototype and Revision. Each Model is shown as a separate block. Within a Model, each Prototype is a sub-block. Below each Prototype are the Revisions of that Model/Prototype, then within each Revision are the different States that the revision existed in.
Example lifecycle states for various revisions of an Item.
Stages in an Advanced-style lifecycle definition can also be linked to the revision levels of the employed revision naming scheme, creating a horizontal dimension to the presentation of an Item's lifecycle, that meshes with the Item's Revision.
Default Lifecycle Definitions
The Altium NEXUS Server provides eight default lifecycle definitions. These default definitions can be used 'as is', or modified to suit company (or personal) requirements. New, custom definitions can also be added and configured, as required.
The Altium NEXUS Server provides eight default lifecycle definitions. These default definitions can be used 'as is', or modified to suit company (or personal) requirements. New, custom definitions can also be added and configured, as required.
The default lifecycle definitions are as follows:
- Altium Attachments Lifecycle
- Basic Lifecycle
- Component Lifecycle
- Extension Lifecycle
- Simple Lifecycle
- Simple Lifecycle With Approvals
- Structured Lifecycle
- Structured Lifecycle With Approvals
The lifecycle definition applied is chosen at the individual Item level, when creating an Item. Different Items can therefore have different lifecycle definitions assigned to them.
Once a defined lifecycle definition is in use by an Item in the Server, that definition can not be deleted. You can however modify the definition to some extent, including renaming it, modifying its state attributes (color, transitions, applicability, visibility), adding new states to the definition, removing any unused states, and linking stages to revision levels (where applicable). Once an Item is created and an initial release into a planned revision of that Item is made, that Item can not have its lifecycle definition changed to a different one.
Lifecycle definitions featuring dedicated approval states and transitions, effectively enable the appropriate authority to have the final say on whether or not an Item Revision can move from, for example, Design to Prototype, or from Prototype to Production.
Managing Lifecycle Definitions
From within Altium Designer, lifecycle definitions can be viewed and managed from within the Edit Lifecycle Definitions dialog. To access this dialog for the Active Server to which you are currently signed in:
- Open the Data Management - Servers page of the Preferences dialog.
- Click the Properties control, at the far right of the Active Server's entry.
- Choose the Lifecycles command from the associated menu.
Lifecycle Definitions for the Active Server are created and edited - in Altium Designer - through the Edit Lifecycle Definitions dialog. Roll the mouse over the image to see the
dialog when signed in to an Altium NEXUS Server.
Browser-base Lifecycle Management
Your managed content server provides the ability to define and manage lifecycle definitions through its browser-based interface, complementing the ability to do this through Altium Designer. And providing better visibility of the states and transitions involved, each lifecycle is built in a graphical way, showing at-a-glance the flows involved.
Defining and managing a lifecycle definition through the Server's browser-based interface is very much a visual affair. A definition is built rather like a flow diagram, using various graphical objects representing the states and sta te transitions (and stages if using an Advanced style of management).
Define your lifecycle definitions in a visual way, with graphical objects representing the stages, states, and transitions.
Adding a New Definition
To create a new Lifecycle Definition, click the Add New Definition link at the top of the Edit Lifecycle Definitions dialog. A new tab will appear in the dialog, ready to be configured.
Create your own, custom lifecycle definition.
A newly-added lifecycle definition is distinguished by a '+' suffix in its tab. This reflects that the definition is still being configured and has not yet been 'saved' to the set of lifecycle definitions for the Server.
Configuring a Definition
Use the controls available within a lifecycle definition's tab to configure that definition as required.
Once a defined lifecycle definition is in use by an Item in the Server, that definition can not be deleted. You can however modify the definition to some extent, including renaming it, modifying its state attributes (color, transitions, applicability, visibility), adding new states to the definition, removing any unused states, and linking stages to revision levels (where applicable).
First, enter a meaningful name for the definition in the Definition Name field. The tab will dynamically reflect the name entered.
Use the Lifecycle Management controls to select the style of lifecycle management - either Simple or Advanced. The simple style means there are only States and State Transitions involved. The advanced style allows definition of Stages, into which the states are clustered.
Specify name and style for the lifecycle definition.
Initial State
Use the Initial State of Revisions field to determine the starting state for an Item Revision, that is, the state for the revision in which it contains no released data - the 'pre-release state' as it were. By default, this state is named Planned. To change it, click the link and use the State Properties dialog to determine its name and a description, as well as text and background colors.
Configure the initial state for revisions.
Stages
If the Advanced style of lifecycle management is chosen, controls for adding and defining the required stages become available. A single stage - named Design - is provided by default, with the possibility to add a further two stages. To add an additional stage, simply click the Add Stage link.
Enter names for the stages as required by typing directly into the respective Stage Name field.
Add stages as required, which will be used to cluster states and create a more enriched, structured lifecycle definition.
To remove a stage, simply click the
control, to the right of the respective
Stage Name field.
States
The next step is to add the required states for the lifecycle definition. For a lifecycle definition based on the simple style of management, this will be a flat listing. For the advanced style of management, this will require adding states to the various defined stages.
Click the control below a state listing to add a new state. Use the State Properties dialog that appears to define that state, in terms of its name, description and color attributes.
Adding a state to the lifecycle definition.
A new state is added to the bottom of the list. Click on a state to select it, then use the controls to move it to the required location in the list.
When defining states for an advanced-style lifecycle definition, addition controls are available to move a state between stages. Depending on the position of the stage, push the state to the stage on the right (), or left () as required.
To edit the properties of a state, click to select it, then click on the
control, to the right of the state name. To delete a selected state, use the
control.
Example states defined across a two-stage lifecycle definition.
Transitions
The last step is to define the State Transitions - the paths between the different states. Click to select a state, then click the control to the right of the state name to add a new state transition. Use the State Transition Properties dialog that appears to define the transition, in terms of its name, target (next) state, menu text, and permissions.
Adding a state transition.
The
Menu Text must be defined. This text will appear in the
Item view (or
Lifecycle aspect view in the
Explorer panel) when right-clicking on an Item Revision to transition it to a new state.
When entering menu text, use the entry $RevisionId as a placeholder for the Revision ID. For example, considering revision 01.A.1 of a particular Server Item, entering the menu text Promote $RevisionId to In Production will result in the menu displaying the entry Promote 01.A.1 to In Production.
A new transition is added to the bottom of the list. Click on a transition to select it, then use the controls beneath the state listing to move it to the required location in the list.
Where the next state for a transition resides in a different stage, an indication arrow - in the color of the target state - will be displayed to show this.
Example of fully defined states and state transitions across a two-stage lifecycle definition. Arrows are used to indicate transitions across stages.
To edit the properties of a transition, click to select it, then click on the
control, to the right of the transition's name. To delete a selected transition, use the
control.
To completely remove all defined states and transitions for a simple lifecycle definition, or all states and transitions for a specific stage in an advanced lifecycle definition, use the Clear command, available from the applicable right-click context menu.
State Transition Permissions
The managed content server provides great flexibility for deciding who can make particular state transitions for an Item Revision in a Server - the action of transitioning a revision from one state, to another different state, as defined by the lifecycle definition employed for its parent Item. It is possible to prohibit standard (non-administrative) users from transitioning between specific lifecycle states on-the-fly, while opening up permissions to more than just Server Administrators. You have the ability to specify permissions at the global level - as part of global Server operation permissions - and also at the individual state transition level. The latter act in conjunction with those settings at the global level, and facilitate fine-tuning of permissions for those more important transitions (for example setting an Item Revision to be Ready for Production).
Alternatively, standard users can be made to request approval for specific state transitions. In turn, these Approval Requests are sent to, viewed, and acted upon, by those designated to be members of one or more Approval Groups.
With various levels of permission control, you can define a lifecycle state transition strategy that adheres to your organization's preferred approach.
In summary, permissions can be defined at two levels:
Example Default Lifecycle States and Transitions
The following table provides a listing of states and state transitions used in the default Structured Lifecycle With Approvals lifecycle definition.
Current State
|
Possible Transitions
|
Transitions to State
|
Comment
|
Planned
|
Perform Release
|
New From Design
|
All new, unreleased Item Revisions start in the Planned state. An Item Revision in this state cannot have its lifecycle status manually changed, it can only be released, automatically transitioning to New from Design.
|
New from Design
|
Set Ready for Prototype
|
Pending Prototype Approval
|
Indicates that this Item Revision has been released so is now New from Design. Once ready to go for prototyping, it can be transitioned to Pending Prototype Approval.
|
|
Abandon Design
|
Abandoned
|
If the Item Revision is deemed not necessary at this stage, it can be Abandoned.
|
Pending Prototype Approval
|
Approve for Prototype
|
In Prototype
|
Item Revision is ready to be approved for prototyping. Successful approval transitions the revision to the In Prototype state.
|
|
Disapprove for Prototype
|
New From Design
|
If an Item Revision fails to be approved for prototyping, it is transitioned back to New from Design.
|
Abandoned
|
Recover Design
|
New from Design
|
An abandoned Item Revision can be recovered, restoring it to New from Design.
|
In Prototype
|
Set Ready for Production
|
Pending Production Approval
|
The Item Revision is In Prototype, typically this is state when you are ready to assemble the first physical prototypes. If it passes prototype testing then it can be transitioned to Pending Production Approval.
|
|
Rollback to Design
|
New from Design
|
If the Item Revision fails testing, then it should be transitioned back to New from Design.
|
|
Closed Prototype
|
Closed Prototype
|
If the Item Revision cannot be developed any further (perhaps it needs design changes, requiring a new Revision), then transition it to Closed Prototype.
|
Pending Production Approval
|
Approve for Production
|
In Production
|
Item Revision is ready to be approved for production. Successful approval transitions the revision to the In Production state.
|
|
Disapprove for Production
|
In Prototype
|
If the Item Revision cannot be released to production, it can transitioned back to In Prototype.
|
Closed Prototype
|
Recover Prototype
|
In Prototype
|
A Closed Prototype is one that is considered unable to be further developed. If it is possible to continue with it, it can be transitioned back to In Prototype.
|
In Production
|
Rollback to Prototype
|
In Prototype
|
If an Item Revision is in Production but there is some reason it cannot be produced, it can be transitioned back to In Prototype.
|
|
Deprecate
|
Deprecated
|
If you are planning to stop making the Item at its current revision (perhaps a component used on the board is becoming difficult to buy), you transition it to be Deprecated.
|
|
Obsolete Production Item
|
Obsolete
|
If an Item Revision that is currently In Production is no longer able to be made, it can be immediately Obsoleted.
|
Deprecated
|
Obsolete Deprecated Item
|
Obsolete
|
Deprecated typically means production can continue from existing stock, but new components for that Item Revision should not be ordered. If this changes and such stock is no longer available, the revision can be made Obsolete.
|
|
Reactivate Deprecated Item
|
In Production
|
Restore a Deprecated Item to be In Production.
|
Obsolete
|
Reactivate Obsolete Item
|
In Production
|
Restore an Obsolete Item to be In Production.
|
|
Deprecate Obsolete Item
|
Deprecated
|
Restore an Obsolete Item to Deprecated.
|
Linking Stages to Levels of the Revision Naming Scheme
Revisions and Lifecycle States can be incremented from the applicable right-click menu in the Item view, or the Explorer panel. While establishing a new Revision and Promoting the Lifecycle are completely separate tasks that are done for different reasons (a new revision when there is a design change, a new lifecycle state to reflect the enhanced usability of that Item Revision), they are inter-related.
For a lifecycle definition based on the advanced style of management, the defined stages can be linked to the revision levels of the employed revision naming scheme. Do this using the option at the bottom of the Edit Lifecycle Definitions dialog.
Option to link stages to revision levels.
This creates a relationship between the Lifecycle State and the Revision Level. What that means is when an Item Revision's Lifecycle is incremented so that it moves from a state in one stage to a state in another stage, then the available Revision modification type commands - on the right-click menu - will change too.
Consider the default lifecycle definition Structured Lifecycle With Approvals, and a 3-level Revision naming Scheme (with levels for Revision, Prototype and Model). If an Item Revision is in the state New From Design, in the first stage, then the Revision-type options on the right-click menu include: establish a new Revision; a new Prototype; or a new Model.
If the lifecycle is then incremented to the point where it is now In Prototype, it will have moved to the second stage. Right-clicking on it, the available Revision-type options now include: establish a new Prototype; or a new Model, that is, there is no option to start a new Revision. This behavior is intuitively expected - if the design has progressed to Prototype, then if a design change was needed, a new Prototype would be needed, or even a new Model, depending on the scope of that change.
Once the Item Revision reaches the In Production state, in the third stage, the Revision-type option to establish a new model is available only, again as expected.
When linked, revision-type commands change as the Item Revision's lifecycle state progresses through the different stages defined.
Saving a Definition
Whether a new lifecycle definition has been added, or an existing lifecycle definition has been modified in some way, that lifecycle definition must be saved. Although there is no actual 'save' command, there are controls available to perform this:
- For a new lifecycle definition - distinguished by a '+' suffix - either use the Add Definition control (at the top-right of the definition's tab), or click the dialog's main Apply button.
- For an existing lifecycle definition that has been modified - distinguished by a '*' suffix - either use the Apply Changes control (at the top-right of the definition's tab), or click the dialog's main Apply button.
In either case the suffix will be removed and the definition will be added as part of the set of lifecycle definitions available to the Server.
Using the dialog's main Apply button provides batch-style 'saving' while keeping the dialog open.
Ensure that a lifecycle definition has truly been added, or changes have been applied, prior to clicking the OK button. Doing so without 'saving' the definition will result in closing the dialog and the changes being lost. In addition, where more than just the first state has been defined for a lifecycle definition, transitions to effectively connect those states must be defined, or the changes cannot be applied. An error dialog will flag this situation, listing the 'unreachable' states.
In the spirit of facilitating a clear and transparent audit trail - of whom changed what, and when - details of when a lifecycle definition was last modified are provided at the bottom-right of its tab.
Identifying when a lifecycle definition was last modified, and by whom.
At any point prior to applying changes for the active definition, those changes can be 'rewound' in full by clicking the Reset control, at the top-right of that definition's tab.
Renaming a Definition
This feature is only available for a user with administrative privileges for the Server.
To rename an existing, used lifecycle definition:
- Access the Edit Lifecycle Definitions dialog for the Active Server.
- Click the tab for the definition whose name you need to change.
- Modify the name in the Definition Name field.
Example of renaming a lifecycle definition, and verifying the change in the properties of an Item already using that definition.
Cloning a Definition
New lifecycle definitions do not need to be created from scratch. The Edit Lifecycle Definitions dialog provides the ability to quickly clone any of the existing definitions. To do so, make the required lifecycle definition that is to be cloned, the active definition, then click the Clone control at the top-right of that definition's tab.
An exact copy of the definition will be taken, creating a new definition with initial default name of New Lifecycle Definition. Rename as required and click the Add Definition control (or the main Apply button) to effectively save the new definition.
Deleting a Definition
To delete an existing lifecycle definition, simply select it - making it the active definition in the Edit Lifecycle Definitions dialog - then click the Delete control, at the top-right of the definition's tab.
A lifecycle definition that is currently being used by an Item in the Server cannot be deleted.
Permanent deletion of a lifecycle definition is effected upon clicking the dialog's main Apply button (or clicking OK). Prior to this, the delete operation can be undone by clicking the Undo control, at the top-right of the dialog.
The operation to delete lifecycle definitions can be undone.
Exporting and Importing Definitions
User-defined lifecycle definitions are available for use only in the managed content server in which they are defined. Providing the ability to port definitions between Servers, the Edit Lifecycle Definitions dialog features Export and Import capabilities.
The lifecycle definition is stored in a Lifecycle Definition file (*.definition).
To export a lifecycle definition, click on the Export control, at the top-right of its tab. Use the subsequent Save Lifecycle Definition dialog to determine where, and under what name, the file is to be saved.
To import a lifecycle definition, click on the Import Definition control, at the top of the Edit Lifecycle Definitions dialog (above the tabbed definitions). Use the Open Lifecycle Definition dialog to browse to, and open, the required Lifecycle Definition file. The lifecycle definition will be added to the list of existing lifecycle definitions available to the Server.
An imported lifecycle definition appears as a new definition, complete with '+' suffix. Ensure that it is 'saved' by clicking the Add Definition control, or the dialog's main Apply button.
If a default lifecycle definition has inadvertently been deleted, it can be restored through use of the Import feature. All default lifecycle definition files are available in the \Program Files\Altium\AD<Version>\System\EDMSTemplates folder, for a default Altium Designer installation.
If a default lifecycle definition has inadvertently been deleted, it can be restored through use of the Import feature. All default lifecycle definition files are available in the \Program Files\Altium\Nexus\System\EDMSTemplates folder, for a default Altium NEXUS installation.
Controlling the Use of a Lifecycle Definition
Control over which Item types can use a particular lifecycle definition, can be defined and enabled at a global level, when defining each definition. If this feature is enabled, then only those allowed definitions will be available when choosing the lifecycle definition for a particular Item type. This gives you that extra level of control to ensure created Items of a particular type only use the lifecycle definition you require.
Control is performed from within the Content Types dialog. Click on the tab for the particular definition whose access you wish to configure, then click the Content Types link, at the top-right of the definition's tab.
Accessing the Content Types dialog - command central for determining which Item types can use the lifecycle definition being configured.
The Content Types dialog lists all of the supported Item types that can be created in your active managed content server. The option above the list - Control Lifecycle Definition per Content Type - provides global control over whether the feature is active (enabled) or not (disabled), for that particular definition. Enable this option, then enable the associated Use option for each Item type that you would like to be able to use that definition.
Default Configurations
The following usage (per Item/Content type) configurations are evident for each default lifecycle definition, when installing a new instance of a managed content server.
- Altium Attachments Lifecycle - none.
- Basic Lifecycle
- BOM Template
- Project
- Script
- Part Choice List
- 3D Model
- Project Review Package
- Altium Designer Preferences
- Draftsman Document Template
- Binary File
- Draftsman Sheet Template
- Layerstack
- Component Template
- Datasheet
- Project Template
- Component Lifecycle
- Footprint
- Symbol
- Component
- Simulation Model
- Extension Lifecycle
- DXP Platform
- DXP SDK
- DXP Plugin
- Simple Lifecycle
- Schematic Template
- Managed Schematic Sheet
- OutputJob
- Simple Lifecycle With Approvals - none.
- Structured Lifecycle
- PCB Fabrication Data
- PCB Assembly Data
- PCB Project Design
- Structured Lifecycle With Approvals - none.
Switching between Advanced and Simple Lifecycle Management Modes
You can switch an existing lifecycle definition from using the Advanced style of lifecycle management (states, state transitions, and stages) to using the Simple style of management (states and state transitions only). When you enable the Simple option, the Confirm Merge States dialog will appear. Use this dialog to determine how to handle the switch as follows:
- Click Yes - all defined states (and state transitions) across Stages 1, 2, and 3, are merged into a single flat listing of states.
- Click No - all defined states (and state transitions) in Stages 2 and 3 are deleted. Only those states (and state transitions) in Stage 1 (the left-most stage) will remain in a single flat listing of states.
Switch style of lifecycle management - from Advanced to Simple - with control over how the states (and state transitions) in other stages are handled.