nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Why most Jira Service Management onboarding processes break after Day 1

James Anderson

Many teams automate employee onboarding in Jira Service Management, but the workflow often stops once the ticket is closed.

The bigger challenge starts afterwards:

Who verifies users still need access after 90 days?
How do you remove access when someone changes teams?
How do you prove to auditors who approved each permission?
How do you identify orphaned accounts?

We noticed that many organizations have great ticketing workflows but still rely on spreadsheets or manual reviews for access governance.
A better approach is to think of access as a complete lifecycle:
Request → Approval → Provision → Review → Revoke
This keeps onboarding, access reviews, and offboarding connected instead of treating them as separate processes.
I'm curious:

How are you handling periodic access reviews today?
Jira Automation?
Custom scripts?
Marketplace apps?
Something else?

I'd love to hear how other teams have solved this.

Accepted answers

Marc -Devoteam-

Hi @James Anderson

If access would need to be revoked, add and end-date of the users contract in the onboarding request.

Base a filter on this, show this filter on a gadget in a dashboard, have automation in place to run a flow on a schedule looking at data field(s) and create off-board request based on work items returned based on date.

Emma Phillips

One thing we've learned is that onboarding is usually well automated, but access reviews often aren't. During audits, it's difficult to prove who approved access, whether it was ever reviewed, or if it should still exist. Having periodic certifications and automatic revocation workflows makes a huge difference, especially for regulated environments. The complete audit trail becomes just as important as the initial provisioning.

All comments

Marc -Devoteam-

Hi @James Anderson

If access would need to be revoked, add and end-date of the users contract in the onboarding request.

James Anderson

I like this approach. Have you seen teams use the same pattern for permanent employees who change roles or departments? In my experience, the end date works well for contractors, but role changes are often harder to track because there's no predefined expiration date.

Marc -Devoteam-

You could use this for department changes as well.

Use a dat field on when the department switch was done and monitor based on that date.

Or have a schema for employees in Assets and add dates.

But this requires a paid subscription

Emma Phillips

James Anderson

@Marc -Devoteam-

That's a good point. Using Assets as the source of truth for employee attributes makes the automation much easier to manage.

One thing I'd add is that department changes often require both provisioning and deprovisioning. It's not just about granting access to the new department, but also ensuring access from the previous role is reviewed and removed where appropriate. That tends to be the more challenging part in larger organizations.

James Anderson

Hi @Emma Phillips

Exactly. Provisioning someone’s access is usually the easy part. The harder question is what happens a few months later. Was the access ever reviewed? Does the person still need it? Was it removed when their role changed or when they left? That’s where periodic reviews and a proper audit trail become really useful.

It’s not just about proving that access was approved initially, but being able to show that it was continuously reviewed and eventually removed when it was no longer needed.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

automation

governance

jira-admin

jsm