About Lifecycles

A lifecycle consists of the individual states, and the rules that control how the content moves from one state to another.

This image shows a sample lifecycle:

Each box shows a lifecycle state. The lines with arrows from one state to another show which states the content can move to from that state. A right-pointing arrow means the content can be promoted to that state. A left-pointing arrow means the content can be demoted to that state. The arrows between states are called transitions.

The table beneath the graph lists any changes made to the default maturity graph.

The out-of-the-box business processes speed and simplify work. Many aspects of these business processes are implemented within lifecycles. For example, object access rights are defined and associated with lifecycle states. The apps use triggers attached to states to execute control checks when a user promotes content. Any transitions or states sensitive to proper workflow cannot be removed. In addition, the lifecycle for specific content types can restrict where you can add additional transitions.

The content could have rules associated with a transition. Rules define conditions that must be met prior to promoting the content to the next state. The Maturity Graph page lists the rules for a lifecycle for a selected transition.

For lifecycles used in web apps, the transition works in both directions. That is, if a transition exists from the Frozen to the Released state, then if the content is in the Release state, users can also demote that content from Released to Frozen. Native apps use a Change Maturity function to move the content state forward (the same as promoting in a web app). However, to move status backward (demoting in web apps), the lifecycle must have a backward transition. In the above example, the lifecycle shows a transition from In Work to Frozen. It also has a transition from Frozen back to In Work.

Lifecycles in web apps also show if signatures or routes must be completed before you can promote content to a state. Native apps do not support signatures and routes.

When editing lifecycles, you can:

• Delete states that do not have a lock
• Restore previously-deleted states
• Rename transitions
• Add or remove transitions between states
• Add or remove transition controls (rules) to transitions

You cannot add new states to a lifecycle.

When you edit a state name, you changes its NLS value.

Native apps store the NLS state names for PLMEntity content types in files on the local computer. After changing state names, you need to update the NLS files on the computers running native apps, then restart the application server.

Users see and use the new state names when:

• Editing properties and viewing attributes
• Searching for content
• Viewing lifecycle information for BOM parts, if you collaborate the physical product with the BOM
• Viewing lifecycle pages in web apps

For classic web apps, the 3DSpace Service automatically updates the state names for engineering content types and you do not need to take any further actions.

You can enter the new state name in any language, however, new states names will not be translated into other languages.

Many business processes implemented by various apps are tightly related to lifecycle state definition. Removing states affects these business processes.

You cannot remove states required for the correct functioning of the system. For example, content is created in an initial state, so you cannot remove that state (Private). In many cases, you also cannot remove the final state (Obsolete).

This table lists the states for design definition and development content types, and what happens if you remove a state. You cannot remove states from content types managed by Engineering BOM Management.

Content type	State Name	What Happens If You Remove
Engineering Definition Engineering Evaluation Engineering Resource	Private	Cannot be removed.
	In Work	This state allows the co-author community to access and modify the collaborative space content. When creating a Major version, the new major version is in the In Work state.
	Frozen	This state is intended for the Contributor role for doing validation work. Removing this state means no work for the Contributor.
	Released	No effect.
	Obsolete	Cannot be removed.
Development Part	In Work	Cannot be removed.
	Frozen	This state is intended for the Contributor role for doing validation work. Removing this state means no work for the Contributor.
	Released	Cannot be removed.
	Obsolete	No effect.
Customer Relationship	Private	Cannot be removed.
	In Work	This state allows the co-author community to access and modify the collaborative space content.
	Frozen	This state is intended for the Contributor role for doing validation work. Removing this state means no work for the Contributor.
	Released	No effect.

When you remove a state, any existing content will use the changed lifecycle. That is, content can never be promoted to a state that has been removed. In addition, you also remove the transitions to and from that state. Any transition controls or triggers associated with those transitions are also removed. When you try to remove a state, the app checks if any existing content is in that state, and if so, shows a message. If you delete the state anyway, that content cannot be promoted or demoted. You can cancel the change, and promote or demote all the content, and then delete the state.

For native apps, any incoming transitions from a removed state no longer show in the Change Maturity dialog box. The state continues to show in the advanced search and in the Compass. This allows you so search for any existing objects might still exist in the database in that state.

If you removed any states, the user sees a system-internal state (named "Dummy") in the State field when using full-text search.

Out-of-the-box, the apps do not control or check content regarding the maturity of aggregated content before it is promoted. You can add transition controls that verify the states of child content (for example, instances in a product structure) prior to allowing the promotion of that parent content.

State changes apply to all types governed by a policy, but transition controls can be based on specific types.

One type of control allows you to define who can promote that content. For example, the Reject on Contributor or Reject on Author role means that people with those roles cannot promote the content, and someone with a higher role can promote it. When the Reject on Contributor control is defined, an Author or Leader can promote the content. When the Reject on Author control is defined, a Leader can promote.

As an example, a simple product structure, a wheel assembly, includes a tire and a rim. When you promote the wheel assembly to the Frozen state, the tire and the rim also need to be promoted to the Frozen state. However, any Evaluation or Resource content related to the wheel assembly probably might not need to be promoted.

In addition, before you can promote the wheel assembly to the Released state, Resource content (such as materials and bolts) and Evaluation content (such as strength analysis) must already be promoted to the Released state.

You can configure predefined controls on transitions to check that the maturity status of child content is consistent with the parent content requirements. Not all content types support all control types.

The "Reject if any of the Governed Children is not on Target State" rule (available for Development Part and Production Part lifecycles) verifies the states of child content before allowing the promotion of the parent content. If you configure this transition control, you might not be able to promote multiple objects at the same time. This rule lets you specify to check "All Children types", or filter which direct children of the content should be checked (implying that the lifecycle state of any other child content is not verified at promotion).

Lifecycle checks configured in previous releases using former typing are migrated automatically when upgrading to a release that uses unified typing. Lifecycle checks added on transitions from a REMOVED state no longer display after migration.