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 is to execute immediately before CentraSite actually modifies the asset's state (which is called a PreStateChange event) or immediately after CentraSite modifies the asset's state (a PostStateChange event).

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

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

There are, of course, 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 PreStateChange policy. But generally speaking, you want to perform approval and validation actions in a PreStateChange policy, and you want to 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 PostStateChange policy.