Videoamp grew from 100 to 500 employees, and Tuesday became the day IT got buried in access requests. New hires had started Monday, managers were missing approvals, and every ticket needed someone to figure out the right app owner before anything could move. That's the moment building self-service IT stops being a nice internal project and becomes the only way the team keeps up without buying more headcount. Because if employees can't request the right access from the place they already work, IT becomes the help desk version of airport security, checking every bag by hand while the line gets longer.
A lot of teams confuse self-service with intake. They build a nice form, point employees to it, and still have IT manually checking approvers, adding users to groups, chasing license cleanup, and rebuilding evidence for audits. So the employee experience looks better, but the operating model is still broken.
Key Takeaways:
- Self-service IT only works when intake, approval, provisioning, and evidence live in the same workflow.
- The biggest waste usually isn't ticket volume. It's the manual work after the ticket gets created.
- A self-service app catalog needs role mappings, approver logic, and identity provider group actions behind it.
- Inactive licenses should be reclaimed from real login data, not quarterly spreadsheet cleanups.
- Jira is already where access work starts for many teams, so governance should live there too.
Why Self-Service IT Breaks When Governance Lives Elsewhere
Self-service IT breaks when the request is easy but the governance work still happens somewhere else. Employees submit through Jira, approvals happen in Slack, provisioning happens in Okta or Entra, and audit evidence gets rebuilt later. That split creates delay, waste, and standing access that nobody meant to keep.
The form is not the workflow
A self-service form feels like progress because the front door gets cleaner. And to be fair, that matters. Employees hate guessing whether they should send a Slack message, file a ticket, email IT, or ask their manager to ask someone else. A clean request path reduces noise fast, especially when you're onboarding 20 or 30 people a month.
But the form doesn't solve the real problem. After the request lands, someone still needs to know who approves Figma Admin, which identity provider group maps to that role, whether the access should expire, and whether the license is already being used. If those answers live in people's heads, you're not really building a self-service IT motion. You're building a prettier queue.
At one advertising company that grew from 100 to 500 employees, Tuesdays became the ugly day. New hires started Monday, then the access queue filled up the next morning with requests that didn't have enough detail. Not malicious. Just incomplete. IT became the interpreter, the approver chaser, and the provisioning engine all at once. If Jira is already the system people trust for work, Multiplier turns that front door into an actual access workflow.
Separate governance portals create a second operating system
Separate IGA portals make sense on paper. Strong controls, dedicated workflows, big governance language — I get why security teams buy them. The downside is that employees don't live there, managers forget to check them, and IT still ends up reconciling the portal with Jira tickets after the fact.
Access work is like an assembly line where every station uses a different clipboard. The request starts on one clipboard, approval gets written on another, the actual group change happens somewhere else, and the audit record becomes a photo of all the clipboards taped together. It works at low volume. Then volume goes up and everything breaks down.
The hidden cost is context switching. A Jira ticket says "Need access to Salesforce." The approver asks in Slack what role they need. IT checks a spreadsheet for group names, someone logs into the identity provider, and later, audit wants proof. Now you're stitching together comments, screenshots, and timestamps like a detective. Nobody wanted that job, but someone owns it anyway.
License waste is usually an access workflow problem
SaaS waste rarely starts with procurement. It starts with access that doesn't get removed. Someone needs a tool for a project, gets access, stops using it after 30 days, and the license keeps renewing because nobody has a clean trigger to reclaim it. Multiply that across 40 apps and 500 employees and the numbers get uncomfortable fast.
The mistake is treating license cleanup as a finance exercise. Finance can ask for the report. Procurement can push vendors. But IT owns the operational truth: who has access, when they last used it, what group grants it, and whether removing it breaks something. Without that, license reclamation is a quarterly spreadsheet ritual — annoying, slow, and usually incomplete.
That's why self-service IT can't stop at requests. The same workflow that grants access should also know when access is stale, when it should expire, and how to remove it without a human remembering to come back later. Otherwise, the queue gets cleaner while the waste keeps compounding.
How to Build Self-Service IT That Still Controls Access
Building a self-service IT model means designing the full access path, not just the request screen. The path should capture the app, role, approver, group mapping, duration, and evidence before IT touches the ticket. When that system is clear, automation becomes safe instead of risky.
Start with the requests that repeat every week
50 repeated access requests per month is usually enough volume to justify a self-service catalog. Not because 50 is magic — once the same requests show up every week, IT stops making decisions and starts doing clerical work. That's the work you should remove first.
A good diagnostic is simple. Pull the last 90 days of Jira access tickets and group them by app and role. If the same app-role combination appears 10+ times, it belongs in the catalog. If the request requires the same approver every time, the approver should be encoded. If IT always adds the same identity provider group after approval, that group should be mapped.
The first pass should be boring on purpose:
- Pick the top 10 to 20 sanctioned apps by request volume.
- Define the 2 to 4 roles people actually request.
- Map each role to the right identity provider group.
- Assign one owner or manager approval path.
- Decide whether access is permanent or time-bound.
That last point matters more than people think. If access is for a project, incident, sensitive dataset, or admin task, don't make it permanent by default. A 24-hour grant is easier to defend than a standing permission no one reviews for 6 months.
Make role mapping the control point
Role mapping is where self-service IT either becomes governed or turns into chaos. The employee shouldn't need to know the identity provider group name. They should ask for "Figma Editor" or "Salesforce Viewer." Behind the scenes, that role needs to map to the exact group that grants the right entitlement.
This is where a lot of teams get stuck. They have groups named after old departments, old tools, old admins, and old mistakes. Identity providers become museums if no one cleans them up. The trick is not to fix the entire museum before building self-service — start with the roles that drive volume and risk.
Use a plain rule: if IT can't explain what a group grants in one sentence, don't map it yet. Clean it first. For each catalog role, write down three things: what the user gets, which group grants it, and who owns the decision. If any one of those is missing, the role isn't ready for self-service.
A simple mapping table works well early:
[Table: Catalog role] — See "Table Embed Codes" in Oleno to copy the HTML for this table.
Once role mapping, approvers, and expiry rules are defined, the process stops being a help desk preference. See how Multiplier works to get a look at the mechanics behind a Jira-native flow like this.
Keep approvals inside the tools people already check
Approvals fail when they require a new habit. Managers live in Slack, Jira, email, meetings, and a bunch of random tabs. Asking them to remember another portal for access approvals sounds reasonable in a vendor demo. In practice, notifications get missed and employees start side-channeling requests.
There is a case for separate approval portals in very large enterprises with specialized governance teams. If you have a dedicated IGA function, complex segregation of duties, and thousands of apps, the workflow might need that depth. For mid-market and high-growth teams already running on Jira Service Management, adding a second place to approve routine access usually creates more drag than control.
Approval routing should answer three questions automatically: who should decide, where should they decide, and what happens after they decide. If the approver is the manager, pull that from the identity provider. If it's the app owner, define it on the app. If it's a sensitive role, route it through a stricter path. Don't make IT read the ticket and guess.
The practical rule: if an approval sits for more than 24 business hours, check the channel before blaming the approver. A Slack DM with approve/deny buttons tied to the Jira issue will usually beat a portal notification no one checks.
Use time-bound access before access reviews
Quarterly access reviews are important, but they're a weak cleanup tool if every grant is permanent. By the time reviewers see the campaign, the access may have been wrong for 60 or 90 days. And reviewers rubber-stamp when the list is too long, because they don't have enough context to make 400 decisions carefully.
Time-bound access changes the shape of the problem. Instead of granting admin rights and hoping someone removes them later, you make the grant expire after 1, 6, or 24 hours. The user gets what they need. The window closes automatically. The audit record shows the request, approval, grant, and revocation. Much cleaner.
The decision rule is straightforward:
- Use 1 to 24 hour access for admin roles, production systems, and sensitive data.
- Use project-based expiry for temporary contractors or short-term project tools.
- Use permanent access only when the role is tied to someone's core job.
- Review permanent access on a campaign schedule.
Some teams worry time-bound access will slow people down. Valid concern. If someone is fixing an incident, you don't want governance theatre in the way. But fast temporary access is usually better than broad standing access. The user gets in quickly, and security isn't stuck cleaning up old permissions later.
Reclaim licenses from login activity, not memory
License reclamation based on memory is a losing game. Managers don't always know what tools their team uses. Employees forget what they requested 8 months ago. IT can export lists, but a list of assigned licenses doesn't tell you whether those licenses are actually being used.
Login activity gives you a better signal. If someone hasn't logged into an app for 30, 60, or 90 days, that doesn't automatically mean you should remove them. It means the system should trigger a check: send a warning, give a grace period, exclude groups that shouldn't be touched, and revoke access if nothing changes.
A useful policy pattern:
- 30 days inactive: send a warning for high-cost, low-risk apps.
- 60 days inactive: reclaim standard licenses unless the user is excluded.
- 90 days inactive: flag for access review if the app is sensitive.
- Never auto-reclaim: executive, legal hold, or operationally sensitive groups without a manual exception path.
The overlooked part is evidence. If access gets removed, you need a record showing why it happened, when the user was warned, and what group membership changed. Otherwise, finance gets a savings story but audit gets another mess.
Treat audit evidence as a byproduct
Audit readiness gets painful when evidence is created after the work: screenshots, exports, spreadsheet notes, copied Slack messages. Someone spends days proving that work happened because the system didn't capture the proof while the work was happening.
A better self-service IT design makes the Jira issue the evidence container. The request is there, the approval is there, and the provisioning action is there. The revocation, denial, or access review decision is there too. Now the audit trail isn't a separate project — it's the exhaust from the workflow.
Before approving any self-service access workflow, check these five things:
- Does every request create or update a Jira issue?
- Does the approval decision live on that issue?
- Does the identity provider change write back to the issue?
- Does time-bound revocation write back too?
- Can an auditor understand the story without asking IT for screenshots?
If the answer to any of these is no, the workflow isn't audit-ready. It might still be useful and save time, but don't pretend it solves governance yet. Governance only works when the control and the proof live together.
How Multiplier Makes Access Governance Jira Native
Multiplier makes self-service IT work by keeping requests, approvals, provisioning, license cleanup, and evidence inside Jira Service Management. It uses the identity provider as the place where access changes actually happen, so Jira stays the operating record while Okta, Entra, or Google Workspace stays authoritative.
The catalog becomes the front door
The Application Catalog gives employees a Jira-native place to request sanctioned apps and roles. They see approved applications, choose the role they need, and submit through JSM or Slack. Behind the scenes, each role can be mapped to identity provider groups, so the request isn't a vague ticket — it's structured from the start.
That matters because the old access workflow wastes time after approval. IT reads the ticket, finds the group, makes the change, comments back, and hopes the evidence is enough later. With automated provisioning via identity provider groups, the approved Jira workflow can add or remove the user from the mapped group and write the outcome back to the ticket. The ticket stops being a reminder and becomes the control record.
The same model supports approval workflows in Jira and Slack. App owners, managers, or specific users can approve without a separate governance portal. For lower-risk access, you can make the path fast. For higher-risk roles, you can require the right decision before provisioning. The point isn't to remove judgment — it's to stop making IT carry every step manually.
License cleanup and expiry stop being side projects
Auto Reclaim handles the license waste problem from real login telemetry, not gut feel. Admins define inactivity thresholds, grace periods, and group exclusions. If a user crosses the threshold, they get warned. If they stay inactive after the grace period, access gets revoked and a Jira ticket documents the removal.
Time-Based Access handles the other half. If someone needs elevated access for 1, 6, or 24 hours, the access expires automatically after the approved window. That reduces standing privilege and cuts the cleanup work that usually gets forgotten. Important caveat: automatic revocation depends on access being managed through identity provider group membership. If an app is manual or not connected through that model, you still need a manual path.
Access Reviews become cleaner because the day-to-day hygiene is already better. Reviewers see user attributes, groups, last login, and recommendations in Jira, then decide keep or revoke. Revocations remove users from the relevant identity provider groups and create evidence in Jira. If the biggest waste is inactive licenses and old group membership, get started with Multiplier rather than running another spreadsheet cleanup.
Start With the Requests That Waste the Most Time
Building a self-service IT motion doesn't mean replacing your whole identity stack. It means taking the access work that already lives in Jira and making it complete: request, approval, provisioning, expiry, cleanup, and evidence. Start with the apps that create the most repeated tickets, then add automation where the rules are clear.
The mistake is trying to boil the ocean. Pick 10 to 20 apps, map the roles, define the approvers, use identity provider groups as the control point, then tackle stale licenses and time-bound access. Once that works, the model expands naturally.
Self-service IT isn't a portal. It's an operating system for access.
Frequently Asked Questions
How do I set up time-bound access in Multiplier?
To set up time-bound access in Multiplier, follow these steps: 1) When creating an access request in the Application Catalog, select the duration for the access (1, 6, or 24 hours). 2) After approval, Multiplier will automatically provision the access and set a timer to revoke it once the time expires. 3) Ensure that the app is configured to allow time-based access. This helps enforce least privilege and reduces the risk of standing access.
What if I need to reclaim licenses for inactive users?
To reclaim licenses for inactive users, you can use Multiplier's Auto Reclaim feature. Here's how: 1) Set inactivity thresholds (e.g., 30 days) and grace periods for your applications in Multiplier. 2) When a user exceeds the inactivity threshold, they will receive a warning email. 3) If they remain inactive after the grace period, Multiplier will automatically revoke their access and create a Jira ticket documenting the change. This process helps optimize your SaaS spend efficiently.
Can I customize approval workflows in Multiplier?
Yes, you can customize approval workflows in Multiplier. To do this: 1) Go to your Multiplier settings within Jira Service Management and map workflow statuses to 'Waiting for Approval' and 'Approved'. 2) Designate default approvers globally or override them on a per-app basis. 3) Ensure that approvers receive notifications via email or Slack for quick decision-making. This keeps the approval process streamlined and tied to the originating ticket.
When should I conduct access reviews with Multiplier?
You should conduct access reviews regularly, ideally on a quarterly basis. To set this up in Multiplier: 1) Create an access review campaign by selecting the applications in scope (only those marked as 'Approved'). 2) Assign reviewers for each application and launch the campaign. 3) Reviewers will receive notifications and can mark users as 'Keep' or 'Revoke' based on their access activity. This helps maintain a clean access environment and ensures compliance.
Why does my self-service IT catalog need role mapping?
Role mapping is crucial for a self-service IT catalog because it ensures that access requests are accurately linked to the right permissions. To implement this: 1) Identify the roles that employees typically request and map them to the corresponding identity provider groups. 2) This mapping allows Multiplier to automate provisioning accurately, reducing manual errors and ensuring that users receive the correct access. Without proper role mapping, the self-service model can become chaotic and ineffective.
