Skip to main content

What Happens After You Send a File

Your extract doesn't just sit in ISC — it drives three things a real person acts on: access requests, fulfillment tickets, and certifications. What you put in the entitlement file, especially description, is what those people actually read.

Access requests​

Once your entitlements are loaded, they appear in ISC's access catalog for anyone with requestable: true. A requester sees your displayName and description — nothing else — when deciding whether this is the access they want. A vague description (JC_HFM_SUB_AM) gets requested by guesswork; a clear one (Jimmy Choo HFM Submitter - Americas Entities) doesn't.

requestable: false keeps an entitlement out of this catalog entirely. Use it for anything that shouldn't be self-service — admin-level access in particular.

Approval is configured on the roles your entitlements are bundled into: a request routes to the approvers defined on that role, and what they read to make the call is, again, the displayName and description you supplied.

Joiners: requested or birthright​

A new hire ends up with access to your application one of two ways:

  • They request it — the catalog path above, with the role's approval step.
  • It's birthright — your application's access is included in a role granted automatically on day one, based on who the person is (department, brand, job function). No request and no approval step; the grant goes straight to fulfillment.

Either way, the actual change in your system is the same ServiceNow ticket a fulfiller works — birthright skips the asking, not the doing. Whether your application is request-only or belongs in a birthright role is agreed with the IAM team at onboarding.

Fulfillment: the ticket a person works​

An access request that's approved becomes a manual provisioning task — a work item that routes to your entitlement's owner (falling back to the source owner if the entitlement has none). Today that task becomes a ServiceNow Service Request (via the integration the IAM team calls SDIM, the Service Desk Integration Module — same thing if you hear that term), worked by a fulfiller who reads it and makes the actual change in your application, then marks it done.

The ticket is only as useful as what's in it. The fulfiller sees the request details ISC has — which is exactly what your file supplied: the entitlement's display name and description, and who requested it. A description that says what the access actually grants (not just its internal code name) is the difference between a fulfiller who can act immediately and one who has to come find you to ask what JC_HFM_SUB_AM even is.

If ServiceNow is ever unavailable, the task doesn't disappear — it queues in ISC's own Task Manager until the integration recovers. Either way, the same rule holds: your owner column has to be a real, monitored person, because that's who the task is assigned to.

Once the ticket exists, reminders, notifications, SLAs, and escalation are ServiceNow's job, not ISC's — it sits in the same queues and escalation policies as the rest of the service desk's work. ISC's part ends at creating the ticket and recording its completion.

Leavers and emergency termination​

When someone leaves, the HR feed drives ISC's leaver process, and for a disconnected application the resulting disable is — like everything else — a ServiceNow ticket: a fulfiller disables the account in your system. Your next extract then confirms it with IIQDisabled: true, closing the loop. A file that still shows the account enabled after the ticket closed is drift worth flagging.

Emergency termination is the same mechanism at maximum urgency: an immediate ticket to disable the account now. It does not wait for your file cadence — the extract's job afterward is to confirm the disable, not to cause it. This is also why the routing columns matter more than they look: an urgent ticket is only as fast as the owner it reaches.

Movers​

A transfer triggers no automatic change to access on a disconnected application — nobody's account is modified because they changed department or role. Access the new job no longer justifies is caught by the periodic user access review below, which is why the reviewer-facing columns in your file (description, owner) carry the weight here: the UAR is the mover control.

Certifications — the periodic user access review​

Periodically, someone (a manager, an entitlement owner, or both) is asked to certify that access is still appropriate — the user access review (UAR). They see the same displayName and description you supplied, plus who holds the access. privileged: true entitlements are prioritized in these campaigns and appear in privileged-access reporting, since they carry more risk if left unreviewed.

A certifier who can't tell what an entitlement does from its description either rubber-stamps it (defeating the point of the review) or has to go ask someone — both are avoidable with a clear description written when you produce the file, not reconstructed later under deadline pressure.

The UAR is also where the paper trail lives. Reviewer decisions and sign-offs are the audit evidence for your application's access, and known exceptions — the agreed uncorrelated populations, service accounts, anything outside the standard rules — are recorded and re-approved there each cycle rather than tracked ad hoc. If an auditor asks "who approved this access, and when was it last reviewed," the UAR record is the answer; your file's description and owner columns are what make that record meaningful.

The throughline​

Everything above traces back to two columns you control: description (read by requesters, fulfillers, and certifiers alike) and owner (who the system routes work to). Getting those two right in the extract is worth more than almost anything else in the file — see the Owner Guide for the concrete rules.