You already know what the policy should look like. What you're trying to figure out is what system actually makes it work — how requests come in, how data owners approve them, who does the provisioning, and how you catch access that should have been removed six months ago. The honest answer from people who've solved this problem is that there's no universally right architecture, but there's a clear pattern between organizations that have it working and those that are still running on HR emails and Word docs.
What User Access Provisioning Actually Looks Like at Most Companies (Before It's Fixed)
The thread that prompted this question is eleven years old and the answers are still completely current. That's worth noting.
One commenter described their current company's process — 400 users, HR emails the helpdesk, helpdesk creates a ticket with a Word doc attachment, different people inside and outside IT handle different pieces of provisioning, nobody is entirely sure how the non-IT people get notified. Their summary: "It's a mess." The same commenter described their previous company — 1,500 users with high turnover, custom access frontend with a SQL backend, job title as the sole determinant of access, exceptions requiring executive sign-off. That system worked. The in-house build took significant time and required a prior effort to rationalize job titles and security roles before the automation was even possible.
Another commenter was mid-implementation on a SharePoint frontend with InfoPath forms, writing directly to the HRIS and AD. Automated access provisioning was described as "a distant maybe."
The pattern is consistent across the thread and consistent with what most IT teams experience: the process that works was either built in-house over years of iteration, or it's still manual and everyone is quietly frustrated by it. The OP's question — is there a package that could be purchased that has the functionality? — was reasonable even in 2013. The category of software that answers it is now much more mature.
What the Workflow Needs to Actually Cover
Before evaluating any tool, it's worth being specific about the components, because "access provisioning workflow" means different things to different teams and most software handles some parts better than others.
Request format. How do employees request access? Email, ticket, form, Slack message? The format matters because it determines what information arrives with the request and how consistently it's structured. A free-text email produces inconsistent information that requires back-and-forth before an approver can make a decision. A structured form with required fields and dropdowns produces complete, consistent requests that approvers can act on immediately.
Approval routing. Who approves access requests, and how does the right person get notified? For sensitive applications, a single manager approval may be insufficient — the data owner, the application owner, and a security reviewer may all need to sign off. The routing logic needs to handle this without requiring IT to manually forward requests to each stakeholder.
Provisioning execution. Once approved, who does the actual provisioning and how? For AD-connected systems, this can be automated. For legacy systems managed by DBAs, a human has to take action. The workflow needs to handle both cases and track completion for both — not just automate the easy ones and ignore the rest.
Access creep management. How do you periodically review whether access granted six months ago is still appropriate? Without a structured review process, access accumulates. People change roles, projects end, and the access they needed for something temporary stays in place indefinitely. The review mechanism needs to be systematic and produce a documented record, not rely on someone remembering to check.
How Modern IGA Platforms Handle Each Part of the Workflow
The category of software that addresses this end-to-end is Identity Governance and Administration. Zluri handles each of the workflow components the thread described, and it's worth being specific about how.
Request format. Employees submit access requests through a web-based app catalog or via a /accessrequest command in Slack — whichever is lower friction for the user population. The request form is configurable: IT admins define the custom fields (business unit dropdown, project justification text box, temporary access date picker) so approvers receive complete, structured information with the initial request. No back-and-forth to gather context that should have been captured upfront.
Approval routing. Automation rules with conditional IF/THEN logic handle routing. When a request is submitted, it goes automatically to the designated approver for that application — the app owner, the reporting manager, a specific user group, or any combination in sequence. Up to five sequential approval levels can be configured for highly sensitive systems. Approvers receive notifications via email and Slack and can approve or reject directly from the notification without logging into a separate tool. The approval chain is recorded automatically regardless of which channel the approver uses.
Provisioning execution. After final approval, Zluri executes provisioning based on what the application supports. For API-integrated applications, a provisioning playbook runs automatically — account created, license assigned, role applied, no IT intervention needed. For legacy systems without API support, a manual task is generated and routed to the appropriate DBA or system admin, either directly or as an automatically created ITSM ticket in Jira or ServiceNow. When the DBA marks the task complete, that action is logged alongside the automated steps in the same audit trail. The workflow doesn't have two different record-keeping systems for automated and manual provisioning — it's one record either way.
Access creep management. Zluri's access certification module handles periodic review campaigns. Reviews are scheduled (quarterly, annually, or on a custom cadence), automatically routed to the appropriate reviewers, and completed within the platform. The system flags high-risk access and inactive users for prioritized review rather than requiring reviewers to evaluate every access entry equally. Once reviewers complete the certification, the documentation is generated automatically in audit-ready format — no manual compilation from spreadsheet exports across multiple systems.
The In-House Build Question
The commenter who described their old company's working system was clear about what made it work: a prior effort of over a year to rationalize job titles and security roles before the automation was built on top of them. That prerequisite — clean, structured data about what each role should have access to — is the foundation that any access provisioning system depends on. A purchased platform doesn't skip that step. It just provides the tooling to build the workflow once the foundation exists.
The SharePoint + InfoPath + PowerShell path that multiple commenters described is a legitimate approach for organizations with the in-house development capability and the appetite for ongoing maintenance. It's also genuinely a lot of work to build and keep working. The specific things that require ongoing maintenance — form updates when request types change, PowerShell scripts when AD structure changes, notification logic when organizational structure changes — are each individually manageable and collectively a significant IT overhead.
The decision between building in-house and buying a platform is mostly a function of how much of the in-house build is differentiated for your specific environment versus how much is the same workflow that every organization with access governance needs. The request form, the approval routing, the provisioning logic, and the access review mechanism are not unique to any organization. The specific applications connected, the specific approval policies, and the specific roles and entitlements are. Platforms handle the former; configuration handles the latter.
Frequently Asked Questions
What software handles end-to-end user access provisioning including approvals and access reviews?
Identity Governance and Administration (IGA) platforms handle the full lifecycle: structured access requests, automated approval routing to app owners or managers, provisioning for API-connected systems, tracked manual task routing for legacy systems, and periodic access certification campaigns. Zluri, SailPoint, and Saviynt are all in this category, with different strengths depending on environment size and complexity.
How do you manage approval routing for access requests across different data owners?
Approval routing should be configured based on the application and the sensitivity of the access, not handled manually by IT forwarding requests. IGA platforms use conditional routing rules that automatically send requests to the designated approver (app owner, manager, security team) for each application, with multi-level approval support for sensitive systems.
What is access creep and how do you prevent it?
Access creep is the accumulation of permissions over time as employees change roles, complete projects, or simply retain access that was granted temporarily. Periodic access certification campaigns — where current access entitlements are reviewed and confirmed or revoked by the appropriate business owners — are the standard mechanism for controlling it. Without a structured review process, access accumulates indefinitely.
Is SharePoint a good solution for user access provisioning workflow?
SharePoint with InfoPath forms and PowerShell automation can handle basic access request workflow, and several teams in the original thread were building or considering this approach. The tradeoff is build and maintenance overhead: every change to request types, approval logic, or connected systems requires development work. A dedicated IGA platform handles these as configuration changes rather than development tasks.
How do you handle provisioning for legacy systems that don't have API integration?
For systems without API access, the provisioning step requires a human — typically a DBA or system admin. The difference between a managed and unmanaged manual step is whether it's tracked: an IGA platform generates an automated task routed to the right person, delivered via email, Slack, or ITSM ticket, and marked complete when the action is taken. The entire workflow — including the manual steps — is documented in the audit trail.
See How Zluri Handles Your Specific Access Provisioning Workflow
Most teams that are still on email-based approvals and SharePoint forms know the process has gaps — they find them during audits or when someone leaves with access they shouldn't have had. See how Zluri's access request, approval, provisioning, and review workflow handles your specific environment, including the legacy systems that can't be fully automated.
.svg)
