4.2 KiB
id, title, sidebar_label, sidebar-position
| id | title | sidebar_label | sidebar-position |
|---|---|---|---|
| access-request-dynamic-approval-event-trigger | Access Request Dynamic Approval Event Trigger | Access Request Dynamic Approval Event Trigger | 2 |
Access Request Dynamic Approval Event Trigger
Event context
The Access Request Dynamic Approval event trigger provides a way to route a request to an additional approval step by an identity or a governance group.
When an access request is submitted, the Access Request Dynamic Approval trigger:
- Sends data about the access request and expects a response that includes the ID of an existing identity or workgroup (i.e. governance group) to add to the approval workflow
- Based on the ID received, an approval task will be assigned to the identity or governance group in IdentityNow for a decision as an additional step after other configured approval requirements
- If the new approver is also the target identity for this request, the manager is assigned instead. If the identity has no manager, a random org admin is assigned.
- If the ID of the additional approver is wrong, then a random org admin is assigned.
- You can choose to NOT add an additional approver by providing an empty object as the response to the triggered REST request.
This trigger can be used to develop logic outside of IdentityNow’s out-of-the-box offerings to route an approval step to users such as:
- The recipient’s department head
- The recipient’s cost center
- A security officer
- A high-risk governance group for highly sensitive roles
Configuration
This is a REQUEST_RESPONSE type trigger. For general information on how to respond to a REQUEST_RESPONSE type trigger, see responding to a request response type trigger. This trigger intercepts newly submitted access requests and allows the subscribing service to add one additional identity or governance group as the last step in the approver list for the access request.
The subscribing service will receive the following input from the trigger service. The input schema can be found in the API specification:
{
"accessRequestId": "4b4d982dddff4267ab12f0f1e72b5a6d",
"requestedFor": {
"type": "IDENTITY",
"id": "2c91808568c529c60168cca6f90c1313",
"name": "William Wilson"
},
"requestedItems": [
{
"id": "2c91808b6ef1d43e016efba0ce470904",
"name": "Engineering Access",
"description": "Engineering Access",
"type": "ACCESS_PROFILE",
"operation": "Add",
"comment": "William needs this access for his day to day job activities."
}
],
"requestedBy": {
"type": "IDENTITY",
"id": "2c91808568c529c60168cca6f90c1314",
"name": "Billy Bob"
}
}
The subscribing service can use this information to make a decision on whether to add additional approvers to the access request. The output schema can be found in the API specification. To add an identity to the approver list, the subscribing service should respond to the event trigger with the following payload:
{
"id": "2c91808b6ef1d43e016efba0ce470906",
"name": "Adam Adams",
"type": "IDENTITY"
}
To add a governance group to the approver list, the subscribing service should respond to the event trigger with the following payload:
{
"id": "2c91808b6ef1d43e016efba0ce470907",
"name": "Audit Committee",
"type": "GOVERNANCE_GROUP"
}
If no identity or group should be added to a particular access request, then the subscribing service should respond with an empty object:
{}