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

Okta is really good at managing identities.

It can create users, manage groups, assign applications, and automate a lot of the repetitive work around user lifecycle management.

Jira Service Management is good at something different: requests, approvals, workflows, etc.,

So what happens when you put the two together?

The interesting part isn't just provisioning the access.

It's deciding what access the person should actually get, why they should get it, and what happens to that access later.

The provisioning part is usually the easy part

Imagine an employee joins the company.

Their manager requests access to:

• Salesforce

• GitHub

• AWS

• Jira

• Confluence

The request goes through and person gets access.

That part can be automated quite nicely.

But six months later, a different question comes up:

Does this person still need all of that access?

That's where things get more complicated.

The "Mover" problem

Employee lifecycle is often described as:

Joiner → Mover → Leaver

Joiners usually get the most attention because onboarding is visible and time-sensitive even though manual process is hectic.

Leavers also get attention because removing access quickly is a security requirement though sometimes some random access given during the period is untraceable and not revoked later.

Movers are often the awkward middle child.

For example:

Sarah starts in Finance.

She gets:

• Salesforce

• Finance ERP

• Finance-related Okta groups

Six months later, Sarah moves to Engineering.

She now needs:

• GitHub

• AWS

• Engineering groups

It's easy to add the new access.

But what happens to the old access?

Does someone remember to remove the Finance groups?

Does anyone review whether she still needs Salesforce?

Was the change approved?

Can you prove when the old access was removed?

This is where simply connecting JSM and Okta isn't the whole governance story.

JSM can handle the decision. Okta can execute it.

A useful way to think about the relationship is:

Jira Service Management = request, approval and governance

Okta = identity and access execution

For example:

1. An access request is submitted in JSM.

2. The workflow determines what access is being requested.

3. The appropriate person approves it.

4. Through Okta the required user/group/application gets access.

5. The action is recorded.

6. Later, the access can be reviewed.

7. If the access is no longer justified, it can be revoked.

The important part is that provisioning isn't treated as the end of the process.

It's one step in the lifecycle.

What about temporary access?

This becomes even more interesting with privileged or temporary access.

Suppose someone needs administrator access to an application for two days.

The request should answer:

• Who requested it?

• Why is it needed?

• Who approved it?

• What access was granted?

• When should it expire?

• Was it actually removed?

Without the expiry and revocation part, "temporary access" can quietly turn into permanent access.

Nobody intended that. It just wasn't revisited.

Periodic access reviews close the loop

This is probably the most overlooked part.

An access request tells you:

"Someone approved this access."

An access review asks:

"Does this access still make sense today?"

Those are two different questions.

A useful governance workflow can periodically ask application owners or managers to review existing access and either:

Keep it

or

Remove it

That creates a much stronger audit trail than simply having a historical provisioning record.

The bigger picture

I don't think the answer is replacing Okta with JSM, or replacing JSM with an identity platform.

They solve different problems.

The more interesting architecture is:

HR system → JSM → Governance decision → Okta → Application

The HR system tells you that something changed.

JSM provides the workflow and approval.

The governance layer determines what should happen.

Okta executes the identity and access changes.

And the audit trail connects everything together.

That's the part that turns "access was provisioned" into something more useful:

"Access was requested, approved, provisioned, reviewed and, when necessary, revoked."

For me, that's the difference between access automation and access governance.