I Moved Access Request Out of SailPoint. Into Jira.

I worked on a migration from ServiceNow to Jira Service Management where the obvious part was rebuilding what already existed — incidents, changes, problems, service requests, the service catalog. The part nobody had named yet was access request.

In most organizations running an IGA — SailPoint, Okta, Saviynt — the access request is born, approved, and decided inside the identity tool. The ITSM, when it shows up at all, is where a task lands: the IGA couldn't provision it automatically, so it opens a ticket for someone to handle manually.

This split isn't incidental. It's documented vendor behavior: sources with a direct connector are provisioned automatically, and everything else becomes a manual task assigned to the system owner. The IGA governs whatever it can automate well. What doesn't fit that model gets pushed somewhere else — and that's where the architecture needs a decision almost nobody makes on purpose.

The real problem

An IGA is built to govern identities, map access, and execute provisioning. It does that well, and it remains the right place for access certification and revocation triggered by HR events. The problem isn't what it does. It's what's left over.

When an access request depends on manual execution, the IGA generates a task. It exists, has an owner assigned automatically, can be reassigned and marked complete. It works. But it's a task inside a governance tool, not a queue item inside a service operations platform — and that difference shows up when you're operating it, not when you're configuring it.

The same request, once it becomes a ticket in an ITSM, inherits an entire ecosystem that was already there: SLA, automatic assignee, an internal comment carrying the execution instruction straight from the catalog, notifications on every status change, a manageable queue, team performance reporting. None of that needs to be built — it's what a service management platform already does for every other kind of request.

And this isn't a reading against the vendor. When announcing the integration with Jira Service Management, SailPoint itself points out that the ITSM lets organizations set SLAs on time-sensitive access requests — acknowledging, in practice, where that layer comes from.

The point isn't which tool is better. It's that there's a boundary between deciding and executing, and where that boundary gets drawn determines what kind of operational experience the organization can offer.

The right question

The debate tends to get framed as a tool choice: IGA or ITSM. That's the wrong question, and it produces bad answers in both directions — organizations that push governance into the service desk, and organizations that treat access request as if it were purely an identity problem.

The right question is where each responsibility lives.

Execution belongs to the IGA. It knows the sources, has the connectors, knows how to translate "grant access" into a real operation on the target system. Governance belongs to it too: periodic access certification, detecting conflicts between access a person has accumulated across different systems, revocation triggered by HR events. These capabilities depend on an aggregated view of everything an identity holds across every system — and a ticket workflow doesn't have that, by nature.

Orchestration belongs to the ITSM. What's in the catalog of what can be requested, who approves what, in what order, what happens when execution fails, who takes over when the step is manual, when the request is actually done. These are process decisions, not identity decisions — and service management tools exist for exactly this.

What usually happens is orchestration gets absorbed by the execution tool, because it was already there. It's not a wrong decision; most of the time it isn't even a decision. It's a consequence of whichever tool got deployed first.

Reversing that — putting orchestration in the ITSM and leaving the IGA as the engine — isn't swapping one for the other. It's not letting the execution tool own the process.

The solution

What makes this operable isn't the workflow. It's the catalog.

The catalog has three levels: the application, the access level within it, and — when it exists — the specific resource within that level, like a project or a workspace. None of them are just descriptive. Each object carries the attributes that decide the path a request takes: which approvals happen, who approves, how access gets provisioned, who executes when the step is manual, and what instructions that person receives.

The workflow doesn't know anything about any application. It reads the catalog.

The consequence shows up in day-to-day work. Adding a new application to the portal means creating objects in the catalog, not editing a flow. A hundred applications and a few hundred access levels coexist with a single request form. And the split in ownership stays clean: the ITSM team maintains the catalog, the platform team maintains the workflow. Two different skill sets, two different owners, no turf to fight over.

It also changes the cost of evolving. Adding a new approval level didn't require redesigning the flow. It required one more status and one more attribute in the catalog. That's how the model went from two approval levels to however many it supports today.

When the method disappears from the experience

Two applications on the same portal. One gets provisioned automatically by the IGA within minutes. The other has no automated provisioning at all, and someone has to go into the target system and configure access by hand. To whoever is requesting, the two look identical.

The form is the same. The questions are the same. The tracking is the same: the request shows up on the portal, changes status, and notifies you as it moves forward.

The difference exists entirely on the inside. On the automated path, the request goes through the approvals that access level requires, execution fires, and the real result comes back before anything gets marked as done. On the manual path, the request reaches an execution step with an owner already assigned and the instructions visible to whoever is executing, without anyone having to go looking for where they're documented. And there's the composite case, where both happen in sequence: automated execution runs first, and only then does the request move to the manual step the application requires.

Three technically very different paths. None of them visible to whoever is requesting.

That's why the provisioning boundary stops leaking. It still exists. But it becomes an architecture decision, resolved once, in the catalog, by whoever has the context to resolve it. Not information the requester has to carry before they can even ask for something.

The result is access request stops being a case apart. Incident, service request, and access request start living in the same operation: same queue, same SLA model, same numbers. Access request stops being the one IT process nobody can measure alongside everything else.