Okta Can Provision Access. But Who Decides What Access Someone Should Have?

This is exactly where we see the gap between access automation and true access governance.

Okta is excellent at managing identities and executing access changes, while Jira Service Management provides strong workflow capabilities around requests and approvals. However, organizations often need an additional governance layer to answer questions like:

Why was this access granted?
Was it approved by the right person?
Is this access still required?
When should it expire?
Can we prove the entire lifecycle during an audit?

This creates an auditing gap.

This is where miniOrange Access Governance for Jira Service Management helps.

Instead of treating access requests as one-time tickets, miniOrange turns JSM into a centralized access governance platform where organizations can manage the complete access lifecycle.

For example:

Joiner

Employee joins through HR-driven workflows.
Access requests are automatically created based on role, department, or business requirements.
Approvals are routed to the appropriate managers/application owners.
Once approved, access is provisioned through connected systems such as Okta, Entra ID, Google Workspace, AWS, Jira, Confluence, GitHub, and other SaaS applications.

Mover
This is where governance becomes critical.

When an employee changes departments, miniOrange can help organizations review existing access instead of only adding new permissions.

For example:

Engineering access is requested.
Previous Finance access is reviewed.
Existing permissions can be approved, modified, or revoked.
Every decision is captured with a complete audit trail.

Leaver

Offboarding workflows can trigger access removal across connected applications.
Application access, group memberships, and user accounts can be deprovisioned based on defined workflows and policies.
Organizations get evidence of when and how access was removed.

Beyond lifecycle automation, miniOrange also supports:

Temporary and Elevated Access

Users can request elevated permissions for a defined period.
Requests follow approval workflows.
Access automatically expires and is revoked after the approved duration.

Periodic Access Reviews
Provisioning answers:

"Who approved this access?"

Access reviews answer:

"Should this user still have this access?"

miniOrange helps application owners and managers periodically review existing permissions, certify required access, and remove unnecessary privileges.

The architecture that can solve this is:

HR System → Jira Service Management → miniOrange Access Governance → Identity Provider → Applications

Where:

HR provides the lifecycle trigger.
JSM manages workflows and approvals.
miniOrange provides governance, policies, reviews, and auditability.
Identity platforms like Okta execute the access changes.

The goal is not to replace Okta or JSM. It is to bring governance around the access lifecycle so organizations can move from:

"Access was provisioned."

to:

"Access was requested, approved, provisioned, reviewed, monitored, and revoked when no longer required."

That is the difference between automating access and governing access.

The Mover case is the right one to build the argument on — Joiners and Leavers are events, and Movers are a state change that nobody gets a notification about.

One thing your architecture handles implicitly but is worth making explicit, because it's the part that tends to be missing when someone finally asks: HR system → JSM → governance decision → Okta → application describes the flow, but not the record.

Six months after Sarah moves to Engineering, the question an auditor asks is rarely "does Sarah have the right access now". It's "when Sarah moved, who decided she should keep the Finance role, and on what date". The provisioning chain doesn't retain that by itself — Okta shows the current grant and, for a while, when it changed. The reasoning lived in the JSM ticket, and whether that ticket still exists, still has the approval visible, and hasn't been edited since is a separate question from whether the automation worked.

So the governance layer needs two outputs, not one: the decision, which drives Okta, and the record of the decision, which nobody reads until they urgently need it. Systems that only produce the first are the ones that feel fine for two years and then can't answer a question.

Disclosure: I build a Jira app in the change-evidence end of this. Nothing to pitch here — the split between the decision and the record of the decision is just the distinction I'd want nailed down before choosing tooling.