Videoamp hit 500 employees, and Tuesday became the day IT got buried in access requests with missing details. That's when a no-code self-service portal stops being a nice IT project and starts deciding whether Jira stays clean or turns into another approval inbox. If the request starts in one place, gets approved somewhere else, and needs evidence rebuilt later, you didn't fix access management.
The portal looks like progress. Employees get a nicer form, IT gets fewer random Slack messages, and for about three weeks, everyone feels good. Then the same broken loop comes back: missing context, approval chasing, manual group changes, and audit evidence rebuilt later from screenshots.
I've seen this pattern in a bunch of ops problems. The tool isn't always the issue. The system around the tool is. And with access requests, the system only works if the request, approval, provisioning, expiry, and audit trail stay tied together from the start.
Key Takeaways:
- No-code self-service portals for access only work if they connect intake, approval, provisioning, and evidence.
- If approvals happen in Slack but evidence lives in Jira, Jira needs to stay the record.
- A good access catalog should reduce back-and-forth by forcing role, app, approver, and duration choices up front.
- If more than 25% of approved requests still need manual IDP work, the portal is intake-only, not access governance.
- Time-bound access should be the default for elevated roles, not a special security project.
- Audits get easier when evidence is created during the workflow, not rebuilt after the fact.
Why Access Portals Still Create Jira Backlog
Access portals still create Jira backlog when they only improve the front door. The request may look cleaner, but approvals, provisioning, expiry, and audit evidence still happen somewhere else. Once those steps split across tools, IT is back to chasing people and stitching together proof.
The portal fixes intake, then the work leaks out
A no-code portal can make the first five minutes better. Employees pick an app, submit a form, and stop sending random messages to IT. Good. That part matters. Still, if the approval goes to email, the group change happens in Okta, and the proof gets pasted into Jira later, you haven't really changed the operating model.
Self-service access isn't a form problem. It's a chain problem. If one link still depends on a person remembering to update another system, the backlog comes back. The giveaway is simple: if an access request closes only after an IT admin manually checks three places, the portal is mostly a prettier queue.
One practical test: pull 20 closed access tickets from last month. Count how many required a follow-up comment, a manual approver nudge, or a manual identity provider change after approval. If the number is over 5, your no-code self-service portal for access requests is not reducing work. It's moving work around.
The Tuesday access spike tells the truth
A workplace tech manager opens Jira at 9:14 AM on Tuesday. Six new requests sit there for Loom, Figma, GitHub, and some app only one department uses. Slack has two people asking whether their manager approved. Okta has the actual group mapping, but the ticket doesn't say which role they need. You can feel the waste in that moment.
Videoamp had the classic version of this problem. New hires started Monday. By Tuesday, IT had a flood of app requests with missing details, unclear app ownership, and lots of repeated work. They weren't failing because the IT team was bad. They were failing because the process didn't force enough context into the request before it hit the queue.
That story matters because it's exactly where a portal either earns its keep or becomes another screen. If the employee can only request "Figma," IT still has to ask "Viewer or Editor?" If the role isn't mapped to the IDP group, IT still has to translate the request. If the approver isn't assigned up front, someone still has to hunt.
The cleaner path is boring, which is why it works. App, role, approver, duration, identity group, ticket. All defined before the request lands. If that's the workflow you're trying to build inside Jira, Learn more about Multiplier in the context of replacing follow-up work with a governed app catalog.
Audits shouldn't be rebuilt after the work is done
Audits become painful when the evidence is created after the workflow instead of during it. Someone exports a spreadsheet. Someone checks Jira comments. Someone asks for screenshots. Someone tries to remember whether the approval happened in Slack or email. It works, kind of. It's also fragile.
Think of it like a shipping label. If the label is printed when the package moves, tracking is natural. If someone has to rebuild the route three months later by calling every warehouse, the process is broken. Access governance works the same way. The ticket should carry the request, the approval, the grant, the expiry, and the removal.
A useful threshold: if preparing access evidence for an audit takes more than 2 hours per app in scope, you're not audit-ready. You're audit-reconstructing. Different thing. And that difference is why a self-service portal by itself doesn't solve the deeper problem.
How to Build Self-Service Access That Actually Holds Up
Self-service access holds up when the catalog becomes the control point, not just the request form. The request should capture enough information to route approvals, provision through the identity provider, expire access when needed, and leave a clean Jira record behind.
Start by sorting requests by operational risk
About 80% of access requests usually fall into predictable buckets: standard app access, role changes, elevated access, joiner changes, mover changes, and offboarding. The exact mix changes by company, but the sorting exercise is the part most teams skip. And skipping it makes every request feel custom.
Before you build no-code self-service portals for access, ask four questions on your last 50 requests. Did the request involve a sanctioned app? Was the access low-risk or elevated? Did it need a manager or app owner approval? Could the access have expired automatically? Those answers tell you which requests belong in the catalog, which need time limits, and which should stay manual for now.
The rule I like: don't automate a request type until you've seen it at least 10 times and can define the approval path in one sentence. For example, "Figma Editor goes to the app owner, then maps to the Figma-Editors group." Nice and clean. "Ask finance what they think and maybe add them to the right thing" is not ready for automation. Not yet.
Some teams prefer starting with everything in the catalog, and I get the logic. It feels faster. The downside is mess. If the catalog launches with unclear apps, unclear roles, and unclear owners, employees lose trust fast. Better to launch with 15 to 25 high-volume apps that are properly mapped than 80 half-finished tiles that create more questions.
Make the catalog opinionated, not open-ended
A self-service access catalog should make the right request obvious. Employees shouldn't have to know the name of an identity provider group. They shouldn't have to guess whether they need Viewer, Editor, Admin, or some weird internal role name created three years ago. The catalog should translate business language into access rules.
A good catalog item has four pieces of context: what the app is, which roles are available, who approves each role, and whether access can be time-bound. Without those four, you're asking the employee to do IT's design work. They won't. They'll write "need access asap" in the notes field and move on with their day.
Use this quick build order: 1. Pick the top 20 requested apps from the last 90 days. 2. Define 2 to 4 roles per app, not 12. 3. Map each role to one or more identity provider groups. 4. Assign a default approver for each app. 5. Mark which roles need temporary access by default.
There's a real tradeoff. A more opinionated catalog takes more setup up front. Fair. The setup pays back every time a request arrives with the right role, the right approver, and the right downstream group already attached. That's when a self-service access portal stops being a form project and starts becoming an operating system.
Slack is the interface. Jira is the ledger.
Slack is where approvals actually happen for a lot of companies. You can fight that, or you can design for it. I wouldn't fight it. People already live there, and a one-click approve or deny in chat is far better than an email someone ignores for two days.
The catch is evidence. Slack is a great decision surface, and Jira is a better system of record. If an approver clicks approve in Slack, the action should update the Jira issue, trigger the workflow transition, and preserve the audit trail. Otherwise, you end up with the worst version of chat-first work: fast decisions with weak records.
Use a simple rule: Slack can be the interface, but Jira must be the ledger. Every approval should point back to the ticket. Every ticket should show who asked, who approved, what changed, and when it changed. If that chain breaks, audit work gets expensive again.
Luno ran into this at scale. Access requests came through Slack, email, and Jira while IT still had to chase approvals and manually assign Okta groups. After moving requests into a Jira-centered app store with Slack approvals and automated group assignment, they reported an 80% reduction in IT workload on access requests. That's not magic. That's what happens when the decision and the execution stop drifting apart.
Automate provisioning only after the approval path is clean
Provisioning is where access portals either save time or create risk. A clean approval where the role maps cleanly to an identity provider group is an easy automation win. A vague request with an unclear approver, automated, just moves the mistake faster.
The diagnostic is pretty simple. For each app role, can you write: "When status becomes Approved, add user to group X"? If yes, that role is a good automation candidate. If no, keep it manual until the mapping is clear. Less exciting than automating everything, sure. It's also how you avoid weird access grants that no one wants to explain later.
A strong first wave usually includes apps with stable roles and clear ownership. Think standard SaaS tools, department apps, and low-risk access levels. Elevated roles should come later, with duration built in from the start. The point isn't to automate the riskiest thing first. The point is to build trust with repeatable requests, then expand.
Track one number here: approved requests that still require manual IDP work. If that stays above 25% after the catalog is live, your process is stuck halfway. The portal is collecting requests, and IT is still doing the work behind the curtain. That's the hidden tax everyone eventually feels.
Use time limits before you write another policy
Standing access is often a cleanup failure disguised as a policy problem. Someone needed admin access for an incident, nobody wanted to block them, and the request got approved. Then the access stayed there for six months because revocation depended on memory. You can write a stronger policy, sure. If the workflow doesn't revoke access, the policy is mostly theater.
Time-bound access changes the shape of the problem. The requester chooses 1 hour, 6 hours, 24 hours, or whatever windows you allow. The approver decides with that duration in mind. Once the window closes, the access comes off automatically through the identity provider group membership. Simple. Hard to argue with.
Use this conditional rule: if access is privileged, production-related, financial, customer-data-related, or license-heavy, make it temporary by default. If the same person asks for the same elevated access three times in 30 days, review whether the role is actually part of their job. Don't punish the requester. Study the pattern.
A lot of teams push back here because they worry about friction. That's a fair concern. Bad time-bound access can absolutely slow people down during real incidents, and a sleepy approver at 2 AM during a Sev1 is a real cost. The fix isn't to avoid expiry. The fix is to make extensions one-click for already-approved requests, and to keep the decision in the same workflow. Fast access and least privilege aren't opposites if the system is built correctly.
Treat access reviews as cleanup, not discovery
Access reviews shouldn't be the first time you discover stale access. By the time a quarterly review finds a user who hasn't logged in for 90 days, you've already paid for unused access and carried extra risk. The review still matters. It just shouldn't be doing all the work.
The better model is layered. Daily workflows handle clean requests, approvals, expiry, and revocation. Usage-based signals reclaim licenses when people stop using tools. Quarterly access reviews confirm that the system is behaving the way you expect. That makes reviews smaller, clearer, and less painful.
A practical review rule: if reviewers revoke more than 15% of access during a campaign, look upstream. High revocation rates usually mean too much standing access, poor offboarding, weak mover workflows, or no usage-based reclamation. The access review is showing you a process problem, not just a user problem.
Reviewer fatigue is real too. Send app owners a spreadsheet with 400 rows and no context, you get rubber-stamping. Show department, title, groups, last login, and a keep-or-revoke choice inside the service desk, the decision gets easier. Not perfect. Better.
How Multiplier Turns Jira Into the Access Front Door
Multiplier turns Jira into the access front door by putting the catalog, approvals, provisioning actions, time limits, and review evidence inside JSM and Slack. The work still runs through your identity provider, but the request record stays in Jira from start to finish.
The catalog lives where employees already ask for IT help
Multiplier's Application Catalog creates a Jira-native app store inside JSM, so employees can browse approved apps, pick roles like Viewer or Admin, and submit requests without learning a new access portal. It syncs apps and groups from Okta, Entra ID, or Google Workspace, and only approved catalog items appear for requesters. That's the part I like. It respects the system people already use.
The Slack App extends the same idea into chat. Employees can start requests from Slack, and approvers can approve or deny from Slack DMs, while the Jira issue remains the record. That matters because chat speed without Jira evidence is just another fragmented process. Multiplier keeps those actions tied back to the ticket, so IT doesn't have to rebuild the story later.
Provisioning runs through mapped identity provider groups after approval. Multiplier doesn't directly provision inside every SaaS app. That's an important boundary. For SSO apps where group-based provisioning is already the path, it removes the manual step of adding a user to the right group and writes the outcome back to Jira. The old 5 to 30 minute admin task becomes a governed workflow.
Time-bound access and reviews make the audit trail part of the work
Multiplier also handles time-based access by adding users to mapped IDP groups for a defined duration, then removing them when the window expires. That supports the rule from earlier: elevated access should expire by default. The grant, approval, and revocation live on the Jira issue, which gives auditors a cleaner story than scattered comments and screenshots.
Access Reviews run in JSM too. Admins create campaigns, select approved apps, assign reviewers, and reviewers see user attributes, group memberships, last login, and recommendations before choosing Keep or Revoke. Revocations can remove users from relevant IDP groups and create Jira tickets documenting the change. For teams that need audit exports, Multiplier can export results as CSV or push evidence to Vanta.
Auto Reclaim covers the license side for Advanced edition customers. It uses identity provider login data, inactivity thresholds, grace periods, and exclusions to warn users before revoking unused access. If the user stays inactive, access is revoked and a Jira ticket is generated. The same access system can support no-code self-service portals for access, least privilege, access reviews, and license cleanup without forcing IT into a separate governance portal.
The practical payoff is focus. Videoamp processed 500+ app requests in 6 months through a Jira-embedded catalog and saved 70+ hours of IT time. Luno cut access request workload by 80%. If the goal is to stand up the first working version without retraining the company on another portal, Get started with Multiplier from the catalog and Slack approval flow.
Make Access Requests Boring Again
No-code self-service portals for access requests are only useful when they remove the work behind the form. A good portal captures the right context, routes the decision, triggers the group change, expires risky access, and leaves evidence in the ticket. Anything less is a nice interface wrapped around the same old backlog.
Start small. Pick the 20 apps that create the most repeat requests. Define the roles. Map the approvers. Decide where time limits apply. Then measure how many approved requests still need manual identity provider work. If that number drops, you're not just adding self-service. You're building access governance that can actually hold up.
Frequently Asked Questions
How do I set up time-based access for my apps?
To set up time-based access with Multiplier, follow these steps: 1) In the application catalog, ensure that the app allows for time-based access. 2) When employees submit a request, they can choose a duration (like 1 hour or 24 hours) for their access. 3) After approval, Multiplier automatically provisions the access and sets a timer to revoke it once the duration expires. This ensures that elevated access is temporary by default, reducing security risks.
What if I need to revoke access quickly?
If you need to revoke access quickly, you can do this through the access review feature in Multiplier. Simply create a new access review campaign, select the relevant applications, and assign reviewers. They can mark users for revocation based on inactivity or other criteria. Once approved, Multiplier will automatically remove users from the relevant identity provider groups and log the changes in Jira, leaving a clear audit trail.
Can I automate approvals for low-risk access requests?
Yes, you can automate approvals for low-risk access requests using Multiplier. Set up your approval workflows in Jira Service Management (JSM) by designating default approvers for specific applications. For low-risk requests, you can configure the system to auto-approve them, which speeds up the process. This way, routine approvals happen quickly, while higher-risk requests still go through the necessary review process.
When should I perform access reviews?
You should perform access reviews regularly, ideally quarterly, to ensure that users still require access to applications. With Multiplier, you can streamline this process by creating access review campaigns in JSM. Admins can select approved apps, assign reviewers, and launch the campaign to assess user access. This proactive approach helps maintain security and compliance while minimizing stale access.
Why does my access request process still feel slow?
If your access request process feels slow, it may be due to fragmented workflows. Ensure that all steps—from request to approval and provisioning—are integrated within Multiplier and Jira. By using the Application Catalog in JSM, employees can submit requests with all necessary context upfront, reducing back-and-forth communication. If approvals happen outside of JSM or Slack, consider routing them through these platforms to keep everything tied to the original request.
