On Monday morning, finance asks why people who haven't logged in for 30 days still hold paid SaaS licenses. IT has a spreadsheet, security has a policy, and nobody has an automatic action tied to either one. Automated IT access management is supposed to solve that. Yet a lot of companies automate ticket intake, then leave provisioning, revocation, and license reclamation manual.
More policy won't fix an execution gap. If nobody removes unused access after the policy threshold is crossed, the company keeps paying and the user keeps access. Both problems come from the same place. A decision was made, but nothing operational happened afterward.
Key Takeaways:
- Treat approval as the trigger for an identity change, not the end of a ticket.
- Execute provisioning and revocation through identity provider groups.
- Make temporary access expire automatically instead of relying on follow-up.
- Use real login activity to find and reclaim unused SaaS licenses.
- Keep requests, identity changes, and audit evidence connected in Jira.
- Start with repeatable access paths before automating edge cases.
Why Manual Access Controls Keep SaaS Waste Alive
Manual access controls keep SaaS waste alive because policies identify what should happen without making it happen. The gap appears after an approval, inactivity threshold, or employee change. Unless those events trigger an identity action, licenses remain assigned and access stays open longer than intended.
Policies Don't Remove Old Licenses
A policy might say an unused license should be removed after 30, 60, or 90 days. Fair enough. That gives IT and finance a shared rule. Yet somebody still needs to pull the login data, check the exceptions, notify the user, and remove the entitlement.
That manual sequence is where the process dies. The report gets exported, reviewed once, and dropped into a folder. By the next review, new unused licenses have piled up beside the old ones. In my view, policy-heavy access management often looks much stronger from the outside than it operates day to day.
A least privilege policy without automated expiry is like a Jira workflow with no transition after Approved. The ticket reaches a nice status, then nothing executes.
The ITSM and Identity Split Creates Drift
Access drift begins when the request and the identity change live in different systems. Jira records what someone asked for. Slack or email captures the decision. Okta, Entra ID, or Google Workspace holds the actual group membership, while a spreadsheet tries to connect the pieces later.
Consider a regular Tuesday. An employee asks for a design tool in Jira, their manager approves in Slack, and an IT admin adds them to an identity provider group. Three months later, the employee changes roles, but nobody revisits the original request. Finance keeps paying because the ticket, group membership, and usage data were never tied together.
A fintech company approaching 1,200 employees ran into exactly that pattern. Hundreds of routine requests arrived through Slack, email, and Jira, while IT chased approvals and assigned Okta groups manually. After connecting intake, approval, and provisioning, the company reduced IT workload on access requests by 80%. The big shift wasn't a better request form. It was removing the handoffs after the form.
Manual Enforcement Turns Every Exception Into Debt
Manual access management is reasonable at very low volume. If you have 20 employees, six core applications, and one admin who knows every request, a spreadsheet can work. I get why teams start there. It's cheap, familiar, and flexible.
The model breaks when headcount, app count, or role complexity increases. Every special approval becomes a note someone must remember. Every temporary grant creates a future cleanup task. Every unused license waits for a review that finance hopes will happen before the next renewal.
You can spot the trouble before the SaaS bill jumps. Three red flags tell you the decisions aren't executing: requests that close before provisioning is confirmed, access granted without an expiry date, and quarterly reviews built from fresh CSV exports. If you're seeing two of those three, you're already carrying access debt, you just haven't been billed for it yet. Those aren't separate admin annoyances. They're evidence that access decisions don't execute themselves.
If that split is already creating cleanup work, Learn more about Multiplier and look closely at where approvals, identity changes, and evidence reconnect. The next question is how to build that operating flow without automating bad decisions faster.
How Automated IT Access Management Should Actually Work
Automated IT access management should connect a business event to an identity change and retain evidence of what happened. A request, approval, inactivity threshold, or employee change triggers the action. The identity provider executes it, while the service record captures the decision and outcome.
Diagnose the Work Before Automating It
Automation should begin with repeatable access paths, not the messiest exception in your queue. I'd start by pulling 30 days of tickets and grouping them by application, requested role, approver, and identity action. You're looking for patterns. The first target is usually boring, which is good.
A workflow is ready for automation when the same inputs lead to the same output most of the time. If every request needs a security debate, keep human judgment in the path. If 80 requests end with the same manager approval and group assignment, the work is already structured enough to automate.
Ask four questions for each request type:
- Is the requested role mapped to a known identity provider group?
- Can the correct approver be selected from the app, manager, or request data?
- Does approval always trigger the same add, remove, or account action?
- Can success or failure be written back to the original Jira issue?
Three or four yes answers point to a strong first workflow. One yes answer means the process needs cleanup before automation. That's the whole diagnostic. Score each request type, automate the high scorers, leave the low scorers to humans until you've cleaned up the inputs.
Use the Identity Provider as the Execution Layer
The identity provider should make the access change because it already controls the group memberships behind SSO applications. Jira can handle intake and workflow. Slack can make approvals easier. Neither should become a second directory with its own version of who has what.
Once a role maps to an identity provider group, the workflow gets much simpler. Approval adds the user to the mapped group. Revocation removes them. For connected SSO apps, the downstream entitlement follows the identity provider's existing SAML or SCIM setup.
Keep the first implementation narrow:
- Choose one identity provider.
- Select three to five high-volume applications.
- Map each common role to a specific group.
- Test additions, removals, and failed changes.
- Write every outcome back to its originating ticket.
Group-based provisioning does have a real boundary. Apps without SSO, reliable groups, or usable identity data may still need manual work. Don't hide those cases inside fake automation. Record them in the same workflow, then automate only the part the system can execute safely.
Separate Approval Logic From Provisioning
Approval answers whether access should be granted. Provisioning handles the identity change after that decision. Mixing both into one manual task forces an IT admin to interpret the request, check policy, chase the approver, and execute the change every time.
A cleaner flow keeps the decision visible while making execution predictable. Low-risk access might follow a standard route to the requester's manager. Higher-risk roles might require the application owner or another named approver. Once the required approval lands, the workflow should stop asking humans to repeat the same mechanical steps.
The operating sequence is straightforward:
- The employee selects an approved app and role.
- The request routes to the correct approver.
- Approval triggers the mapped identity provider action.
- The ticket records success or failure.
- The requester receives the status.
What if the identity provider call fails? Keep the ticket open, record the error, and route it for follow-up. Closing the request before execution is confirmed creates false confidence, which is worse than an obvious backlog.
Once you can point to the exact transition that triggers the identity change, See how Multiplier works as one concrete implementation of that Jira-to-identity-provider handoff. Now the workflow has an execution point. The next job is removing access without another ticket chase.
Make Temporary Access Expire Automatically
Temporary access should carry its end time from the moment it's requested. A user asking for production access might choose one hour, six hours, or 24 hours. Approval grants the mapped group membership, starts the timer, and removes that membership when the approved window ends.
The downside is real. Short access windows can frustrate engineers mid-incident, especially when the work runs longer than expected. That's a valid concern, and I won't pretend otherwise. The better response is an extension path tied to the original approval, not permanent access that survives because everyone was busy. Standing access is just a temporary grant nobody remembered to end.
A 160-person fintech company used that model to reduce privileged access by 85%. More than 1,300 access requests were automatically revoked after their approved windows. The meaningful part wasn't the approval speed alone. Expiry became an enforced action rather than a reminder sitting in someone's queue.
For time-bound access, verify three things:
- The entitlement is controlled by identity provider group membership.
- The requested duration is visible before approval.
- Removal is recorded against the same service record as the grant.
Manual access grants can't always be auto-removed. When the system can't enforce expiry, label the request accordingly and create a named owner for cleanup.
Use Login Activity to Reclaim SaaS Licenses
License reclamation should begin with actual login activity, not a vague sense that an application looks underused. Set an inactivity threshold for each in-scope app, define a grace period, and exclude groups that require special handling. A design tool and an annual tax application probably shouldn't share the same threshold, one gets touched weekly, the other once a year.
Login data isn't perfect. Some apps expose weak or delayed telemetry, and some users need access even when they log in rarely. That limitation matters. Automated license reclamation works when the identity provider has accurate last-login data and the policy includes sensible exclusions.
A practical policy runs in four stages:
- Pull last-login activity for connected applications.
- Flag users who cross the app's inactivity threshold.
- Notify them and allow a defined grace period.
- Revoke access if inactivity continues, then create the service record.
I prefer warnings before removal because they catch legitimate edge cases without turning the whole program into another manual review. If someone still needs the tool, a login or response preserves access. If they don't, the license comes back before renewal.
License optimization and least privilege are often treated as separate programs. They're really the same control viewed by different executives. Security sees unnecessary access. Finance sees an unnecessary subscription. Automate one and you've handled both.
Capture Audit Evidence During Normal Work
Audit evidence should be created when the access event happens. Rebuilding it later from Jira comments, Slack messages, identity provider logs, and screenshots adds work while weakening the chain between approval and action. Memory becomes part of the control. Not ideal.
The service record should show who requested access, who approved it, what identity change ran, whether it succeeded, and when access ended. Access reviews should use the same identity context, including group membership and last-login activity. A revoke decision should also execute, not become another spreadsheet cell awaiting cleanup.
Check the record against five questions:
- Who requested the access?
- Which role or group was involved?
- Who approved or denied it?
- What change happened in the identity provider?
- When was access removed or reviewed?
Missing one field may be manageable. Missing three means the audit process will require reconstruction, and reconstruction the week before an auditor arrives is exactly the headache this whole approach exists to avoid. Automated IT access management earns its value when the evidence arrives as part of the work, because that's the point where security control, SaaS savings, and audit readiness finally meet.
How Multiplier Connects Access Decisions to Jira
Multiplier connects Jira access requests to identity provider actions, then writes the outcome back to the Jira issue. Its workflows can provision approved group access, remove time-bound access at expiry, and reclaim inactive SaaS licenses. The originating ticket remains the record for the request, decision, change, and evidence.
Group Mappings Turn Approval Into Provisioning
Each catalog role can map to one or more groups in Okta, Microsoft Entra ID, or Google Workspace. When a Jira issue reaches the configured Approved status, the product calls the identity provider to add the user to the mapped group. Success or failure is recorded in the ticket, so IT doesn't need to treat approval and provisioning as two unrelated tasks.
Approval workflows can route decisions to a manager, app owner, or specific user through Jira or Slack. For temporary access, the approved duration starts a timer, and expiry removes the identity provider group membership. Automatic revocation only works when access is controlled through that group, which keeps the boundary clear.
The workflow connects four pieces:
- JSM application catalog: Captures the approved app, role, and request context.
- Approval workflow: Routes the decision to the correct person.
- Identity provider group mapping: Executes the approved addition or removal.
- Jira issue history: Records the decision and identity change together.
Auto Reclaim Connects Usage to License Removal
Auto Reclaim uses last-login telemetry from connected identity providers to identify inactive users. Admins set the inactivity threshold, grace period, and group exclusions for each policy. Users receive a warning, and continued inactivity triggers access revocation plus a Jira ticket documenting the removal.
The capability is available on Multiplier's Advanced edition, and it depends on accurate login data from the identity provider. Apps without that telemetry can't be handled the same way. That's an honest limitation, and it's much better than pretending every SaaS license can be reclaimed from one generic report.
Access Reviews add a second control for periodic certification. Reviewers can see identity context and last-login dates in JSM, choose Keep or Revoke, and have supported group removals executed through the identity provider. Results can be exported as CSV or pushed to Vanta, while the underlying evidence stays connected to Jira.
If unused licenses and standing access are already showing up in the same conversations, Get started with Multiplier by walking through one high-volume application and its group mappings. One working path will tell you more than another broad policy document.
Turn Access Governance Into an Operating System
Automated IT access management works when decisions produce identity changes without losing the audit trail. Start with repeatable requests, use identity provider groups for execution, make temporary access expire, and reclaim licenses from real activity. You don't need to automate every edge case on day one.
The first win should be boring and measurable. Pick one app with clear roles, known approvers, reliable login data, and a painful renewal cost. Connect the full path. Then repeat it.
Frequently asked questions
- How do I automate access requests in Jira?
To automate access requests in Jira using Multiplier, start by setting up the Application Catalog. This allows employees to browse approved applications and roles. When they submit a request, a Jira ticket is automatically created. Next, configure approval workflows to route decisions to the appropriate approvers. Once approved, Multiplier will provision access through your identity provider, ensuring a seamless connection between requests and approvals. This setup minimizes manual tasks and keeps everything documented in Jira.
- What if I need to revoke temporary access?
If you need to revoke temporary access, ensure you use Multiplier's Time-Based Access feature. When employees request access, they can select a duration (like 1, 6, or 24 hours). After approval, Multiplier automatically sets a timer to remove access once the time expires. If you want to extend access, it can be done automatically without needing re-approval, simplifying the process during critical tasks.
- Can I track inactive users and reclaim licenses?
Yes, you can track inactive users and reclaim licenses using Multiplier's Auto Reclaim feature. Set inactivity thresholds for each application based on login activity. When a user exceeds this threshold, Multiplier will notify them and allow a grace period. If they remain inactive, access will be automatically revoked, and a Jira ticket will document the removal. This process helps optimize your SaaS spend by ensuring that licenses are only held by active users.
- When should I conduct access reviews?
You should conduct access reviews regularly, ideally every quarter. Use Multiplier's Access Reviews feature to streamline this process. Create campaigns that include only approved applications and assign reviewers. They will receive notifications and can easily mark users as 'Keep' or 'Revoke' based on their last login activity. This ensures that your access management stays up-to-date and compliant with security policies without relying on manual spreadsheets.
- Why does my approval process seem slow?
Your approval process might be slow due to fragmented workflows. To improve efficiency, integrate Multiplier with Jira and ensure that all access requests, approvals, and provisioning actions are handled within Jira. This keeps everything centralized and reduces the need for back-and-forth communication across different platforms. By using automated workflows, you can speed up the approval process and minimize delays.
Frequently Asked Questions
How do I automate access requests in Jira?
To automate access requests in Jira using Multiplier, start by setting up the Application Catalog. This allows employees to browse approved applications and roles. When they submit a request, a Jira ticket is automatically created. Next, configure approval workflows to route decisions to the appropriate approvers. Once approved, Multiplier will provision access through your identity provider, ensuring a seamless connection between requests and approvals. This setup minimizes manual tasks and keeps everything documented in Jira.
What if I need to revoke temporary access?
If you need to revoke temporary access, ensure you use Multiplier's Time-Based Access feature. When employees request access, they can select a duration (like 1, 6, or 24 hours). After approval, Multiplier automatically sets a timer to remove access once the time expires. If you want to extend access, it can be done automatically without needing re-approval, simplifying the process during critical tasks.
Can I track inactive users and reclaim licenses?
Yes, you can track inactive users and reclaim licenses using Multiplier's Auto Reclaim feature. Set inactivity thresholds for each application based on login activity. When a user exceeds this threshold, Multiplier will notify them and allow a grace period. If they remain inactive, access will be automatically revoked, and a Jira ticket will document the removal. This process helps optimize your SaaS spend by ensuring that licenses are only held by active users.
When should I conduct access reviews?
You should conduct access reviews regularly, ideally every quarter. Use Multiplier's Access Reviews feature to streamline this process. Create campaigns that include only approved applications and assign reviewers. They will receive notifications and can easily mark users as 'Keep' or 'Revoke' based on their last login activity. This ensures that your access management stays up-to-date and compliant with security policies without relying on manual spreadsheets.
Why does my approval process seem slow?
Your approval process might be slow due to fragmented workflows. To improve efficiency, integrate Multiplier with Jira and ensure that all access requests, approvals, and provisioning actions are handled within Jira. This keeps everything centralized and reduces the need for back-and-forth communication across different platforms. By using automated workflows, you can speed up the approval process and minimize delays.
