Creating a Different Lifecycle Path for a New Version of an Asset
For certain asset types, you might want to define separate lifecycle paths for new instances of an asset and new versions of an asset. For example, in a lifecycle for an XML schema like the one shown below, you might want new versions of existing schemas to bypass the Proposed state and go directly to the Design state.
Alternate Lifecycle Path for a New Version of an Asset
Creating an alternate path in a lifecycle requires the use of policies that conditionally change the state of an asset depending on the way in which the asset is classified. In the example shown above, this is achieved by doing the following:
Defining an initial state (the New state) through which all schemas (new or versioned) pass.
Creating policies that execute immediately after a schema enters the New state. These policies switch the schema to the Proposed state or the Design state depending whether the schema is classified as New or Existing.
To implement a lifecycle like the one above, you must add to the XML Schema asset type a Classification attribute that can be used to classify a schema as either New or Existing. (You would need to create a custom taxonomy to support this attribute.)
You must also create two policies that execute after a schema enters the New state: one policy that executes when a New schema enters the New state (this policy will switch the schema to the Proposed state), and one policy that executes when an Existing schema enters the New state (this policy switches the schema to the Design state).
Note: | The example above describes how you can use policies to conditionally route an asset between two alternate paths when an asset enters the initial state of its lifecycle. However, you can use this same technique to establish alternate paths at any point in the asset's lifecycle. Its use is not limited to the initial state. |
