Before
IAM staff likely had to inspect the requester’s identity and current group memberships, find the relevant platform owner, and coordinate manager and owner decisions manually. After approval, they also had to add the new access group, remove older memberships, update the ticket, and notify the requester across separate steps.
How it works
- Validate the requester, platform, requested tier, and current memberships, then close requests that are already satisfied or invalid.
- Route sequential approval requests to the manager and platform owner, record refusals, and escalate unanswered decisions after 72 hours.
- Apply the approved group, remove superseded tiers, verify the resulting memberships, update the ticket, and notify the requester.
Workflow details
- Request normalization: A ServiceNow privilege-elevation request supplies the requester, platform, resource, requested access tier, justification, and ticket details. The workflow builds the corresponding access-group name and retrieves the requester, platform application, and platform owner.
- Access validation: The workflow reviews the requester’s current group memberships to determine the existing tier, whether the requested tier is already granted, and which older tiers must be removed. Already-satisfied requests are closed without changes, while requests for unknown tiers are closed as invalid.
- Approval control: Eligible requests are recorded in ServiceNow and sent to the requester’s manager in Teams for a decision. After manager approval, the platform owner receives the request; refusals are recorded and communicated, while missing responses after 72 hours are escalated to the IAM team.
- Provisioning and cleanup: When both approvals are received, the requested group is granted to the requester and any superseded groups for the same resource are removed. The resulting memberships are then read back to confirm the post-change access state.
- Closure and communication: The ServiceNow request is updated with the approval details and resulting access, then closed. The requester receives a Teams confirmation that the elevation was granted, or a refusal notice when an approver declines.
What changed
Access validation, approval routing, timeout escalation, group changes, post-change verification, ticket updates, and requester communication now follow one controlled workflow. Human approval remains required from both the manager and platform owner before an approved elevation is applied.
Work removed
Looking up requester and platform-owner details, checking current and superseded access groups, sending and tracking two approval requests, recording approval outcomes, adding and removing memberships, verifying the final groups, updating the ticket, and sending requester notifications.
Expected outcome
A conservative estimate is that five or more recurring manual actions are removed per approved request, with the resulting role becoming available after the next synchronization and the request outcome recorded automatically.
