ServiceNow SailPoint integration, for Identity Security Cloud and IdentityIQ.
Staff ask for access in ServiceNow Employee Center, the approvals run in ServiceNow, and SailPoint provisions the change. Warde is the ServiceNow application that does the ServiceNow half: requests, approval policies, access bundles, user access reviews and My Access, with a supported connector to SailPoint in place of a home-built integration.
Warde next to SailPoint’s own ServiceNow applications.
| Warde | SailPoint for ISC | SailPoint for IdentityIQ | |
|---|---|---|---|
| Ask for access in the ServiceNow catalog | yes | yes | yes: roles |
| Approve it in ServiceNow | yes | yes | yes: ServiceNow manager approvals, or an IdentityIQ workflow |
| SailPoint does the provisioning | yes | yes | yes |
| User access reviews decided in ServiceNow | yes | yes: SailPoint documents a certification portal in ServiceNow where certifiers approve, revoke and sign off | no: the IdentityIQ integration does not include it |
| Campaigns defined and scheduled in ServiceNow | yes | their console | their console |
| Approval policies built in ServiceNow | yes | no | no |
| Access bundles curated in ServiceNow | yes | 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 |
| An admin workspace on the instance: what is stuck, what is stale, connector health | yes | not stated | not stated |
| The auditor’s evidence pack, in ServiceNow | yes | no | no |
| Applications SailPoint does not reach, run the same way | yes: provisioned by ServiceNow tasks | no | no |
| Spots the joiner and the leaver for you | not on its own: your joiner and leaver trigger calls Warde’s lifecycle endpoint, and Warde provisions from there | yes | yes |
SailPoint columns are read from SailPoint’s published documentation, linked in the next section, in October 2026. A dash means the work is done in SailPoint’s console, or the documentation does not say it is done in ServiceNow. On the last row, SailPoint watches your HR source itself; Warde is called by whichever system already knows somebody has joined or left.
The ways to connect ServiceNow and SailPoint, and what each one is for.
“ServiceNow SailPoint integration” covers several different jobs, and they run in different directions. Most SailPoint customers need more than one. Pick by the question you are answering.
| Integration | Direction | What it does | Reviews in ServiceNow |
|---|---|---|---|
| SailPoint Identity Governance Connector | SailPoint governs ServiceNow | Loads ServiceNow user accounts into Identity Security Cloud and provisions accounts in ServiceNow, so SailPoint controls who holds ServiceNow roles | - |
| SailPoint Service Catalog integration for Identity Security Cloud | ServiceNow asks SailPoint | Request roles and access profiles from ServiceNow, see and remove existing access, and track requests | A certification portal SailPoint documents for Identity Security Cloud |
| SailPoint Service Catalog Integration for IdentityIQ | ServiceNow asks SailPoint | Request roles from ServiceNow, approved by ServiceNow managers or an IdentityIQ workflow, through a MID server | - |
| SailPoint service desk integration | SailPoint asks ServiceNow | SailPoint raises a ServiceNow ticket so a person provisions an application SailPoint cannot reach | - |
| Warde | ServiceNow asks SailPoint | Requests, approval policies, access bundles, user access reviews, My Access and the audit evidence pack on your instance; SailPoint provisions, and Warde confirms each change back | ✓ campaigns defined, scheduled and decided in ServiceNow |
SailPoint facts are from SailPoint’s published documentation, linked above, as read in October 2026. If you want SailPoint to govern who holds roles inside ServiceNow itself, that is the Identity Governance Connector’s job, and Warde runs alongside it.
One path from the request to SailPoint and back.
In Employee Center
Staff search for access by name and put several applications in one request. Access they already hold is marked, and the approver is shown before they submit.
In ServiceNow
Your approval policy picks the approvers in order: manager, application owner, security, licence owner. A bundle is approved once.
By SailPoint
The approved change goes to SailPoint, which provisions it the way it already does. Warde retries and shows the requester a promised date.
Back in ServiceNow
The request reads done only when SailPoint confirms the change. Removals and review revocations go down the same path.
SailPoint stays the system of record. Warde does not take over your role model, your policy engine or your identity warehouse, and the separation-of-duties rules stay in SailPoint.
What Warde reads from SailPoint, and how each change goes back.
Formerly IdentityNow
Reads sources, accounts, entitlements, access profiles, roles and who holds them: the catalog daily, accounts every four hours. Each grant or removal goes in as an access request aimed at the person’s account, and Warde polls its status until ISC confirms it. Roles ISC assigns by membership criteria cannot be removed by request, so those go to a person.
Over its SCIM API
Reads applications, entitlements, roles and accounts. Each change is launched as a provisioning plan through IdentityIQ’s own provisioning workflow, LCM Provisioning unless you name another, and Warde polls until it succeeds. IdentityIQ’s policy check gives a separation-of-duties verdict before approval.
SailPoint’s names, your accounts
Collections and entitlements keep the names SailPoint gives them, refreshed on every read. Accounts are matched to ServiceNow users on the attribute pair you choose, employee number by default. If SailPoint is unreachable, work is parked, an incident or event is raised, and the work is requeued when it recovers.
Certifications decided in ServiceNow, with the evidence kept there.
Campaigns are defined, scheduled and decided in ServiceNow, so reviewers use Employee Center rather than another console. A take-away decision goes back to SailPoint down the same path as a removal, and is confirmed before it reads as done. The evidence pack is frozen at launch and keeps its own copy of every row, so a rename in SailPoint does not rewrite last quarter’s evidence. User access reviews in ServiceNow.
If somebody built your ServiceNow to SailPoint integration years ago.
Many SailPoint customers run a ServiceNow integration built in-house: a catalog item per application, scripted REST calls, and a person who remembers how it works. Warde replaces it with a supported scoped application, installed and updated through the ServiceNow Store as one versioned release. The applications and entitlements SailPoint knows about are read in, keep SailPoint’s names, and are requested from one form with no catalog item to build per application. Your IAM team runs it with three wizards and no developer.
ServiceNow and SailPoint, answered.
Does Warde replace SailPoint?
No. SailPoint stays your identity system: it holds the role model and the policies, and it provisions. Warde puts the request, the approval and the review in ServiceNow and hands the change to SailPoint.
Do I still need SailPoint’s Service Catalog app?
Not for access requests. Warde raises requests, runs approvals and tracks them to a confirmed change. You can keep SailPoint’s Identity Governance Connector if SailPoint governs who holds roles inside ServiceNow itself, because that is a different job.
Does it work with both Identity Security Cloud and IdentityIQ?
Yes. Warde has a connector for each. Identity Security Cloud was formerly called IdentityNow.
How do I set up the Identity Security Cloud connector?
In Identity Security Cloud, create a personal access token for a service identity that can read the catalog and raise access requests. The access request API needs a token with user context, so an API client without one is not enough. Leave the approval schemes empty on the roles, access profiles and entitlements Warde will manage, because the approval happens in ServiceNow. In ServiceNow, open the SailPoint ISC alias in Connections & Credentials and set its URL to your tenant’s API address, such as https://acme.api.identitynow.com. Then run Guided Setup: step 2 takes the token’s client ID and secret and tests the connection, step 3 matches accounts to people (employee number by default), and step 4 runs the first read.
Which Identity Security Cloud settings should we review?
Three. Access reasons are read from identity history by default, which needs the idn:identity-history:read scope on an identity with the Org Admin, Helpdesk or Report Admin user level; without it the sync carries on and the reasons stay blank. Checking whether each role can be revoked is off by default, so every role counts as revocable until you turn it on; ISC will not revoke roles held through membership criteria or identity lists. Reading access profiles held outside a role is off by default; turn it on if people hold access profiles directly, or they will not appear in My Access or reviews. End dates stay in ISC, which removes the access when they pass.
How do I set up the IdentityIQ connector?
In IdentityIQ, create a SCIM user with the SCIMExecutor capability, and make sure /scim/v2 is reachable through any reverse proxy. Warde launches the LCM Provisioning workflow with approvalScheme=none, so the approval stays in ServiceNow; if you use a forked or customised workflow, name it in the engine’s connector configuration and check that it honours approvalScheme. In ServiceNow, set the SailPoint IIQ alias URL to the SCIM root, such as https://iiq.example.com/identityiq/scim/v2, pick a MID Server in Guided Setup step 2 if IdentityIQ sits inside your network, then test, bind accounts and run the first read. Delta reads stay off until you have checked them against your deployment, and Warde removes expired access on its own end dates with a daily pass.
How do we know the connector is working?
Test connection in Guided Setup reads from SailPoint and says what it found, such as the number of Identity Security Cloud sources. After that a health check runs hourly, the catalog is read daily at 02:00, accounts every four hours and who holds what every six hours, with a full read at the weekend. The Import data step shows the counts and the time of the last sync.
Does it need a MID Server or IntegrationHub?
No IntegrationHub and no paid ServiceNow subscription. Identity Security Cloud is reached directly from your instance. An IdentityIQ server inside your network needs a route from the instance, such as a ServiceNow MID Server.
Can a request be sent to SailPoint twice?
Warde is built so it is not. If Identity Security Cloud does not answer a submit, Warde looks for the request rather than sending it again, and hands it to a person after 30 minutes. IdentityIQ launches that go unanswered go to a person rather than being relaunched.
What if SailPoint cannot provision an application?
Warde sends a ServiceNow task to the team that owns the application, at the right time, and the request completes when the task is closed complete.
Can people who do not use SailPoint applications still use it?
Yes. Applications with no identity engine behind them are requested, approved and reviewed the same way, with provisioning done by ServiceNow tasks.
Which ServiceNow releases does it support?
Zurich and Australia. Warde is built and running, and is waiting on ServiceNow Store certification. It installs as one scoped application.
Related pages
Bring the SailPoint request your users 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.