There are two ways to give someone production database access. Grant it and hope they mention when they are done, or grant it for four hours.
Almost every team does the first, then runs an access review twice a year to undo the damage. That is not governance. That is cleanup on a schedule.
The queue is not the problem, the queue is the symptom
Access requests are slow for a reason that has nothing to do with the tooling: the person approving has no basis on which to say no.
A ticket arrives saying "Marcus Lee requests Salesforce Admin". The approver knows Marcus. They do not know your Salesforce configuration, what that profile can reach, or whether he had it last quarter. Given a choice between approving and finding out, approving takes eleven seconds and finding out takes an afternoon.
So requests get approved, and because getting access is slow and annoying, people ask for more than they need while they have somebody's attention. Then it never goes away.
Where access requests go to wait behind laptop orders and password resets.
Given once for a migration in 2024 and never taken back, because taking it back is somebody's afternoon.
What people fall back on at 3am when the approval path is slower than the incident.
Let people ask where the work already happens
A request that requires opening a second tool becomes a DM instead, and a DM is not a record.
The request, where the work already happens. Duration and IAM groups come from the template; the only thing typed is the reason.
The whole request in that screen is one sentence of typing. The app, the access template, the duration and the IAM groups all come from policy. The only free text is the reason, because the reason is the only part a policy cannot supply.
Note the duration, set to two days automatically. Nobody chose that in the moment. It came from the template, which is how you get expiry to happen consistently: by deciding it once, when nobody is under pressure, rather than every time somebody is.
What the approver sees
The request that reaches the app owner carries what they need to decide:
What the person has in that app today. What the requested role adds on top, described as capabilities rather than a role name. Whether they have asked before and what happened. And what the policy caps this grant at regardless of the answer.
That last one matters more than it looks. An approver who knows the grant expires in 24 hours is making a much smaller decision than one who thinks they are granting it permanently, and small decisions get made honestly.
Expiry comes in three shapes
Time-boxed. A fixed window from policy. Four hours of production access during an incident, expiring whether or not the incident is closed. If it needs longer it gets requested again, and the second request is a signal worth having.
Task-bound. Tied to the thing it was for rather than to a clock. Access granted for a ticket ends when the ticket closes.
Standing, and marked as such. Some access should persist. A support engineer needs the helpdesk daily. Those grants stay, but they are recorded as deliberate rather than defaulted into, which means the access review has something reviewable: a short list of decisions somebody made, instead of everything anyone ever asked for.
Most stacks cannot tell a deliberate standing grant from an expired temporary one, because nothing recorded the difference at the moment of granting. That is the gap this closes.
Break-glass is a path, not an exception
A policy that blocks an incident is a policy people route around, and the first time somebody shares a credential to get through an outage, your controls are decorative.
So break-glass is designed in. The grant is issued immediately against a named policy that says who may use it and for what. The review happens afterwards. It is logged as break-glass, so it never sits in reporting looking like a normal approval.
The measure of this working is not that break-glass is never used. It is that nobody had to use a shared login instead.
What actually changes
What this does not do
It does not make approvals unnecessary. It makes them cheap and informed, which is different.
It does not work on an app nobody owns. Every route here ends at a person who is accountable for that application, and if that person does not exist the request has nowhere to go. Assigning owners is the unglamorous prerequisite for all of it.
And it will not fix a culture where everything is urgent. If every request is marked critical, expiry becomes the only real control you have, and it works, but it works by attrition rather than by anyone making a decision.