CentraSite 10.11 | CentraSite User’s Guide | Policy Management | Built-In Design/Change-Time Actions Reference | Initiate Group-Dependent Approval
 
Initiate Group-Dependent Approval
Initiates an approval workflow based on the group to which the requestor belongs. If the requestor does not belong to any of the groups specified in the Triggering Groups array, approval is waived and the action is considered to be completed successfully.
CAUTION:
When you use this action on the Pre-State Change event, only certain kinds of actions can be executed after this action in an approval policy. Some actions, if they occur after this action, will cause the policy to fail.
Note:
To use the email options provided by this action, CentraSite must have a connection to an SMTP email server.
If You Migrate this Action from a Pre-8.2 Release
If you have a policy that contains this action and the policy was created prior to version 8.2, that policy continues to exhibit the old email-notification behavior (that is, it continues to send the earlier version's standard email message to approvers). If you want to use the email-notification enhancements that were introduced in version 8.2, simply edit the policy and enable the email parameters in the Approval action.
Event Scope
Pre-State Change
OnConsumerRegistration
Object Scope
This action can be enforced on any object type that the policy engine supports.
Input Parameters
User
(String). The user name that is used together with the Password parameter as authentication credentials for performing a lifecycle model state change on a service asset. The credentials are stored in the approval request and passed to the web service for completing the approval. The user specified must have the permissions required to perform the state change.
This parameter is only visible to users with the CentraSite Administrator role.
Password
(String). The password that is used together with the User parameter as authentication credentials.
This parameter is only visible to users with the CentraSiteAdministrator role.
Approval
(Object). (Array). The list of groups whose membership determines whether the request requires approval, and if so, to which group of approvers the request is to be routed. Each object in the Approval array must contain the following information:
Parameter
Description
Triggering Groups
(String). (Array).The user group (or groups) that identifies the users whose requests must be approved.
Approval Flow Name
(String). The name to be given to the approval workflow that this action initiates. This name serves to identify the workflow when activity relating to it appears in the Approval History log or an approver's inbox.
An Approval Flow Name can contain any combination of characters, including a space.
You can also include substitution tokens in the name to incorporate data from the target object on which the policy is acting. For a list of the allowed tokens, see the list of Substitution Tokens shown in the Send Email Notification action.
Approver Group
(String). (Array). The user group (or groups) that identifies the set of users who are authorized to approve the requested operation.
Note:
If the user groups specified in Approver Group are empty at enforcement time, the user's request is auto-approved.
Approval is needed from
(String). The manner in which the approval is to be processed as follows:
Value
Description
AnyOne
(Default). The request can be approved or rejected by any single user in Approver Group. In this mode, only one user from the set of authorized approvers is required to approve or reject the request.
EveryOne
The request must be approved by all users specified in Approver Group. (It does not matter in which order the approvals are issued.) A single rejection will cause the request to be rejected.
Reject State
The lifecycle state that is to be assigned to the object if the approval request is rejected. If this parameter is not specified, the object's lifecycle state does not change when a rejection occurs.
The lifecycle model must define a valid transition from the state that the target object is in at the time it is submitted for approval to the state specified in Reject State. Otherwise, the target object's state does not be switched when a rejection occurs.