Steps to Configure Custom License Reclamation Policies

Most IT teams don’t need another portal. They need access governance that lives where requests, approvals, and changes already happen. If you’re running Jira Service Management with Okta, Entra, or Google, you can design real least privilege without slowing anyone down. We’ll cover the exact steps to wire up approvals, expiries, and reviews. In plain English.

You probably came here looking for concrete steps to configure custom access workflows in JSM that actually stick. Good. The secret isn’t a monster policy doc or a six‑month IGA rollout. It’s putting the rules, the context, and the automation inside Jira and Slack, then driving changes through your identity provider so the audit trail writes itself.

Key Takeaways:

• Put governance inside Jira and Slack so requests, approvals, and changes live in one record
• Provision through your identity provider groups to keep changes fast, auditable, and reversible
• Make elevated access temporary by default with time-based windows that auto-expire
• Run access reviews in Jira to close the loop and generate clean evidence on demand
• Standardize intake with a self-service app catalog so every request has the right context
• Use numbered policies and templates so approvers don’t guess at risk
• Start with one high-volume workflow, then expand once you’ve proven the pattern

Why Custom Access Workflows Break at Scale in Jira

Custom access workflows break at scale because the work is split across tools, so no single system owns context, timing, and evidence. Intake sits in Jira, approvals float in email or Slack, provisioning happens in the IDP, and audits get rebuilt in spreadsheets. The gaps invite delays, standing access, and weak reviews. When teams grow, these seams tear.

What looks like a tooling problem is really a placement problem. You’ve got the right pieces, they’re just in the wrong place. Jira Service Management is already your intake and SLA backbone. Your identity provider is already authoritative for adding and removing people from groups. When you glue those together correctly, speed and control stop fighting each other.

I’ve watched teams try to fix this with strict policies alone. It doesn’t hold. People bypass portals, approvals stall, and someone pastes screenshots into a ticket at month end to keep the auditor happy. Feels exhausting, right? It is. That fatigue is the cost of fragmented governance.

The Real Bottleneck: Split Workflows, Split Evidence

The bottleneck isn’t approvers who are “slow.” It’s that decisions and changes live in different systems with no shared thread. A product manager approves in email. IT adds a user to an Okta group. A screenshot lands in a folder named “Audit.” None of this is authoritative. All of it is fragile.

The fix is to keep the entire thread in Jira. Approvals move the ticket. The next status triggers a change in the IDP group. The result writes back to the issue. Now your record of decision links to the exact change. SLAs make sense again. So do audits. You can configure approvals natively in JSM so approvers click once and you have a durable log of who said yes, when, and to what kind of access. If you’ve never set up approvals in JSM, the official guide is solid and quick to follow, see Jira Service Management approvals.

The Hidden Cost: Standing Privileges And License Waste

When provisioning happens by hand, expiry rarely happens at all. That’s the quiet failure. Admin roles linger for months. Extra seats stay billed. The team pays twice, once in risk and once in cash. Most of this is avoidable if the rule is “elevated access expires unless renewed.” You’re not adding friction, you’re removing drag.

Tie access to a timer at request time and revoke it automatically. Your IDP already supports membership changes by API. Okta does, Microsoft Entra does, Google does. For example, Okta exposes group membership endpoints you can call safely and repeatably, see Okta group membership APIs.

Why People Resist: Context Switching Feels Like Work

The last human piece is simple. People don’t want to learn a new portal. They’ll DM someone in Slack before they’ll find a new login. So meet them in Slack, keep Jira as system of record, and let the identity provider do the heavy lifting behind the scenes. That small change lowers resistance, which is why adoption finally sticks.

How to Configure Custom Access Governance in Jira Without Another Portal

You configure custom access governance in Jira by standardizing intake, encoding approvals in JSM, provisioning through identity provider groups, enforcing time-bound access, and running access reviews as Jira issues. Start small with one workflow, then expand. The aim is speed without losing control, least privilege without manual cleanup.

The path below is what I’ve seen work again and again. It isn’t fancy. It’s repeatable.

Design Your App Catalog So Intake Is Deterministic

Your catalog is the front door. If it’s messy, your workflow will be messy. Build a clean, visual catalog in your JSM portal that lists sanctioned apps as tiles, mapped to clear roles like Viewer, Editor, Admin. Each role must correspond to a group in your IDP. That way a request for “Editor” becomes a specific group change later, not a free‑text puzzle.

Two paragraphs in, one hard truth: if the catalog doesn’t reflect your actual identity groups, you’ll drift. So sync your app list with the IDP and add non‑SSO apps only when you still want the approvals and the audit trail. The point is to capture complete context at intake, every time, without a back‑and‑forth. Keep the form light, but complete enough that the approver has what they need to say yes or no.

To structure the catalog for scale:

1. Start with your top 15 apps by request volume
2. Define 2–3 roles per app that match real groups
3. Add brief role descriptions so approvers don’t guess
4. Hide anything not approved for self-service This is particularly relevant for steps to configure custom.

Pro tip: pick a simple group naming convention (app_role_scope), e.g., jira_editor_prod. Consistency kills confusion later.

Encode Approvals In JSM So “Yes” Means Something

If approvals live in email, you’ll lose them. Put them in JSM. Map statuses like “Waiting for Approval” and “Approved” to your request type, then set default approvers by app or by requester’s manager for higher‑risk roles. The more you move decisions into Jira clicks, the tighter your evidence and the faster your cycle time.

Approvals also need context. Include the requester’s job title and department, the role they asked for, and the intended duration if you plan to enforce time‑bound access. Create a short, numbered policy that tells approvers when to auto‑approve and when to escalate. Clarity beats second‑guessing.

Set your approval rules like this:

1. Manager approval for elevated roles
2. App owner approval for sensitive systems
3. Auto‑approve low‑risk viewer roles during business hours
4. Require intended duration for anything above viewer

How to wire it fast:

• JSM: Project settings > Request types > add Approvals and fields (Role, Duration, Justification)
• JSM: Workflows > add statuses and a transition “Approved” that only fires after required approvals
• Automation: On transition to Approved, add comment “Approved by at for ”

Provision Through Your Identity Provider Groups

Never provision inside apps if you can avoid it. Keep membership changes in the identity provider so they’re authoritative, fast, and reversible. This is where most teams win back hours. When a ticket hits “Approved,” add the user to the mapped group and log the result to the issue. If you need licenses, use group‑based assignment in your IDP so a single group change handles both license and entitlement. Microsoft calls this group‑based licensing and it’s built for exactly this.

This pattern removes guesswork. No more “which group was it again?” You’ve decided that at catalog design time. At runtime, you’re just executing the rule you already wrote. If something goes wrong, you have a comment on the Jira issue with the error, not a mystery in an admin console.

To keep this clean:

• Map each catalog role to a single authoritative group
• Use separate groups for time‑bound access where needed
• Write success and failure notes back to the ticket automatically

Quick wiring tip (Jira Cloud): use Automation’s “Send web request” to call your provisioning service or integration that updates the IDP group, then post the response back to the issue.

Enforce Time-Based Access So Least Privilege Isn’t A Slogan

Least privilege fails when access never ends. Make expiry the default for elevated roles. Ask for intended duration at request time, approve based on that window, then remove the user from the group when the timer ends. During incidents or critical work, allow quick extensions without ping‑ponging approvers, but still write the extension to the same issue.

This one change reduces risk and cuts license waste. It also teaches the org a healthy habit. People ask for what they need, when they need it, and it goes away when they’re done. Not before. Not never. The principle is old, but the practice is what matters, see the NIST least privilege guidance if you want the formal framing.

Set time windows by risk:

1. Viewer roles, no expiry unless sensitive data
2. Editor roles, 24 hours by default with quick renew
3. Admin roles, 1–6 hours by default with manager approval
4. Production systems, the minimum practical window This is particularly relevant for steps to configure custom.

Implementation notes:

• Store start/end timestamps on the Jira issue
• Use a scheduled job or app to poll for expiries and remove users from groups
• Always annotate the issue when access is revoked (who/when/what group)

Run Access Reviews As Jira Campaigns, Not Spreadsheets

Quarterly certifications collapse when they depend on CSVs and side channels. Run them as campaigns in Jira instead. Scope apps, assign reviewers, and show the data reviewers need to make a call: job title, department, group membership, last login, a simple recommendation like Keep or Revoke. When someone clicks Revoke, remove the user from the group and log the change to an issue automatically. Evidence is now a byproduct of how you work, not an extra project.

Reviews should feel lighter, not heavier. Keep your reviewer experience in the JSM portal so no one needs a new login. Track completion in one dashboard. If an app has no users, upload them once and fix the upstream sync later.

One trick that pays off: tag revocations with a short reason code so you can analyze patterns next quarter. You’ll find stale teams or roles faster and fix them at the source.

Ready to put this model in motion without another portal? Learn more about Multiplier

From Manual Tickets to Automated Provisioning: Configure Custom Governance With Multiplier for Steps to configure custom

Multiplier makes this approach practical by putting the app catalog, approvals, provisioning, and time‑bound access inside Jira and Slack, while executing changes through your identity provider. The record of decision is your Jira issue. The change is a group update in Okta, Entra, or Google. The audit trail writes itself. That’s the loop.

The best part is you don’t need to rewire your org. You keep Jira as the front door, Slack as the notification layer, and the IDP as the source of truth for access. Multiplier connects them cleanly.

Catalog, Approvals, Slack: Standardize Intake And Decisions

Multiplier’s Application Catalog replaces ad hoc asks with a single, Jira‑native storefront. Employees browse approved apps as tiles, choose the role, and submit, either in the JSM portal or via Slack. Approvals route to the right person in JSM and Slack, so approvers can approve or deny in chat and you still keep the evidence in Jira. The point is simple. Intake is consistent, and decisions are traceable to the exact request.

Once an access request hits the approved status, Multiplier calls your identity provider to add the user to the mapped group. No copy and paste. No screenshots. If you enable time‑based access for an app, the requester picks a duration at submission. After approval, Multiplier grants access, starts the timer, and removes the user from the group at expiry. That kills long‑lived access without adding manual cleanup.

When you do need to work in chat, the Slack app keeps things moving. Users can type a quick command to open the same catalog they’d see in JSM. Approvers get a direct message with one‑click actions. Every click ties back to the Jira issue that originated it.

Curious how the catalog and Slack approvals look in practice? See how Multiplier works

Provisioning, Reviews, And Reclaim: Close The Loop With Your IDP

Multiplier provisions through identity provider groups. That keeps changes authoritative, fast, and reversible. It writes success or error notes back to the Jira issue for verification. For apps connected through SAML or SCIM, group membership pushes entitlements directly. If you also assign licenses through groups in your IDP, a single change handles both license and access. The outcome is fewer delays and fewer mistakes.

Access reviews run as Jira‑native campaigns in JSM. Admins scope apps, assign reviewers, and launch. Reviewers land in a JSM Help Center dashboard where they can see users, key attributes, last login, and simple Keep or Revoke actions. When a reviewer clicks Revoke, Multiplier removes the user from the relevant group and records the change automatically. That addresses the earlier cost you felt in spreadsheet chaos and rubber‑stamp certifications. Evidence is now exportable and complete.

When you want to control spend, Auto Reclaim identifies inactive users using last login data from your IDP, warns the user, and, if they stay inactive past the grace period, removes access and records it in Jira. The effect is straightforward. You avoid paying for seats no one uses, and you can show exactly why those seats were freed.

Teams moving from manual tickets to this model report faster approvals, fewer standing privileges, and cleaner audits because the whole loop, request to revoke, sits inside Jira with the change executed through the identity provider. If that’s what you want, you can get there fast. Get started with Multiplier

The Path Forward: Configure Custom Governance Where Work Happens

You don’t need a new portal to fix access. You need the work of governance to live inside Jira and Slack, with your identity provider as the engine for change. Standardize intake with a catalog, encode approvals in JSM, provision through groups, enforce expiries, and run reviews as issues. That’s the pattern that holds.

Do it once for a single high‑volume app. Prove the cycle time drops and the evidence is cleaner. Then expand. When you configure custom governance where people already work, speed and control finally align.