If your self-service access request still creates 15 minutes of IT follow-up, the portal didn't solve the problem. The feature that matters is the full handoff from request, to approval, to provisioning, to evidence. I've watched teams get excited about a clean catalog, then realize IT is still chasing managers, updating identity groups, and rebuilding audit proof later. That's where self-service either becomes real, or turns into a nicer front door for the same broken process.
The common mistake is thinking the portal is the product. It isn't. The portal is just the front door. The real system is everything that happens after someone clicks submit.
Key Takeaways:
- Self-service access works when requests, approvals, provisioning, revocation, and evidence stay connected.
- A catalog without ownership rules just creates faster confusion.
- Jira-native workflows reduce the handoff tax because IT, employees, and approvers already live there.
- Time-bound access matters because standing privilege is usually a cleanup problem pretending to be a policy problem.
- Access reviews need usage context and enforced revocation, not another spreadsheet.
- The right feature test is simple: can the system grant access, remove access, and prove both without side work?
Why Self-Service Access Breaks Without Governance
Self-service access breaks when the request experience is separated from the control system behind it. Employees get a portal, but IT still chases approvals, updates identity provider groups, and rebuilds audit evidence later. That gap is where fast access turns into messy governance.
The Portal Usually Gets Too Much Credit
A clean request form feels like progress. I get it. When employees can pick an app from a list instead of sending a Slack message that says "can I get Figma?", it looks like you've fixed the intake problem. Intake is only one piece of self-service access, and it's not even the hardest piece once the company starts growing.
The real test starts after the request is submitted. Who approves it? Does the system know the right role? Can it add the person to the right identity provider group? Can it remove access later? Can an auditor see who approved what without asking IT to pull screenshots from five places? If the answer is no, then you've built a nice front door attached to a messy back office. Looks better. Still breaks.
A separate IGA portal can absolutely make sense for large teams with very complex governance needs. Some teams need deep policy modeling and many layers of certification. Fair. If your employees already request work in Jira Service Management and your approvers already answer in Slack, forcing everyone into another portal adds drag before it adds control. If you're trying to make that shift without adding another place for people to check, Learn more about Multiplier in the context of Jira-native access governance.
Access Requests Become an Evidence Problem
At 50 employees, manual access requests feel annoying. At 500, they become an evidence problem. A new hire on a Monday morning needs Slack, Zoom, Jira, GitHub, Figma, Notion, and a handful of role-specific tools. Then on Tuesday at 2:47 PM, they realize they need two more. Someone asks in Slack, someone files a Jira ticket, someone gets approval in a thread, and someone else updates Okta.
Multiply that by onboarding waves, promotions, transfers, contractors, and offboarding. Fun stuff.
A fintech team that grew to nearly 1,200 employees hit this exact problem. Access requests were coming through Slack, email, and Jira, and IT had to chase approvals and manually assign Okta groups. The work itself wasn't intellectually hard. That was the frustrating part. Each request might take 5 to 30 minutes, but the hidden cost was tracking, audit logging, and the constant fear that one manual step got missed.
The Hidden Cost Is Standing Access
Standing access is what happens when cleanup becomes optional. Someone gets temporary admin access for an incident, the incident ends, and nobody removes it. Not because people are careless. Because the system has no memory unless a human remembers to check.
Self-service access needs to be treated more like an assembly line than a suggestion box. In a good factory, the part doesn't just enter the line and vanish. It moves through stations, gets checked, gets finished, and leaves with a record attached. Access should work the same way: request, approve, grant, expire, review, revoke, prove.
Standing access rarely announces itself. It sits there until a review, incident, or customer audit forces everyone to ask why someone still has a role they haven't used in months. By then, the access problem has already become a trust problem. And trust problems compound faster than access problems.
What Features Make Self-Service Access Work
What features make self-service access work is not a UI question. The real answer is a set of connected controls: a governed catalog, approval routing, identity provider provisioning, time limits, access reviews, and audit evidence. Miss one, and IT keeps doing cleanup by hand.
Start With a Catalog That Only Shows Approved Apps
Before building anything fancy, run this gut check on your current catalog. Pick 10 common access requests from last month and ask whether a new employee could submit each one correctly without asking IT a follow-up question. If 3 or more would still need back-and-forth, your catalog isn't ready. Fix the request shape before you automate anything. Otherwise, automation just moves bad inputs faster.
A useful access catalog should reduce guessing before the request ever reaches IT. Employees should see sanctioned applications, pick the right role, and submit enough context for the approver to make a decision. If the catalog includes every possible tool with no approval status, role mapping, or owner logic, you've just moved the mess into a nicer screen.
The catalog also needs role clarity. Viewer, Editor, and Admin shouldn't be free-text guesses. They should map to actual identity provider groups or defined manual paths. Before, someone says "I need access to Salesforce" and IT has to ask what kind. After, the requester picks the approved app, selects the role, and the system knows what should happen next. Same request. Half the back-and-forth.
Route Approvals Based on Risk, Not Habit
For every app in your catalog, write down the approver in one column and the reason they're the approver in the next column. If the reason is "they've always done it" or "IT knows them," you don't have governance. You have folklore. And folklore doesn't hold up well when the auditor asks why a specific person approved access to a sensitive system.
Approval rules should match the risk of the access, not whoever happened to approve it last time. Low-risk tools can be auto-approved or manager-approved. Admin roles, finance systems, production access, and sensitive data should go to the app owner or a named approver who actually understands the risk. Sounds basic. It often isn't.
There is a real tradeoff here. More approval gates reduce risk, and they slow employees down. I wouldn't add a second approver unless the app meets one of three conditions: privileged access, regulated data, or material financial impact. Anything else should start with one clear owner. Keep the process tight. Add complexity only where the risk earns it.
Provision Through the Identity Provider
Self-service access becomes real when approval triggers the actual change. If IT still has to copy the ticket details into Okta, Entra ID, or Google Workspace, then the employee didn't really self-serve. They just filled out a better ticket.
The identity provider should be the execution layer. Approved roles map to groups. Groups drive access into SSO apps. The ticket records the request, approval, and outcome. When the Jira issue hits the approved status, the group change should happen without someone opening another tab and hoping they picked the right group. That's where the time savings show up.
A good threshold to watch: if more than 25% of approved requests still need manual group assignment, your self-service program is only partially built. That may be fine for non-SSO apps or edge cases. For your common SSO apps, manual provisioning should be the exception, not the operating model. Otherwise, IT remains the bottleneck and the catalog becomes a prettier queue.
Make Temporary Access Expire Without a Reminder
Humans are bad timers. During an incident, nobody wants to stop and schedule a cleanup task. During quarter-end, nobody wants to check which temporary finance roles are still active. By Friday afternoon, the person who granted the access is already buried in something else. Different function, same mistake.
Temporary access should have an end date at the moment it's granted. Not later. Not after someone remembers. Right there in the request. If someone needs elevated access for 1 hour, 6 hours, or 24 hours, the duration should be part of the workflow and the revocation should be automatic.
Stavvy is a good example of why this matters. After funding and acquisitions, they had long-lived privileged access that needed to shrink fast. By moving to time-bound access, they reduced privileged access by 85% and had 1,300+ access requests automatically revoked after approved windows. That's the standard. If access is meant to be temporary, the system should treat expiry as part of the grant, not a future project.
Run Access Reviews Where the Work Already Lives
Access reviews fail when reviewers don't have enough context to make a real decision. A spreadsheet with names and app names forces people to guess. They rubber-stamp, or they delay, or they ask IT for more data. None of those outcomes are great.
A better review shows the reviewer who the user is, what groups they're in, their department, job title, last login, and a recommendation. Then the reviewer can choose Keep or Revoke, add a reason, and trigger the change. The key detail is enforcement. If someone marks Revoke and IT has to go clean it up later, the review is only half done.
Use a 90-day rule as a starting point, not a universal law. If a user hasn't logged into a normal SaaS app in 90 days, revoke should be the default recommendation. For executive tools, seasonal systems, or apps with poor login telemetry, use a longer threshold or manual review. The point isn't to make the number sacred. The point is to stop treating every access review like all access has the same risk.
Keep Evidence Attached to the Original Ticket
Pick one access request from 60 days ago. Can you answer these five questions in under 2 minutes?
- Who requested access?
- Who approved it?
- What exact role was granted?
- When was it granted or removed?
- Where is the proof?
If you can't answer those from the original ticket, your self-service access process isn't audit-ready. Audit evidence should be created while the work happens. If the team has to rebuild evidence later, the workflow is broken. It means approvals, changes, and revocations happened in different places, and now someone has to stitch the story together. That's where what features make self-service access more than a convenience question. The feature set has to produce evidence by default, because nobody wants to spend the week before an audit hunting through Slack, spreadsheets, and identity logs.
Watch for License Waste Before Reviews Catch It
One AI company processed 3,800+ access requests in a year with a 4-person IT Ops team supporting 420+ employees. The reason that model works is because the routine stuff doesn't stay manual forever. Access requests, approvals, and provisioning get standardized. Then the team can focus on higher-value work instead of checking whether someone still needs a license they haven't opened in months.
License reclamation is usually treated like a finance cleanup project. It shouldn't be. If your identity provider knows someone hasn't logged into an app for 30, 60, or 90 days, that signal should start a workflow before the next quarterly review.
The decision rule is pretty straightforward. If an app is expensive, widely assigned, and has reliable login data, automate inactivity checks. If an app is cheap or has weak telemetry, leave it for review campaigns. Don't overbuild. Don't ignore the obvious waste either. The right feature set should reduce tickets, reduce standing privilege, and reduce unused licenses without turning IT into a reporting team.
The catalog, approval, provisioning, expiry, review, and evidence pieces all need to talk to each other. Otherwise, you don't have self-service access. You have a request form with a lot of cleanup behind it.
How Multiplier Brings Governance Into Jira
Multiplier brings access governance into Jira Service Management and Slack by connecting the request, approval, provisioning, review, and evidence trail. The main shift is location. Instead of forcing employees into another IGA portal, the work runs where tickets, approvers, and IT already operate.
Jira-Native Requests With Slack Approvals
Multiplier's Application Catalog gives employees a Jira-native app store for approved applications and roles. They can request access in JSM, or through Slack using the Slack App, while the request still creates a Jira issue as the system of record. That matters because the approval isn't floating around in chat with no audit trail attached.
Behind the scenes, approved catalog roles can map to identity provider groups in Okta, Entra ID, or Google Workspace. When the request reaches the configured approved status, Multiplier provisions through the identity provider group. When asking what features make self-service access actually work in Jira, the difference is that intake, approval, execution, and evidence stay connected instead of splitting across tools. The Slack approval flow is the adoption layer; Jira remains the record.
Access Reviews With Enforced Revocation
Multiplier's Access Reviews run inside JSM, where reviewers can see users, groups, job titles, departments, last login dates, and recommendations. Reviewers mark Keep or Revoke, and revocations can remove users from the relevant identity provider groups. The review decision and the change both tie back to Jira evidence.
That callback matters because earlier we talked about the hidden cost of standing access and review spreadsheets. Multiplier doesn't claim to fix every possible edge case. For non-SSO apps or purely manual grants, automatic removal depends on how the access is controlled. A real limitation. For apps governed through identity provider groups, the review can move from "someone should revoke this later" to "the revocation is part of the workflow." With Multiplier's time-based access, temporary access can also expire after the approved duration, which keeps privileged roles from turning into permanent ones by accident.
Make Self-Service Access Boring in the Right Way
Self-service access should feel boring when it's working. Employees find the app, pick the role, get the right approval, receive access, lose access when they should, and leave behind clean evidence. No drama, no scavenger hunt, and no spreadsheet archaeology.
The buying trigger here is usually growth. At 100 employees, you can muscle through access requests. At 400, the cracks show. At 1,200, the cracks become a system. The feature set that works at that stage isn't a mystery anymore: governed catalog, smart approvals, identity provider provisioning, time limits, reviews with context, and proof inside the ticket.
Multiplier is built around that Jira-native model, so teams don't need to bolt governance onto the side of their service desk. If your access process already starts in Jira and gets nudged along in Slack, Get started with Multiplier and turn that pattern into an enforceable workflow.
Self-service access isn't about removing IT from the process. It's about removing the repetitive work that keeps IT from doing the real work. Once the request, approval, provisioning, expiry, review, and evidence all live together, the whole thing gets a lot easier.
Frequently Asked Questions
How do I set up time-based access for applications?
To set up time-based access with Multiplier, follow these steps: 1) In the application catalog, ensure the app supports time-based access. 2) When a user requests access, they can select a duration (like 1, 6, or 24 hours) during submission. 3) Once approved, Multiplier will automatically provision access and set a timer to revoke it when the duration expires. This helps enforce least privilege and reduces the risk of standing access.
What if I need to revoke access for multiple users at once?
To revoke access for multiple users, you can use Multiplier's Access Reviews feature. Create a campaign for the applications in scope, and assign reviewers. They can easily mark users for revocation based on criteria like last login. This process allows you to manage access efficiently without having to handle each user individually, keeping your access governance tight and organized.
Can I automate license reclamation for unused applications?
Yes, with Multiplier's Auto Reclaim feature, you can automate the reclamation of unused licenses. Set inactivity thresholds (like 30 days) for your applications. When users exceed this threshold, they receive a notification. If they remain inactive after the grace period, Multiplier will automatically revoke their access and generate a Jira ticket documenting the removal. This helps optimize your SaaS spend and keeps your license management efficient.
When should I use the Slack app for access requests?
You should use the Slack app for access requests when your team frequently communicates through Slack. The app allows employees to request access directly from Slack, which creates a Jira ticket automatically. This reduces context switching and speeds up the approval process, as approvers can respond to requests right in Slack. It’s a great way to streamline access requests while maintaining governance.
Why does my access request process need a governed catalog?
A governed catalog is essential because it ensures that employees only see and request approved applications, reducing confusion and errors. With Multiplier's Application Catalog, users can browse sanctioned applications, select roles, and submit requests that include the right context. That cuts the back-and-forth with IT and gets requests moving faster.
