If you had to chase 3 access approvals this week, your problem probably isn't the approval policy. Your problem is that you're trying to automate access requests in one place while the actual work happens in Jira, Slack, Okta, Entra, Google Workspace, spreadsheets, and some random DM from Tuesday.
And honestly, that setup can look fine for a while. At 100 employees, you can brute force it. At 500 employees, the queue starts to smell. At 1,200 employees, every access request becomes a tiny operational tax that compounds.
The old answer was to buy a separate identity governance portal. I get the logic. But if employees already ask for access in Jira and approvers already live in Slack, adding another portal can make the workflow slower, not safer.
Key Takeaways:
- Access request automation fails when requests, approvals, provisioning, and evidence live in different tools.
- If your team uses Jira Service Management, governance should sit close to the Jira issue, not off in a separate portal.
- Time-bound access should be the default for elevated permissions, especially production, finance, data, and admin roles.
- The cleanest audit trail is created during the access workflow, not rebuilt later from screenshots.
- Strong access automation needs 4 things: intake, approval routing, identity provider provisioning, and expiry.
- If more than 30% of requests require manual follow-up, your access process is still too fragile.
Why Access Request Automation Breaks Outside Jira
Access request automation breaks when the ticket, approval, identity change, and audit evidence live in separate systems. Each handoff creates delay, missing context, and cleanup work. In Jira-heavy companies, the workflow usually starts in JSM anyway, so moving governance outside Jira often adds one more place for work to get lost.
The Portal Nobody Wants to Use
A separate IGA portal sounds clean on a slide. I get why security likes it. You get policies, reviews, access models, entitlement language, all the grown-up stuff auditors expect. But then an employee needs Figma Editor access, and what do they do? They ask in Slack. Or they file a Jira ticket. Or they message the IT person they know will answer quickly.
Now IT has two jobs. They have to fulfill the request, and they have to drag the request back into the “proper” system after the fact. That second job is where the waste lives. The access might be correct, but the evidence is scattered. The approver said yes in Slack, the actual group change happened in Okta, and the Jira ticket has a comment that says “done.” Not exactly audit-ready.
A 9:14 AM request becomes a small scavenger hunt. The employee posts in Slack because they can't find the right request type. The IT analyst creates or updates a Jira issue. The manager approves in a thread. Someone adds the user to an identity provider group, then leaves a note for audit. By 4 PM, the employee has access, but nobody set an expiry, and the whole thing depends on a human remembering what happened.
That's the access governance version of doing finance from receipts in a shoebox. The transaction happened. The record is technically there. But when you need proof, you're digging.
The Real Cost Is the Handoff
The hidden cost of access request automation isn't the request. It's the handoff between systems. If one person asks, one approver approves, one admin provisions, and one auditor later verifies, you already have 4 chances to lose context before anything even goes wrong.
I saw this same pattern in content years ago. When I was the sole marketer, I could move fast because all the context was in my head. Then the team grew, and every handoff made the work slower. Access works the same way. The process doesn't fail because people are lazy. It fails because the context keeps moving.
Security frameworks have been saying least privilege matters for a long time. NIST's access control guidance, especially AC-6 on least privilege, is clear on reducing unnecessary access. The problem is not knowing the principle. The problem is enforcing it every day without turning IT into the company bottleneck.
If your access request workflow needs a ticket, a Slack thread, an identity provider change, a spreadsheet update, and a quarterly cleanup, you're not automating access. You're automating pieces of it and hoping the gaps don't matter.
For teams already running Jira Service Management, See Multiplier on the Atlassian Marketplace if you want to see what access governance looks like when the request, approval, provisioning action, and evidence stay tied to the Jira issue.
Why Audits Expose the Broken Workflow
Audits don't create access problems. They expose them. If your team has to spend 2 weeks rebuilding who approved what, who granted what, and whether access was removed on time, the audit is just showing you the workflow never created usable evidence in the first place.
Luno is a good example. They grew to nearly 1,200 employees, with hundreds of access requests coming through Slack, email, and Jira. IT had to chase approvals and manually assign Okta groups. Each request might have taken 5 to 30 minutes, which doesn't sound terrible until you multiply it across hundreds of tickets every month.
There is a fair argument for separate IGA tools. They can make sense in very large enterprises with complex entitlement models, dedicated governance teams, and months to implement. Fair. But for mid-market and high-growth companies running on Jira, the heavier portal often solves the reporting model while making the daily workflow worse.
And daily workflow wins. Always.
How to Automate Access Requests Without Weakening Governance
The right way to automate access requests is to keep intake, approval, provisioning, expiry, and evidence in one workflow. Start with the Jira request, route approvals where people already work, provision through the identity provider, and write every decision back to the original issue. That gives you speed without losing control.
Start by Diagnosing Where Requests Actually Die
Before you automate access requests in Jira, look at the last 50 access tickets and find where the delay really happened. Don't guess. Tag each request by delay point: missing requester context, unclear approver, approval wait, manual provisioning, license confusion, or evidence cleanup.
The pattern usually gets obvious fast. If more than 30% of requests are waiting on approvers, your issue isn't provisioning yet. It's routing. If more than 20% need IT to ask “what role do you need?”, your intake form is broken. If access gets granted quickly but never removed, your expiry model is the problem. Different failure point, different fix.
I like this audit because it takes the debate out of it. Security might think the issue is standing privilege. IT might think the issue is volume. Employees might think the issue is “IT is slow.” All three can be true, but the ticket data will tell you where to start.
Run the review like this:
- Pull the last 50 access requests from Jira.
- Mark the first delay point for each request.
- Count how many required manual identity provider changes.
- Count how many had a clear approver at creation.
- Check how many included expiry or removal evidence.
If you can't answer those questions from Jira alone, there's your problem. The system of record doesn't have the record.
Treat Jira as the Control Plane, Not Just the Ticket Queue
Jira should not just be the place where access requests go to wait. It should be the control plane for access work. The request comes in, the right approver is attached, the workflow moves status, provisioning happens through the identity provider, and the evidence lands back on the issue.
That sounds obvious. But most teams don't run it that way. They use Jira for intake, Slack for the actual decision, Okta or Entra for the real change, and spreadsheets for audit cleanup. Then someone wonders why access reviews take forever.
The better mental model is manufacturing. You wouldn't build a production line where the order starts in one system, the approval happens in a hallway conversation, the assembly step happens on a different floor, and quality control gets a photo three months later. Access should work like a controlled line. Every request moves through known stations, and every station leaves a trace.
For Jira-first companies, the workflow should include:
- A structured request type: App, role, reason, duration, and business context should be captured up front.
- A named approver path: Manager, app owner, or specific user should be known before IT touches the ticket.
- An identity provider action: Okta, Entra, or Google Workspace should be the source of the actual group change.
- An expiry rule: Elevated access should have a clock attached to it.
- Evidence on the issue: Approval, grant, failure, and revocation should be visible from the Jira record.
If the Jira issue can't tell the whole access story, the workflow is still split. And split workflows always create cleanup.
Make Time-Bound Access the Default for Risky Roles
Time-bound access is the easiest least privilege improvement most teams aren't using enough. If someone needs admin access for 1 hour, 6 hours, or 24 hours, give them the window they need and remove it automatically when the job is done. Don't make permanent access the default just because manual cleanup is annoying.
Stavvy is a clean example here. After funding and acquisitions, they had long-lived privileged access that didn't fit where the company was going. They moved toward just-in-time access, and privileged access dropped by 85%. Over 1,300 access requests were automatically revoked after the approved window. That's the kind of number that changes the conversation.
The counterpoint is real though. Time-bound access can annoy employees if the process is clunky. Engineers don't want to file a ticket every 12 minutes during an incident. Finance doesn't want to lose access halfway through close. Fair criticism. The answer isn't to avoid expiry. The answer is to match duration to risk.
Use a simple rule:
- Low-risk SaaS access: Approve normally, review quarterly.
- Sensitive business apps: Require manager or app owner approval, review usage.
- Admin or production access: Require time-bound access by default.
- Break-glass access: Allow fast approval, but force a short window and detailed reason.
A good access process should feel boring most of the time. The risky stuff gets guardrails. The normal stuff moves quickly.
Build Evidence During the Workflow, Not After
Audit evidence should be a byproduct of the access request workflow. If your team has to create evidence after the fact, you already lost. The clean version is simple: requester, approver, decision, provisioning action, expiry, and revocation all attach to the same Jira issue.
This matters because audits are not just about whether the right thing happened. Auditors need to see proof that the right thing happened, at the right time, by the right person, with the right control. A Slack approval and an Okta screenshot can work once. Across hundreds of requests, it becomes a mess.
Verizon's 2024 Data Breach Investigations Report keeps showing how much identity and credential issues matter in real incidents. You don't need to overreact to every report, but the broad lesson is hard to ignore. Access is not admin paperwork. Access is part of your risk surface.
The evidence test is pretty simple:
- Can you see who requested access?
- Can you see who approved it?
- Can you see what group or entitlement changed?
- Can you see when access was removed?
- Can you export the evidence without rebuilding it?
If the answer is no, don't call it automated access governance yet. Call it ticketing with extra steps.
Access request automation gets a lot easier when Jira stays the record and the identity provider executes the change. If you want to compare that model to your current process, Try Multiplier on the Atlassian Marketplace and map it against your last 50 access tickets.
Separate Catalog Requests From Lifecycle Changes
Access requests and lifecycle changes are cousins, not twins. A catalog request is usually “I need this app or role.” A lifecycle change is “this person joined, moved departments, changed manager, or left the company.” If you mix those together, the workflow gets ugly fast.
For catalog requests, the employee experience matters a lot. People should be able to find sanctioned apps, pick a role, add context, and submit. No guessing. No “who owns this app?” detective work. If the catalog is clear, IT gets better data and the approver sees the request in a format they can act on.
Lifecycle work needs a different shape. New hire onboarding might create an Entra account, add department groups, assign licenses, and trigger app access based on role. Offboarding might disable accounts and remove key groups. Promotions and transfers might update attributes and change access patterns. Same governance goal, different workflow.
A practical split looks like this:
- Use catalog requests for ad hoc app access and role changes.
- Use lifecycle workflows for onboarding, transfers, and offboarding.
- Keep both tied to Jira issues.
- Push actual access changes through the identity provider.
- Make revocation visible, not implied.
Vuori is a good mental picture. They were dealing with onboarding, offboarding, and employee changes at scale, and the manual spreadsheet approach was getting painful. Once lifecycle work moved into structured Jira workflows with automation, they saved 100+ workdays in a year. That's not a tiny improvement. That's a team getting time back.
Use Access Reviews to Catch What Automation Misses
Access reviews are the safety net, not the main access control. If quarterly reviews are your only least privilege mechanism, you're basically letting access drift for 90 days and then asking managers to clean it up in a spreadsheet. That is how rubber-stamping happens.
Better access reviews start with better daily workflow. If requests are structured, approvals are captured, and provisioning runs through identity provider groups, reviewers get useful context. They can see department, title, group membership, last login, and the original request history. Now the review is a decision, not a scavenger hunt.
The rule I like is pretty simple. If a reviewer needs more than 30 seconds to decide whether a user should keep access, the review screen is missing context. Either the app owner doesn't know the user, the role names are unclear, or usage data is absent. Fix that before yelling at reviewers for being slow.
Strong reviews usually include:
- User name, department, title, and manager
- Application and role
- Group membership
- Last login or usage context
- Recommended keep or revoke action
- Reason capture for revocations
- A generated ticket when access is removed
Access reviews shouldn't feel like homework nobody wants to do. They should feel like a cleanup pass on a system that's already doing most of the right things.
How Multiplier Automates Jira Access Governance
Multiplier automates Jira access governance by keeping requests, approvals, provisioning, time-bound access, reviews, and evidence inside Jira Service Management and Slack. It provisions through Okta, Entra ID, or Google Workspace groups, then writes status and audit activity back to the Jira issue. The point is simple: less swivel chair work, cleaner evidence.
Jira-Native Requests With Identity Provider Provisioning
Multiplier starts with a Jira-native application catalog, so employees request approved apps and roles from the JSM portal or Slack. Multiplier syncs apps and groups from Okta, Entra ID, and Google Workspace, then maps catalog roles to identity provider groups. Once the request is approved, Multiplier adds the user to the mapped group and records the action on the Jira issue.
That matters because it removes the worst part of the old workflow. No more Jira ticket, then Slack approval, then manual group assignment, then comment, then screenshot. Approval workflows can route decisions to managers, app owners, or specific users, with approvers acting in JSM or Slack. The Jira issue stays the record.
Multiplier also supports time-based access for elevated roles. Requesters choose a duration, like 1, 6, or 24 hours. After approval, access is granted through the identity provider group, and when the timer expires, Multiplier removes the group membership and logs the revocation. For teams trying to automate access requests in Jira without creating standing privilege everywhere, that expiry loop is the big unlock.
Reviews, Reclaims, and Audit Evidence in Jira
Multiplier's access reviews run inside JSM, so reviewers can make keep or revoke decisions with user attributes, group memberships, last login, and recommendations in front of them. Revocations remove users from the relevant identity provider groups and create Jira evidence. Admins can export review results as CSV or push evidence to Vanta.
Auto Reclaim handles a different but related problem: unused licenses. Multiplier monitors last-login data from connected identity providers, applies inactivity thresholds and grace periods, warns users, then revokes access if they stay inactive. Worth noting, Auto Reclaim is available on the Advanced edition, and it depends on accurate login data from the identity provider.
For the Luno-style problem, where routine requests used to take 5 to 30 minutes and pile up across hundreds of tickets, the change is pretty direct. The request starts in Jira or Slack. Approval happens where people already work. Provisioning happens through the identity provider. Evidence stays attached to the issue.
If your team is ready to stop rebuilding access evidence after the fact, Get Multiplier from the Atlassian Marketplace and use your current Jira queue as the baseline.
Put Access Governance Where the Work Already Happens
Access request automation gets a lot easier when you stop treating governance like a separate destination. If the request starts in Jira, the approval happens in Slack, and the access change runs through your identity provider, then the record should connect all of it.
The old model created too many gaps. Jira had the ticket. Slack had the decision. Okta or Entra had the actual change. Spreadsheets had the audit story. Everyone worked hard, but the process still leaked.
The better model is tighter. Automate access requests in Jira, route approvals where people respond, provision through the identity provider, set expiry on risky access, and let evidence build while the work happens. Less cleanup. Fewer standing privileges. Cleaner audits.
And honestly, that’s the whole point. Not more governance theater. Better access control that people will actually use.
Frequently Asked Questions
How do I set up time-based access for specific roles?
To set up time-based access with Multiplier, start by defining the roles that require temporary access. When employees request access through the Jira Service Management (JSM) portal or Slack, they can select a duration for their access (like 1, 6, or 24 hours). Once the request is approved, Multiplier automatically provisions access and sets a timer to revoke it once the duration expires. This helps enforce least privilege without manual follow-ups, ensuring that access is only granted for the necessary time.
What if I need to revoke access quickly?
If you need to revoke access quickly, you can do so through the access review feature in Multiplier. During access reviews, reviewers can mark users for revocation based on inactivity or other criteria. Once a decision is made, Multiplier automatically removes the user from the relevant identity provider groups and creates a Jira ticket documenting the change. This process ensures that revocations are executed reliably and that you maintain a clean audit trail.
Can I automate approval workflows in Slack?
Yes, you can automate approval workflows in Slack using Multiplier. When an access request is submitted, the approver receives a notification in Slack with options to approve or deny the request directly from the chat. This integration keeps the approval process fast and efficient, as decisions are made where your team already communicates. Just ensure that your approval workflows are set up correctly in Multiplier to route requests to the right approvers.
When should I use the application catalog?
You should use the application catalog whenever employees need to request access to sanctioned applications. The catalog provides a user-friendly interface within the JSM portal, allowing employees to browse approved apps, select roles, and submit requests easily. This streamlines the intake process and ensures that requests include the necessary context upfront. By using the catalog, you can reduce the administrative burden on IT and improve the overall access request experience.
Why does access governance need to be integrated with Jira?
Integrating access governance with Jira matters because it keeps all aspects of the access request process—intake, approval, provisioning, and evidence—within a single system. This reduces the risk of losing context between different tools, which often leads to delays and compliance issues. With Multiplier, you can manage access requests directly in Jira, ensuring that every action taken is logged and easily auditable, which simplifies the governance process and enhances security.
