On this page0
Guide
Handle access requests
Let people ask for an app themselves, have an approver decide, and have IT provision it, with every decision on the record.
Before you start
- Requesters need a role that lets them request access. That shows Access GovernanceAccess Requests in their menu. In the built-in set every active person has it, through the “Everyone” group.
- At least one approver: someone whose role lets them approve access requests or manage users. In the built-in set, administrators can do both, and members of the “Manager” group can approve requests. Approvers are notified of each new request, by email too if email is set up.
- People in the IT group to carry out the provisioning in ExecutionWorkflow Tasks.
- Connected apps make this better. If none are connected, people pick from a common-app list or type any app name.
Request access
Step 1: Pick the app
Open Access GovernanceAccess Requests. Under “What do you need access to?”, click an app tile, or search for it. For anything not shown, click “Something not listed?”, or type the name and press Enter.
Step 2: Say why, and submit
In “Request access”, check “App or access”, choose a “Reason” (New role, Project need, Backfill, Temporary elevation or Other), and add a “Justification (optional)”. Your organization may add its own fields here. Click “Submit request”.
Those extra fields are set by someone whose role lets them manage users, under “Custom request fields” on this page or in AdministrationData Governance under “Access requests”. Everyone else just fills them in.
The request appears under “My requests” as “Awaiting approval”, with a Requested, Approved, Provisioned progress bar.
Gate 1: the approver decides
Step 3: Review the queue
Approvers see a second column, “Waiting on you”, listing each request with who it is for, who asked, and their justification.
Step 4: Approve or reject
Click “Approve” or “Reject”, add an optional comment, and confirm. To decide several at once, tick them (or “Select all requests”) and approve or reject them together with one shared comment.
You cannot approve a request you submitted, or one for your own access. Another approver has to. You can still reject it. Administrators are exempt.
Step 5: What approval does
Approving creates a provisioning run and moves the request to “Approved — IT provisioning”. If the person has left or their account is no longer active, Zonitix refuses instead: the request is rejected with the comment that the subject is no longer an active employee, and nothing is provisioned. This applies to administrators too.
Rejecting ends the request. The requester is notified with your comment.
Gate 2: IT provisions it
Step 6: IT approves the provisioning
The run appears in the IT queue in ExecutionWorkflow Tasks, titled “Access request: …” with the app and the person’s email. Its first step is “IT Provisioning Approval”. IT approves it to go ahead, or rejects it with a reason to stop it.
Members of the IT group and administrators can act on this step: it opens with “Approve to release the run, or reject to stop it here.” Anyone else sees “Read-only — currently with another team.” and a “Waiting for IT” label, with no Approve or Reject buttons.The IT approver must be a different person from whoever approved at gate 1, unless they are an administrator or that rule is switched off in Security Settings.
Step 7: The access is set up
After IT approves, the run gains the step to grant the app. For a connected app, that is an account step. For anything else, it is an IT task to do by hand and tick off. Account steps on access-request runs wait for an administrator to run them (they show “WAITING TO RUN”). See Work through workflow tasks.
Where access reviews live
Step 8: Certify access on a schedule
To check that people should still have the access they hold, use Access GovernanceAccess Reviews. “Current access & drift” shows everyone’s access now, with access nobody granted flagged. “Reviews” holds campaigns: start one with “New campaign”, and reviewers “Certify” or revoke each item. “Schedules” repeats a campaign automatically.
Nobody can certify their own access. Revoking a Zonitix role or group takes effect at once. Revoking access to an external app creates an IT run in Workflow Tasks.
What you should see
When the run is complete, the request under “My requests” reads “Provisioned” and the requester is told. If IT rejected it, it reads “Declined by IT at provisioning”.
Each request, decision and outcome is written to the audit log.
If something goes wrong
- "You cannot approve your own access request (separation of duties)."
- You either asked for it or it is for you. Leave it for another approver, or reject it yourself if it is no longer needed.
- The request was rejected with "Subject is no longer an active employee."
- The person was offboarded or deactivated while the request waited. This is by design. If they have come back, their account must be active again before a new request can be approved.
- A request shows "Provisioning couldn’t start — retryable".
- The request was approved but no provisioning run could be created, usually because there is no live Access Request pipeline. Nothing was granted. Contact Zonitix support to restore the pipeline and retry it.
- Someone opens the IT Provisioning Approval step and it says "Read-only — currently with another team."
- They are not in the IT group, which owns this step. Ask a member of the IT group or an administrator to open it, or add the person to the IT group. The request stays at Approved — IT provisioning until the step is approved or rejected.
- "This request is already approved" (or rejected).
- Another approver decided it first. The queue refreshes itself every 15 seconds, so the request will drop out of your list.
Still stuck? See When something goes wrong, or Contact Zonitix support.