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.
The parameters are described in the description of the action Initiate Group-Dependent Approval in the CentraSite Developer’s Guide.
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.
