For a given object type (say Service), each organization can define and activate its own lifecycle model, so that there are several models that can control the Service type. However, per organization only one lifecycle model can be active. When a new Service instance is created, then the user creating belongs to an organization and that organization's active lifecycle model is used to control the particular Service instance.

It is possible to define a lifecycle model which consists of multiple nodes (registries) to make up one overall model. Each node only knows the model for the current node. It also knows the nodes that make up the complete lifecycle model and where they are.

When a lifecycle model is stored in CentraSite, it must be a valid state machine. This specifically means that all of the following semantic rules must be checked by CentraSite:

Lifecycle models can be applied to:

CentraSite does not require you to apply lifecycle models to the assets in your registry. You can create and maintain an asset catalog without them. However, most of CentraSite's policy-based governance controls (for example, enforcing approval processes, validating attribute settings) can only be applied to assets that have an associated lifecycle model. The use of lifecycle models also makes it easier to manage the assignment of permissions (for example, granting View permissions to additional organizations) as an asset moves through its lifecycle.

If you want to use design/change-time policies to impose governance controls on a particular type of asset or you want to automate routine management tasks at certain points in the asset's lifecycle (such as setting permission assignments), associate a lifecycle model with the asset type.

When you define a lifecycle model, you specify the asset types to which the model applies. Because different types of assets usually have different development paths, you generally create models that are specific to a single asset type (that is, one model for Service assets, one model for XML Schema assets, one model for Business Processes, and so on). However, if multiple asset types have the same lifecycle path, you can apply the same lifecycle model to them all.

When you apply the same lifecycle model to multiple asset types, you do not necessarily have to apply the same state-change policies to those types. You can trigger different policies depending on the type of asset whose state is changed. If you were using the lifecycle model for XML Schema and DTDs shown in the figure above, you might create one policy that executes when an XML Schema switches to the Available state and another policy that executes when a DTD switches to the Available state.

If an active lifecycle model is already associated with a particular type within an organization, you cannot assign another lifecycle model to that type. In other words, a particular object type can be associated with one and only one lifecycle model within a particular organization. If you want to switch an object type to a different lifecycle model, you must disassociate it with the current model and then assign it to the new model.

You can associate a lifecycle model with virtual asset type. When you apply lifecycle model to a virtual asset type, you do not necessarily have to apply the same lifecycle model as its base type. You can create a lifecycle model specific to the virtual asset type.

You can configure a virtual type to follow the same lifecycle model as its base type or you can give the virtual type its own lifecycle model to follow. Whether a virtual type follows the lifecycle model of its base type is determined by the type's Inherit Base Type LCM setting.

When the Inherit Base Type LCM option is selected for a virtual type, the virtual type automatically inherits its lifecycle model from the base type if the virtual type does not have an assigned lifecycle model of its own. (In other words, the lifecycle model for the base type serves as the default lifecycle model for the virtual type. CentraSite applies the lifecycle model of the base type to the virtual type only when the virtual type has no other lifecycle model assigned to it.)

If the Inherit Base Type LCM option is disabled, the lifecycle of the virtual type is completely independent of the lifecycle of the base type. The virtual type will only have lifecycle model if you explicitly assign one to it.

The following table summarizes how lifecycle model is applied to a virtual type depending on the state of the Inherit Base Type LCM option.

Each state that you define in a lifecycle model includes a set of optional state permissions. State permissions enable you to restrict who can transition assets to a specified state. You can assign state permissions to individual users or to groups.

If you do not explicitly assign permissions to a state, any user with Modify permission on an object can switch the object to that state.

When you assign permissions to a state, two sets of users are allowed to switch an asset to that state: the set of users to which you explicitly grant state permission and users who have implicit permission to switch lifecycle states. The set of users who have implicit permission to switch lifecycle states are:

Note that the group of users with implicit permission to switch states does not include the owner of the asset itself. If you want to give asset owners the ability to switch their assets to a particular state, you must explicitly include them using the state permission settings.

Also note that granting state permission to a user does not, in itself, give the user the ability to switch an asset to that state. The user must also have Modify permission on the asset itself. For example, let's say you give the Users group for organization ABC permission to switch assets to the Development state. Doing this does not mean that any user in organization ABC can switch the assets in organization ABC to the Development state. It means that any user in organization ABC with Modify permission on an asset can switch that asset to the Development state.

You can configure design/change-time policies to execute during the transition points in an asset's lifecycle. For example, you might apply a policy that gives View permission to a specified group of users when an asset enters the Operational state, or you might apply a policy that obtains approvals from a review group before an asset enters the Development state.

When you create a policy that executes on a state change event, you specify whether the policy should execute immediately before CentraSite actually modifies the asset's state (which is called a Pre-State Change event) or immediately after CentraSite modifies the asset's state (a Post-State Change event).

Generally, you execute policies that perform approval and validation actions on the Pre-State Change event. In other words, you use Pre-State Change policies to ensure that an asset satisfies the entry criteria for a given state.

On a Post-State Change event, you typically execute policies that update the asset (for example, granting instance-level permissions to the users who need to work with the asset in the next phase of its lifecycle) or issue notifications (for example, sending an email). In short, you use Post-State Change policies to execute actions that are to be carried out only if the asset's state is switched successfully.

There are, exceptions to the generalizations above. Under some circumstances you might want to set an asset's instance-level permissions or update its attributes in a Pre-State Change policy. That is you want to perform approval and validation actions in a Pre-State Change policy, and issue notifications and perform state-certain actions (that is, actions that should occur only after an object's state has been successfully switched) in a Post-State Change policy.