Access and Approval Automation
Access and Approval Automation
Requests routed to the person who knows the answer, and the identity system called directly once they approve.
What this is
A large share of what a small IT function does all day is access. Somebody is locked out, somebody needs the folder, somebody starts on Monday and needs eleven accounts, somebody left in March and still has five.
Automating it means giving the request a route, sending the approval to the person who actually knows whether it should be granted, and then calling the identity system to make the change.
There is almost no model in this work. It is a form, a routing rule, an approval and an API call, which is why it is normally the fastest thing in this cluster to get into service. A model earns a place only at the edges, such as reading a free-text request and working out which route it belongs to.
What you get
What gets built
A route per request class, the approval moved to where the answer is, and a record at the end of it.
A request route people will use
A form in Teams, a portal page or a ticket type that asks for what is actually needed rather than accepting 'please give me access'. Half the delay in the current process is the two emails spent working out what was being asked for.
Approval by the person who knows
The requester's manager or the system's owner, not a queue somebody triages later. Moving that authority off the IT desk is where most of the waiting disappears, and IT keeps the ability to see and reverse anything a route did.
The provisioning call
Group membership, licence assignment or an application role written through the identity system's API the moment the approval lands. The same route can carry the downstream systems — the ticketing tool, the file store, the line-of-business application.
Joiner, mover and leaver routes
The same machinery run forwards for a new starter and backwards for a departure. The second one is the half that usually never got built.
Time-bound access
Access granted for a stated window and removed when it expires, for contractors, projects and anything else that was always meant to be temporary. Expiry is set at the moment access is granted rather than written into somebody's calendar.
Self-service inside the tenant's rules
Password and sign-in method resets handled by the person who needs them, within the boundaries the tenant already enforces.
A record of every grant
What was asked for, who approved it, exactly what changed, and when it was removed — as a record you can query rather than a mailbox thread somebody has to go and find.
Access review packs
A periodic list of who currently has what, sent to the person who owns each system to confirm or revoke. It is the only mechanism that reliably reverses years of accumulated access.
How it works
How the work runs
Count the request classes
Three to five kinds of request are normally most of the volume. The ticket history says which, and it is often not the ones people name from memory.
Decide who approves each one
For every request class, who holds the authority and what approved actually means. This is the slow part, it is not technical, and it is where the saving actually comes from.
Build one route all the way through
One request class from the form to the provisioning call to the record, running against real requests with somebody watching the first week of them.
Add the next classes
Once the first route is trusted. The leaver route is usually second, because it is the one with a standing benefit rather than a per-request one.
What matters
What the design has to get right
This work touches the directory, so the interesting parts are all about scope and record-keeping.
The automation holds standing privilege
Whatever can add a person to a group can add anyone to any group. Where that credential lives, what it is scoped to and who can trigger it is the central design decision, not a detail at the end.
Scope the permission to the routes, not the directory
The application registration gets only the directory permissions the built routes actually use, and authenticates as a managed identity rather than a stored key wherever the platform allows it. A directory-wide administrative role is the easy answer and the wrong one.
The approver has to be a recorded fact
Routing to 'the manager' depends on the manager field in the directory being right, and in most tenants it has drifted years out of date. Correcting it is part of the work, and it improves several other things at the same time.
Running it twice must be safe
Automation platforms deliver at least once, so a retry has to be harmless. A duplicated grant is untidy; a duplicated removal locks somebody out mid-morning.
Removal is the part that decays
Grants accumulate quietly because nobody is ever asked to give access back. Time-bounding, the leaver route and the review packs are what keep the directory honest between audits.
The failure path lands with a person
When the identity system rejects a call, the request goes to a human with the error attached rather than into a log nobody reads. A request that silently stopped is worse than one that was never automated.
Who it is for
Where this pays
Businesses where IT is one or two people
Access requests are the interrupt that stops anything longer than ten minutes from ever getting finished, and they arrive at the least convenient moment of the day.
Firms with contractors or seasonal staff
People arriving and leaving constantly, each needing a defined set of access for a defined period. The leaving half is normally the weaker one.
Firms that have to show who approved what
Professional and regulated businesses where the record of the approval matters as much as the grant itself, and gets asked for at the least convenient time.
Anyone with a folder-access backlog
A standing queue of 'can you give me access to' requests that everybody has stopped apologising for.
Questions
Frequently asked questions
Is there actually any AI in this?
Mostly no, and it is worth saying plainly. This is routing, approval and an API call — it is here because it is often the fastest work to pay for itself, not because it is clever.
Which identity systems does it work with?
The shape is the same wherever identity lives. Microsoft 365 and Entra ID are the common case here, and the same route pattern calls Okta, Google Workspace or a ticketing system's API rather than driving a screen. What changes between them is the permission model, not the design.
What stops someone approving their own request?
The route defines the approver and it is never the requester. Every grant carries the identity of the person who approved it and the time they did it.
Do we give up control by automating this?
Approvals still happen, and they become visible. Today most grants are a chat message and somebody's memory; afterwards each one has a request, a named approver and a timestamp. Approvers can also be given a route to revoke, which today usually means raising another ticket.
How long does it take to build?
A single request class is normally days rather than weeks. Adding the joiner and leaver routes takes longer, because those decisions are organisational rather than technical.
What about offboarding?
It is the same route run backwards, and it is worth building early. Access removal is where most tenants have drifted furthest from what anybody intends.
Also on this site
Start with the request you get most
The one that arrives every day and waits for somebody in IT to have a free minute.
(844) 422-7000