Events and Objects for Approval
You can add approval policies for the following combinations of events and object types:
Event Type | Supported Object Types | Supported Approval Actions |
PreStateChange | Asset Policy |  Initiate Approval Initiate Group-dependent Approval |
OnConsumerRegistration | Asset | Initiate Approval Initiate Group-dependent Approval |
Using the Initiate Approval Action
You use the Initiate Approval action when you want to define an approval process that applies to all of the users who submit requests that trigger the policy. If you need to apply the approval process selectively, that is, if only certain groups of users require approval, or if different groups of users require authorization from different groups of approvers, use the Initiate Group-dependent Approval action instead.
The parameters required to define the action include the name of the approval flow that the action initiates, the name of the approver groups (that is, the groups of users who are allowed to approve requests that trigger the policy) and email addresses of users who should be informed of the progress of the action.
Using the Initiate Group-Dependent Approval Action
When you want a policy to initiate an approval process for some groups of requestors and not for others, or when you need to route requests to different approvers based on the user group to which a requestor belongs, you use the Initiate Group-dependent Approval action.
The parameters required to define the action include the name of the approval flow that the action initiates, the name of the approver groups (that is, the groups of users who are allowed to approve requests that trigger the policy), the names of the related triggering groups (that is, the groups of members whose requests require approval), and email addresses of users who should be informed of the progress of the action.
You can route approvals to different approver groups based on the triggering group to which the requestor belongs. For example, you could configure the action to route requests to the approver groups Approvers-A and Approvers-B when a requestor belongs to a particular triggering group.
Points to consider when using the Initiate Group-dependent Approval action:
If a requestor does not belong to any of the groups specified in the
Triggering Groups parameter,
CentraSite does not even initiate an approval workflow. Approval is waived and
CentraSite simply executes the next action in the policy. (Be aware that, because the request does not enter the approval framework, requests that are waived do not appear in the Approval History log.)
The UI dialog allows you to combine triggering groups and approval groups into sets, where each set defines one or more triggering groups and the associated approver groups. You can specify multiple sets and
CentraSite processes each set in the order given in the dialog. When it encounters a set whose
Triggering Groups parameter includes a user group to which the requestor belongs, it immediately initiates an approval workflow based on that set and ignores any remaining sets in the dialog. In other words, if the requestor is a member of multiple
Triggering Groups, approval is determined by whichever of those groups appears first in the dialog.
If a requestor is a member of both
Triggering Groups and a member of
Approver Group in the same triggering group/approver group combination, the request is auto-approved.
Switching the State of an Object when an Approval Request is Rejected
By default, an object's lifecycle state is not changed when an approval request is rejected. For example, let's say that object ABC is in the Tested state and an approval request is submitted to switch object ABC to the Production state. If the approval request is rejected, object ABC stays in the Tested state. For some approval work-flows, however, you might want to switch objects to a particular state when they are rejected. To do this you use the Reject State parameter.
Important: If you use this option, make sure that the lifecycle model provides a transition from the state(s) that an object might be in when the approval policy executes and the state that you specify in the Reject State parameter. Otherwise, the approval engine will not be able to switch the target object to the specified state when a rejection occurs.
Also be aware that you can specify only one state in the Reject State parameter. Therefore, if an approval policy applies to objects with different lifecycle models, the Reject State can apply to only one of those models. For example, let's say you use the same approval policy for both XML schema and services, but these two asset types follow different lifecycle models. If you set the Reject State to a state in the lifecycle model for XML schema, only XML schema will switch to this state when an approval request is rejected. Services, when rejected, will simply remain in their current state. If you want to specify one reject state for XML schema and another for services, you must create a separate approval policy for each type.