Build a Self-Service App Catalog That Actually Works

Creating a self-service app catalog sounds like an IT project, but it’s really an operating model problem. If you skip that part, you don’t get fewer tickets. You get prettier tickets with the same broken approvals, stale licenses, and audit mess underneath.

Most teams start with the portal. Fair enough. It feels like the obvious place to start because everyone can see it, click around, and say, “Great, now employees can request apps.” But the portal is only the front door. The real work is what happens after someone asks for access.

And if you’re running Jira Service Management already, the bigger question is pretty simple: why send people to another system when the work already starts in Jira? If you want to see what that can look like in practice, Learn more about Multiplier.

Key Takeaways:

• Creating a self-service app catalog fails when teams focus on the portal instead of the access workflow behind it.
• The first job is to map your messy access requests, not design app tiles.
• Roles matter more than app names because vague access levels create approval loops.
• Slack approvals can speed things up, but only if Jira remains the system of record.
• Temporary access should be the default for risky apps, admin roles, and production systems.
• License reclamation needs login data, not quarterly spreadsheet cleanup.
• A good self-service app model should cut tickets, reduce standing privilege, and produce audit evidence as work happens.

Why Creating a Self-Service App Catalog Usually Fails

Creating a self-service app catalog usually fails because teams treat it like a request portal, not a governed access system. The visible part is the catalog, but the hidden part is approval routing, provisioning, expiry, license cleanup, and evidence. Miss that layer and you’ve just moved chaos into a nicer interface.

The Portal Is Not the Workflow

A Workplace Technology manager opens Jira at 9:12 AM on Tuesday and sees 38 access tickets from Monday’s onboarding batch. Half say “Need Figma” or “Need Salesforce” with no role, no manager approval, and no clue whether the license should be permanent. By 11 AM, someone has already Slacked three app owners, checked Okta groups manually, and left two tickets in limbo because the requester picked the wrong thing. That’s the trap. The team thinks the problem is intake, but the problem is the workflow after intake.

I’ve seen this same pattern in content, sales, onboarding, all of it. You create a nice front-end experience, and everyone claps for a week. Then the same ugly work shows up behind the curtain. Creating a self-service app only works if the request carries enough context to make the next step obvious. App name, role, duration, business reason, approver, group mapping. Without those pieces, IT is still playing detective.

A decent test is simple. Pull your last 50 access requests and ask how many could be completed without a follow-up question. If fewer than 70% could be approved or denied from the original ticket, your catalog isn’t ready. You don’t have an app catalog problem yet. You have an access request quality problem.

Chat Alone Makes the Mess Faster

Slack is great for speed. I’m not anti-chat. People live there, so approvals should show up there. But a chat bot by itself doesn’t give you governance, time-bound access, or audit evidence that survives the quarter. It just makes the conversation faster, which can be good or bad depending on what gets recorded.

NIST’s access control guidance is pretty clear that account management needs authorization, review, and removal practices tied to the identity lifecycle, not just quick approvals in a message thread. The NIST SP 800-53 account management controls are dry reading, sure. But the point matters. If approval happens in chat, provisioning happens in the identity provider, and evidence gets rebuilt in a spreadsheet later, you’ve created three versions of the same truth.

Videoamp had a very normal version of this problem. They grew from 100 to 500 employees, and Tuesdays became the access request day from hell after Monday onboarding. They eventually put 20 sanctioned apps into a JSM app store and processed 500+ app requests in 6 months, saving 70+ hours of IT productivity. Not because the tiles looked nice. Because the catalog forced better intake and cleaner routing.

SaaS Waste Hides Inside Standing Access

SaaS waste often hides in users who still have access because nobody owns cleanup. The license looks assigned, the account still exists, and the renewal spreadsheet says you need the same number of seats again. Nobody notices the person hasn’t logged in for 45 or 90 days until finance starts asking hard questions.

This is where creating a self-service app catalog connects to budget, not just IT service delivery. Every app request is also a future reclaim decision. If you don’t know who requested access, who approved it, what role they got, and whether they still use it, you can’t cut waste cleanly. You either over-revoke and annoy people, or you under-revoke and keep paying.

The better model is closer to warehouse inventory than ticket routing. If a part comes in, you tag it, assign it, track usage, and know when it returns to the shelf. Access should work the same way. Otherwise every license becomes a drawer full of spare cables. You know there’s waste in there, but nobody wants to sort it.

How to Build a Self-Service App Catalog That Actually Gets Used

A self-service app catalog gets used when employees can request access quickly and IT can trust what happens next. The catalog should collect the right data, route the right approval, trigger the right provisioning path, and create a record by default. Adoption follows clarity, not portal design.

Audit the Request Mess Before You Build Anything

Start with the mess you already have. Pull 30 days of access requests from Jira, Slack, email, and wherever else people are asking for apps. Don’t sanitize it. The ugly version is the useful version, because it shows how people actually behave when they need access and don’t know the “right” process.

The diagnostic I like is painfully simple. For each request, mark whether it included the app, role, duration, approver, business reason, and provisioning path. Then mark whether IT had to ask a follow-up question. If more than 3 out of 10 requests need clarification, don’t start by creating a self-service app catalog with 100 apps. Start with your top 10 repeat offenders and fix the intake rules there first.

A good audit usually shows three buckets:

• Ready for self-service: Low-risk apps with clear roles and obvious approvers.
• Needs guardrails first: Apps with vague roles, messy ownership, or sensitive data.
• Keep manual for now: One-off tools, non-SSO apps, or access that needs human judgment.

That last bucket matters. Some teams pretend everything can be automated right away, and that’s just not true. If an app has no clean group mapping, no clear owner, and no reliable login data, forcing it into the first version of the catalog creates more cleanup later. Better to start smaller and make the first 10 apps actually work.

Define Roles Before You Define the Catalog

A catalog full of app names isn’t enough. “Request Salesforce” is not a complete access request. Does the person need viewer access, sales rep access, admin access, integration access, or temporary access to troubleshoot a customer issue? Those are very different decisions, with very different risk.

The role model is where most teams go wrong. They sync apps, build tiles, and only later realize every app has 6 weird permission levels that nobody has named properly. Then approvers get vague requests, IT gets stuck translating roles into identity provider groups, and employees keep asking for “whatever my teammate has.” Not great.

Before creating a self-service app for a major tool, define the approved roles in plain English:

1. Name the role so employees understand it.
2. Map the role to an identity provider group.
3. Assign the approver who owns the access decision.
4. Decide if the role expires or stays standing.
5. Record the business reason required for higher-risk roles.

I’d argue this is the real catalog work. The tile is just packaging. The role-to-group mapping is what makes the system reliable. Atlassian has been writing more about teams using Jira Service Management across the employee lifecycle, including onboarding and workplace operations, and the pattern shows up there too: the more work you can standardize in the request, the less cleanup you need after the ticket is filed. Their write-up on employee lifecycle management in Jira Service Management is worth reading if you’re thinking beyond app access.

Route Approvals Where People Already Answer

Approvals die when they’re sent to places people don’t check. Email approval chains sound fine in a policy document, but in real life the app owner is in meetings, the manager missed the notification, and the employee is asking IT why nothing moved. So the instinct is to push approvals into Slack. Good instinct. Incomplete answer.

Slack should be the action layer, not the system of record. The approval can happen in chat, but the request, decision, provisioning result, and audit trail need to stay tied to the Jira issue. Otherwise you get fast decisions with weak evidence, which feels fine until audit season or an access review.

Use a simple routing rule. If the app is low risk and the role is basic, route to the manager or auto-approve if your policy allows it. If the app contains sensitive customer data, financial data, production access, or admin rights, route to the app owner or security approver. If the role is temporary and tied to an incident, approve quickly but force expiry.

The threshold I’d use is this: any access that can expose customer data, change production systems, or export financial records should never rely on manager approval alone. Managers know job context. App owners know system risk. Security knows policy. Sometimes you need all three, but not for every request. Over-approving low-risk access creates backlog, and under-approving high-risk access creates exposure. Both cost you.

A mid-sized fintech team like Luno had the classic version of this. Hundreds of routine requests came through Slack, email, and Jira. IT had to chase managers and manually assign Okta groups. After moving the request and approval flow into Jira and Slack with automated provisioning, they cut IT workload on access requests by 80%. That’s the shape you’re aiming for: faster decisions, less chasing, cleaner records. If your current flow has people copying approvals from Slack into Jira comments, See how Multiplier works.

Make Temporary Access the Default for Risky Apps

Permanent access is easy to grant and hard to clean up. That’s why it spreads. Someone needs admin access for a migration, gets it for a week, finishes the job, and keeps the role for 14 months because nobody owns the removal step. Multiply that across engineering tools, finance systems, data warehouses, and customer platforms. Now you’ve got standing privilege everywhere.

The better default is time-bound access for risky roles. Not every app needs it. Nobody wants employees re-requesting basic Zoom access every day. But admin roles, production systems, sensitive data tools, and elevated permissions should have a timer. One hour, six hours, 24 hours, maybe seven days for project work. Pick durations based on the job, not vibes.

A useful rule:

1. Basic employee apps can be standing if usage is monitored.
2. Paid apps should be reviewed against login activity every 30 to 90 days.
3. Admin roles should expire by default.
4. Production or sensitive data access should require a reason, approver, and expiry.
5. Break-glass access should be short, logged, and reviewed after use.

Security teams sometimes push this too far. I get why. Least privilege sounds clean in theory. In practice, if you make every request painful, people route around the process and ask a friendly admin in Slack. The trick is to make temporary access faster than the workaround. When the governed path is the fastest path, people actually use it.

Measure Reclamation, Not Just Request Speed

Request speed is the easy metric. Everyone likes saying access got faster. But if creating a self-service app catalog only reduces time-to-grant and doesn’t reduce stale access, unused licenses, or audit work, you’ve solved half the problem. Maybe less.

License reclamation is where the CFO starts caring. You need to know which users haven’t logged into which apps, how long they’ve been inactive, whether they should be excluded, and what happens before access gets removed. A 30-day inactivity threshold might work for a daily collaboration tool. A 90-day threshold might be better for a quarterly finance tool. Same idea, different policy.

Track these metrics from day one:

• Request completion rate: Percent of requests completed without follow-up.
• Approval cycle time: Median time from request to decision.
• Provisioning time: Median time from approval to access granted.
• Expired access removed: Percent of time-bound grants revoked on schedule.
• Inactive licenses reclaimed: Seats removed after login inactivity and grace period.
• Audit evidence completeness: Percent of access changes with requester, approver, action, and timestamp.

Synthesia is a good example of why these metrics matter. They grew 4x and had IT requests running through Slack channels and Notion boards. After moving access into a catalog and automated approval model, they processed 3,800+ access requests in a year, with 75% fully automated, while a 4-person IT Ops team supported 420+ employees. Speed mattered. But the real win was repeatability.

How Multiplier Runs Access Governance in Jira

Multiplier runs access governance inside Jira Service Management by connecting catalog intake, approvals, provisioning, time-based access, reviews, and license reclamation to the same Jira record. Employees request access in JSM or Slack, while IT keeps approvals, identity provider changes, and evidence in one governed workflow.

JSM Catalog and Slack Approvals Keep Intake Clean

Multiplier starts with a Jira-native Application Catalog, which is basically the part employees see when they need access. Apps appear as sanctioned tiles, roles can be selected, and submissions create Jira issues instead of disappearing into Slack threads or email. Behind the scenes, Multiplier syncs apps and groups from Okta, Entra ID, and Google Workspace, then maps catalog roles to identity provider groups.

Approval workflows can route decisions to managers, app owners, or specific users, with notifications in JSM and Slack. That matters because employees and approvers don’t need another portal just to answer a basic access question. Multiplier keeps Slack as the place people act, and Jira as the record that proves what happened. Clean split. Easy to understand.

The practical change is pretty big:

• Employees request sanctioned apps from JSM or Slack.
• Approvers act in Jira or Slack without losing the Jira record.
• Approved requests can provision through identity provider groups.
• The Jira ticket captures the request, decision, and change history.
• Custom non-SSO apps can still be tracked, even when provisioning stays manual.

Worth being precise here. Multiplier provisions through identity provider group membership. It doesn’t directly provision inside every individual SaaS app outside that model. That’s a real boundary, and honestly, it’s the right one to know before you design your catalog. If the app and role can map cleanly to an identity provider group, the workflow can become much more deterministic.

Auto Reclaim and Time-Based Access Close the Loop

Multiplier also addresses the part most catalogs ignore: what happens after access is granted. Time-Based Access lets requesters choose durations like 1, 6, or 24 hours where configured, then removes the user from the mapped identity provider group when the window expires. For admin roles and sensitive systems, that’s the difference between “we believe in least privilege” and “least privilege actually happened.”

Auto Reclaim handles the license waste side. Multiplier ingests last-login data from connected identity providers for in-scope apps, applies inactivity thresholds and grace periods, sends warning emails, and revokes access if the user stays inactive. It also generates a Jira ticket documenting the removal. Auto Reclaim is only available on the Advanced edition, and its effectiveness depends on accurate last-login data from the identity provider. Again, useful boundary.

Access Reviews add the quarterly governance layer. Reviewers work from JSM dashboards with user attributes, groups, last login dates, and recommendations like revoke if inactive 90+ days. Keep or revoke decisions can remove users from relevant identity provider groups and create Jira evidence. So the model isn’t just faster intake. It’s request, approval, provisioning, expiry, review, and reclamation sitting in the same operating system.

What used to be a pile of Slack messages, Okta clicks, stale seats, and spreadsheet evidence becomes a governed access loop inside Jira. If you’re ready to build that loop instead of another disconnected portal, Get started with Multiplier.

Start With the Messiest Access Requests First

The best self-service app catalog doesn’t start with every app. It starts with the access requests that waste the most time, create the most risk, or burn the most license spend. Pick 10 apps, define the roles, map the approvals, set expiry rules, and measure whether follow-up questions disappear.

Creating a self-service app catalog is not a design exercise. It’s an operating decision. You’re deciding where access work lives, how approvals happen, how provisioning gets executed, when access ends, and what evidence exists when someone asks for proof six months later.

Start smaller than your ambition. That’s usually the move. If the first 10 apps cut request noise, reclaim unused seats, and reduce standing access, you’ll have the internal proof to expand the catalog without turning it into another messy portal nobody trusts.