Access requests in ServiceNow, asked once, approved once, delivered automatically.
Warde gives ServiceNow one access request form for every application, in the Employee Center your staff already use. The right people approve in order, your identity engine or a ServiceNow task delivers, and the request reads done only when the change is confirmed.
Ask, approve, deliver, confirm.
One request
Search for access by name and put several applications in one request, for yourself or for somebody else. Duplicates, conflicts and missing prerequisites show before you submit.
The right people, in order
Manager, application owner, security: whatever chain your policy sets. Each approver sees what the access is, in plain words, and why it has come to them.
Provisioned with no ticket
Warde sends the approved change to your identity system, retries, and shows the requester a promised date. Where no engine can provision it, a task goes to the team that owns the application.
Done when it is done
The request is reported complete only when the engine confirms the change was made. Removals go down the same path.
Narrowed to what you are allowed to be given.
- Each application can ask its own narrowing questions first, so the list that follows fits where you work.
- Access you already hold is listed and marked, and cannot be asked for a second time.
- Terms of use are read and accepted on the form.
- Before anything is raised, the form shows the approver your policy resolved to.
- Where your identity engine checks separation of duties, its verdict shows on the form and is checked again before approval, set to block, warn or off. The ruleset stays in the engine.
- Each row in the request carries its own account and its own end date.
A different approval policy for every kind of access.
Standard access goes to the manager. High-risk access adds the application owner and security. Licensed software adds the licence owner. Each policy is a chain of stages written in a four-step wizard, and every approver comes from your own data: the requester’s manager, the entitlement’s owner, a group, a named person, or a field on the application’s CMDB record. Conditions read the request line, so a stage can run only for admin accounts or only above a risk rating. If a stage’s approver is missing, it falls back to one you name instead of being skipped.
A whole job’s access in one request.
An access bundle puts the access one job needs into a single request, approved once by the people who own it. An accounts payable starter who would otherwise raise six requests and wait on eleven approvals raises one request with one approval. Teams curate their own bundles, high-risk access keeps its approvers, and a bundle is reviewed and removed as one. Birthright bundles are granted with no approval when your joiner feed names them.
One page for what you hold.
My Access shows what you hold, what your team holds, what you hold while acting for somebody, and the reviews waiting on you. Each row has a Remove button, and a removal goes down the same approval and fulfilment path as a grant.
Your identity engine provisions it, or a task does.
Identity Security Cloud and IdentityIQ
Approved requests go to SailPoint to provision. The ServiceNow SailPoint integration.
Entra ID Governance
Groups, app roles, licences, directory roles and access packages. The ServiceNow Entra integration.
ServiceNow tasks
Provisioning and removal go as tasks to the team that owns the application, at the right time.
What each vendor’s ServiceNow application does on your instance.
A tick means the work happens in ServiceNow. A dash usually means the vendor does it well in its own console.
| Warde | SailPoint | Saviynt | Entra | Okta | Omada | |
|---|---|---|---|---|---|---|
| Ask for access in the ServiceNow catalog | yes | yes | yes | yes | partly: the documented integration runs the other way, from Okta into ServiceNow | yes |
| Approve it in ServiceNow | yes | yes | yes | yes | partly: the documented integration runs the other way, from Okta into ServiceNow | yes |
| Your identity engine does the provisioning | yes | yes | yes | yes | yes | yes |
| User access reviews decided in ServiceNow | yes | yes, for Identity Security Cloud: SailPoint documents a certification portal in ServiceNow where certifiers approve, revoke and sign off | no | no | no | no |
| Campaigns defined and scheduled in ServiceNow | yes | their console | their console | their console | their console | their console |
| Approval policies built in ServiceNow | yes | no | no | no | no | no |
| Access bundles curated in ServiceNow | yes | no | no | no | no | no |
| My Access: one page for what you and your team hold, and the reviews waiting on you | yes | partly: the app shows the roles and access profiles a person holds, without a team view or reviews on the same page | not stated | their console | their console | not stated |
| An admin workspace on the instance: what is stuck, what is stale, connector health | yes | not stated | not stated | no | no | no |
| The auditor’s evidence pack, in ServiceNow | yes | no | no | no | no | no |
| Runs with no identity engine at all | yes | no | no | no | no | no |
| Spots the joiner and the leaver for you | not on its own: your own joiner and leaver trigger calls Warde’s lifecycle endpoint, and Warde provisions from there | yes | yes | yes | yes | yes |
Read from each vendor's published documentation in September 2026. For Okta, "partly" means the documented integration runs the other way: a request raised in Okta creates a record in ServiceNow. For SailPoint on the My Access row, it means the app shows what a person holds, without the team view or the reviews waiting. SailPoint's tick on user access reviews is for Identity Security Cloud's Store app, which SailPoint documents as a certification portal where certifiers approve, revoke and sign off. The IdentityIQ integration does not include it. On the last row, Warde does not watch your HR feed. Whichever system already knows somebody has joined or left calls Warde's lifecycle endpoint, and Warde grants or removes the access from there. The full sixty-three-row version, sources attached, is yours if you ask for it.
Access requests in ServiceNow, answered.
How is this different from a catalog item per application?
One form covers every application, so there is nothing to build per application. The form knows what each person already holds, what they are allowed to ask for and who will approve it, and the request is tracked through to a confirmed change.
Can somebody request access for another person?
Yes. You decide who people can raise requests for: themselves, their team, their organisation or anyone. Several applications can go in the one request.
Do approvers need anything new?
No. Approvers approve in ServiceNow, in the order your policy sets, from the screens and emails they already use.
What happens when access expires?
Access past its end date is removed by a daily pass, which warns the holder and their manager first.
Does it need a developer to run?
No. Three wizards cover the first setup, each new application and every change to who approves what, with no update sets.
Related pages
Bring the access request you hate most.
Forty-five minutes on a live instance, with no slides. We will show you what replaces it, what it costs, and what the product still cannot do.