The three scenarios that define access request management are almost universal: a new hire who needs accounts and access provisioned, an existing user who needs access modified, and a terminated employee whose access needs to be removed. Every organization has some process for handling these. The question is whether that process is sustainable as headcount grows.

At 20 people, a Jira workflow with checklist subtasks is workable. At 200 people with dozens of applications, manual ticket-based access management becomes the source of the security problems it was supposed to prevent: provisioning delays that block new hires on day one, role changes that add new access without removing old access, and terminated employees who retain access because offboarding checklists were completed inconsistently.

The alternative is treating access management as an identity lifecycle problem rather than a ticketing problem.

The JML Framework: Why Access Management Is Not Primarily a Helpdesk Function

The practitioner framing that most experienced IAM professionals land on is this: access request management should not primarily be a function of end users filing tickets. It should be a function of identity lifecycle events.

A new hire is not an access request. It is a Joiner event. The access they need follows from their role, department, and location, and the system should be able to determine and provision most of it automatically based on those attributes. What cannot be automated should be routed to the right approver with the right context.

A role change is not a modification request. It is a Mover event. It should simultaneously deprovision access that no longer applies and provision access for the new role. Doing only half of this is how privilege creep accumulates.

A termination is not a deprovisioning ticket. It is a Leaver event. Every application the user accessed needs to be identified and access revoked. The checklist approach fails here because it only covers the applications IT knows about.

This reframing matters because it changes where the trigger lives. Instead of waiting for a manager to file a ticket, the identity lifecycle event in the HR system triggers the workflow automatically. The approval workflow covers exceptions and discretionary access, not the baseline access that every person in that role should have.

Joiner: Provisioning New Hires Without Manual IT Work

The ideal new hire provisioning flow starts in the HR system and ends with the employee having access to everything they need on day one, without anyone filing a ticket.

The mechanism is birthright access: a predefined set of applications and permissions tied to a specific role, department, and location combination. When a new hire record appears in the HR system with the role "Sales Representative," the provisioning playbook for that role runs automatically: AD account created, email provisioned, Salesforce access granted at the standard rep permission level, ERP access granted at the standard level, and any other applications that every Sales Representative needs.

This covers the standard case without any manual IT involvement. Edge cases, additional access beyond the birthright set, or roles without a defined template go through a self-service request workflow.

Zluri connects to HR systems (Workday, BambooHR, and others) as the source of truth, detects new hire records, and triggers the corresponding playbooks. The provisioning happens through direct API integrations with the target applications, not through manual IT action.

Mover: Role Changes That Handle Both Sides of the Transition

The most common failure mode in access management for role changes is that organizations provision the new access without removing the old access. The manager submits a ticket for what the employee needs in their new role. IT provisions it. Nobody submits a ticket for what should be removed. Over time, users accumulate access from every role they have ever held.

The correct approach for a role change is a single automation that runs both directions simultaneously: a deprovisioning playbook that removes access tied to the previous role, and a provisioning playbook that grants access for the new role. This happens as a single event triggered by the role change in the HR system, not as two separate tickets that may or may not both get filed.

For access that falls outside the automated role transition, employees can submit requests through a self-service catalog. In Zluri, this is the App Catalog, accessible through a web portal or directly through Slack. The employee selects the application, specifies the access level, duration, and business justification, and submits. The request routes to the appropriate approver automatically.

Leaver: Offboarding That Covers Everything, Not Just the Checklist

Offboarding checklist failures happen for two reasons: the checklist is incomplete (it does not include applications purchased by individual teams that IT does not know about), and the checklist depends on someone executing it correctly under time pressure.

The structural fix is an offboarding playbook triggered by the termination event in the HR system, not by someone filing a ticket. The playbook runs against a continuously maintained inventory of everything the user has accessed, not against a static list. It revokes access systematically across every connected application, logs each action, and can be scheduled to run at the exact time of the employee's last day.

Shadow IT, the applications employees adopt without going through IT procurement, is where most offboarding failures occur. Zluri's discovery engine surfaces these applications as part of ongoing SaaS monitoring, so the offboarding playbook knows about them rather than leaving them as blind spots.

After offboarding completes, the platform generates a record of every access revocation: which application, what access level was removed, and when. This audit trail is the evidence an auditor or compliance team needs to confirm the offboarding was complete.

Approval Workflows: Routing the Right Requests to the Right People

Not all access changes should be automatic. Birthright access for well-defined roles can be automated. Exceptions, elevated access, and discretionary requests should go through an approval workflow.

The workflow configuration covers three questions: who approves what, what context do they receive, and where do they act.

For most access requests, approval should route to the application owner or the user's direct manager, not to the IT team. IT is a bottleneck for routine approvals and the wrong person to judge whether a Sales Representative should have a specific Salesforce permission level. The application owner or the manager has the context to make that decision.

Approvers receive a notification in Slack or email that includes everything they need: who is requesting, what they are requesting, the permission level and duration, and the business justification. The approver can approve or reject directly from the notification without logging into a separate system. Approved requests trigger provisioning automatically. Rejected requests are logged with the reason.

Approval workflows should also handle time-bound access. For temporary project access, the request specifies a duration. When the duration expires, access is revoked automatically through a linked deprovisioning playbook. The access is genuinely temporary because the system enforces the end date, not a person's calendar reminder.

What to Use at Different Scales

The right tooling depends on where an organization is in its growth:

At small scale (under 50 people), Jira workflows with checklist subtasks work. They are not scalable, but they are better than email threads and provide an audit trail. The operational cost is manual IT effort for every provisioning action.

At medium scale (50 to 500 people), the manual process starts producing visible failures: provisioning delays, incomplete offboarding, accumulated access. A lightweight IGA platform or a dedicated access governance tool becomes cost-effective relative to the manual overhead.

At larger scale, a full IGA platform with deep HR system integration, automated lifecycle workflows, and access review capabilities is the standard approach. Platforms like SailPoint provide this at enterprise depth. Zluri positions in this space with a focus on SaaS-heavy environments, out-of-the-box integrations, and Slack-first workflows that reduce the administrative overhead of running governance programs.

For the specific use case of HR-driven JML workflows with approval routing, Zluri covers the full cycle: HR system integration for trigger events, birthright access provisioning for Joiners, simultaneous deprovision-and-provision for Movers, and discovery-backed offboarding playbooks for Leavers. Access requests for discretionary access go through the App Catalog with Slack-based approval notifications.

The Audit Trail That Actually Satisfies Auditors

One of the reasons organizations graduate from Jira-based access management is the audit trail. Jira tickets provide a record that someone created a ticket and the ticket was closed. They do not produce a system-generated record of exactly what access was provisioned, when, and by what mechanism.

For SOC 2, ISO 27001, or HIPAA audits, the evidence auditors want is: who had access to what system, when was it granted, who approved it, and when was it revoked. A Jira ticket that says "done" does not answer these questions reliably.

An IGA platform that provisions access through API integrations logs every action: which application, what permission level, when it was granted, the approval record, and when it was revoked. That log is queryable, exportable, and constitutes the evidence trail auditors actually need rather than a reconstruction from closed tickets.