Privileged Access Request Workflow

Why should we automate privileged access requests instead of handling them manually?

Manual privileged access requests are often tracked across email threads and spreadsheets, making it hard to see where a request stands or whether the right people approved it. This workflow captures each request as a record with a reference number and status, so managers, system owners and security reviewers act on tasks routed to them, and every decision is recorded on the record's timeline. That structure helps reduce delays and makes it easier to see who approved what and when.

What is the return on investment of using this workflow?

The workflow reduces the administrative time spent chasing approvals, tracking down request status, and manually notifying requesters at each stage. Because acknowledgement emails, rejection notices and provisioning confirmations are sent automatically, staff spend less time on repetitive communication. Table views and dashboards showing records by status also make it easier for teams to monitor volume and identify bottlenecks without building separate reports.

Who is involved in approving a privileged access request?

A request first goes to the requester's manager for approval, then to the system owner for a separate approval. If the request is flagged as high risk, it also goes to the security team, who record a review result and comments. Each of these is a task assigned to a workspace member, and the outcome of each determines whether the request moves forward or is rejected.

What happens if the manager or system owner rejects the request?

If the manager rejects the request, the record's status is set to Rejected and the requester receives an email explaining that the manager did not approve it. The same pattern applies if the system owner rejects the request at their approval step. In both cases the rejection is reflected in the record's status and timeline, so there is a clear record of where and why the request stopped.

How does the workflow decide whether a request needs security team review?

After manager and system-owner approval, the workflow routes the request based on the Risk Level entered on the original form. Requests marked High risk go to a security team review task, where the reviewer records a Security Review Result and comments; requests marked Standard go straight to IT provisioning. If the security team declines a high-risk request, the record is set to Rejected and the requester is emailed the security team's comments.

What does the IT provisioning step actually record?

The IT Provisioning Task is a task the workflow waits for, during which IT grants the access and enters the Username Granted, Date Granted and Expiry Date. These details are saved to the record once the task is completed, and the record's status is then updated to Active. The requester and the person granted access both receive an email confirming access is in place along with the expiry date.

Can this workflow be customised for our own approval structure or risk criteria?

Yes. Workflow steps can be changed by describing the change in plain English or editing the steps directly in the workflow editor, and earlier versions are kept. This makes it possible to adjust routing conditions, such as risk level thresholds, or add further tasks without needing a development project.

Do requesters or the person needing access need an account to take part?

No account is required. Requesters submit the initial request through a public request form, and any follow-up interactions, such as receiving notifications, happen through email. This keeps the process accessible to anyone who needs to request or receive privileged access.

How is the status of a request tracked over time?

Each submitted request becomes a record with a reference number, a status such as Submitted, Provisioning, Active or Rejected, and a timeline showing what happened at each step. Table views and dashboards display records grouped by status, making it straightforward to see how many requests are pending approval, under security review, or already active. Each business should confirm this level of tracking meets its own internal record-keeping requirements.

What information does the initial request form collect?

The request form collects the requester's name and email, the name and email of the person needing access, the privileged role requested, the target system, a business justification, the requested duration in days, and the risk level. This information is captured on the record when it is created and is used throughout the approval, review and provisioning steps.