Skip to content
ServiceNow coexistence Federated identity governance

ServiceNow and SafePaaS: what each one governs

SafePaaS does not replace ServiceNow. It governs what a role permits once the user is inside the ERP — the layer an identity platform cannot see.

Beside ServiceNow, not instead of it — one rule book across every system in the same business process.

Book a Demo See How It Connects
Group read as ServiceNow defines it, down to the table and field ACL Every snapshot re-tested in full, so a conflict reintroduced since the last one surfaces Handed back findings from every governed system return to ServiceNow, where your process already lives One rule book applied across every system in the process, not one tool per application
The entitlement model we read

A ServiceNow user’s authority is four layers below the role name

SafePaaS reads the ServiceNow security model as ServiceNow defines it: user, group, role, table and field ACL. Each layer is resolved, not assumed.

Only the deepest layers say what a user can actually do, and where. Everything above them is a container.

Figure 1 How SafePaaS resolves a ServiceNow user to effective authority
  1. Layer 1 User
  2. Layer 2 Group
  3. Layer 3 Role
  4. Layer 4 Table and field ACL which may carry conditions and scripts of its own

A container in this chain can be widened while keeping the name an access review sees, and the deepest layer differs with every assignment. That is why SafePaaS tests the authority a user actually resolves to, not the label attached to it.

Coverage in detail

Where SafePaaS and ServiceNow divide the work

What does ServiceNow already govern?

ServiceNow owns the account and the process around it, reading its own model to do so: user, group, role, table and field ACL. None of that is in question, and SafePaaS does not replace any of it.

▸ The account itself — joiners, movers and leavers ▸ Birthright access, and the request and approval workflow ▸ Provisioning a user into the downstream system, and recording that they hold a role there ▸ Certification campaigns, run against what it knows

What can ServiceNow not see once the user is inside the ERP?

What the role PERMITS. ServiceNow records that a user holds a role; what that role resolves to lives several layers down in the target system’s own security model and does not travel with the assignment.

▸ The entitlement behind the role name, which is where the permission actually lives ▸ A conflict that exists only where two duties share an org unit — so it is a column, not a row ▸ A role whose contents were widened after it was built, while the name an access review sees stayed the same ▸ Configuration and transaction change inside the ERP, which no access model describes at all ▸ Service, batch and integration accounts that no joiner-mover-leaver process was built to review

What does SafePaaS add on top of ServiceNow?

One rule book, tested against an ERP Snapshot of the target system’s own security model — so a certification in ServiceNow reflects the entitlement rather than the role name.

Modules Enterprise Access MonitorEnterprise Roles ManagerMonitorPaaS
▸ Resolves each role to the entitlement it actually grants, in the target system’s own vocabulary ▸ Tests segregation of duties across every system in a business process, not one application at a time ▸ Simulates a role change before it is applied, so a change does not reintroduce a violation that was already remediated ▸ Watches what happened — the posted document, the changed bank detail — not only who could have done it ▸ Extends the same policy to non-human identities and AI agents

How do SafePaaS and ServiceNow hand work to each other?

Through the service request. When an access review decides a user should lose access, SafePaaS raises the request in ServiceNow and follows it until it closes — so the removal is carried out where your fulfilment already runs, and the review’s own record shows whether it was.

Modules Enterprise Access Certification Manager
▸ A reviewer’s decision to remove access becomes a requested item (RITM), created through the ServiceNow Table API ▸ SafePaaS keeps the ticket’s sys_id and checks it on a schedule until it reaches a terminal state — Closed Complete, Closed Incomplete or Cancelled ▸ The outcome is written back to the certification record, so the decision and its fulfilment sit in one audit trail ▸ ServiceNow keeps the fulfilment it already owns; SafePaaS decides what should change and records whether it did
Connection

How does SafePaaS connect to ServiceNow?

SafePaaS extracts through the platform’s own service interfaces — SOAP per security object, REST for transactions.

Inside ServiceNow → SafePaaS extraction SOAP services per security object returning XML; REST endpoints returning JSON for occurrences.
Transfer → DataProbe The collected data is pushed out to SafePaaS through DataProbe.
Normalize → DataPaaS The transformation layer. Normalizes the data where required so one rule book can test it.
Result ERP Snapshot The point-in-time copy every module tests against — SoD, monitoring, certification and audit evidence alike.
What is read User, Group, Role and Table and field ACL How data moves Everything collected lands in the FSOD_* open interface tables, and DataPaaS normalizes it from there First snapshot A baseline of every user, role and entitlement assignment, and the first SoD test result set against your own rule book Protection Traffic terminates behind a WAF and an API gateway; the snapshot is tenant-isolated at rest
What runs inside ServiceNow Nothing Extraction runs through the platform’s own service interfaces, so no SafePaaS component is deployed into it.

Because every governance module tests the snapshot rather than the live system, the same rule book applies to ServiceNow and to every other system in the same business process.

FAQs

What ServiceNow teams ask first.

The security model as ServiceNow defines it: user, group, role, table and field ACL. SafePaaS resolves the chain rather than recording the role name, because the role name is a container and the permission lives below it.

Nothing inside the application. Extraction runs through its own service interfaces. Everything collected is pushed out to DataProbe, where DataPaaS normalizes it into the snapshot every governance module tests.

Every test runs against a snapshot taken at a point in time, and Enterprise Roles Manager simulates a role change before it is applied. A change that would reintroduce a remediated conflict is visible before it reaches production rather than at the next review.

A baseline of every user, role and entitlement assignment, and the first SoD test result set against your own rule book — typically the first time the estate has been assessed against one rule book rather than several.

No. Your identity platform keeps the account, the joiner-mover-leaver process and the request workflow. SafePaaS governs what the entitlement behind the role actually permits, and hands findings back, so a certification reflects the entitlement rather than the role name.

Go deeper on identity governance
Pillar Enhance your IGA Pillar Policy-based access governance across the estate Index All application coverage
Next step

See how SafePaaS governs a ServiceNow estate

A working walkthrough against a demo environment, with a specialist who can map what you see onto the roles, organisation structure and audit pressure you actually have.

What the walkthrough covers How the entitlement chain is read as ServiceNow defines it — user, group, role, table and field ACL An SoD conflict traced from the rule to the entitlements that create it How a role change is simulated before it reintroduces a remediated conflict Where SafePaaS sits relative to the IGA and GRC tooling you already run