Be aware that in a single-stage lifecycle design like the one described above, the user who enters the XML schema into the catalog retains ownership of the schema throughout its entire lifecycle. Consequently, when the XML schema reaches the Available state in this lifecycle, the original owner (and any other user with Manage Assets permission within the owner's organization) retains the ability to edit and delete the schema. The schema will not be under the sole control of the Operations organization. To address this issue, you might want to move the asset into the Operations organization when it reaches the Available state.

In any lifecycle design that uses approval polices, it is important to ensure that the members of the approval groups have View permission on the assets that they will be asked to approve. Without View permission on the asset, an approver cannot process an approval request on that asset. To ensure that the appropriate permissions are in effect when an asset reaches an approver, consider including an action in the approval policy that grants View permission to the approval group just before the policy executes the approval action.

Generally speaking, to change an asset to a particular state, a user must have state permission on that state and have Modify permission on the asset itself. However, if the state change triggers a policy that sets instance-level permissions on the asset, the user who triggers the policy must have Full permission on the asset. Otherwise the policy will fail. Thus, if your lifecycle design uses policies to set instance-level permissions on an asset during certain state changes, make sure that you give the users who will make those state changes Full permission on the asset.