Access requests

Requests where the work already happens

What replaces the ticket queue, and the DM people send instead of using it.

You make the request where you already are, in Slack or the service desk. Policy fills in the app, the template, the duration and the group, so the only thing anyone types is the reason.

That matters more than it sounds, because the alternative is not a slower request. It is no request at all. A request that requires opening a second tool becomes a DM instead. And a DM is not a record.

That is the practical reason ticket queues underperform for access. Not that they are slow, though they are, but that they are avoidable, and the avoidance is invisible.

The approver problem

The deeper issue is that approvals are uninformed.

A ticket says "Marcus Lee requests Salesforce Admin". The approver knows Marcus. They do not know your Salesforce configuration, what that profile reaches, or whether he had it last quarter and gave it back.

Given approve, deny, or find out: approving takes 11 seconds and finding out takes an afternoon. So the control becomes a formality, and everyone involved knows it.

What replaces it

An access request in Slack: AWS, the Oncall-escalation template, a two-day duration set automatically, and a free-text reason box.

The request, where the work already happens. Duration and IAM groups come from the template; the only thing typed is the reason.

The request is made where the person already is. The app, the template, the duration and the groups come from policy, so the only thing typed is the reason, which is the only part policy cannot supply.

The approval carries what the decision needs: what this person has in that app today, what the requested role adds described as capabilities rather than a role name, whether they have asked before and what happened, and what policy caps the grant at regardless of the answer.

Approve in the same place. Provisioning follows in seconds.

Why this is not just a nicer form

Because the record is the point. Every request carries who asked, why, who approved, what was provisioned, when it expired, and whether it was ever used.

That last field pays for the whole thing. Access nobody exercised is access nobody needed, and it is the fastest way to find the standing grants worth removing before an auditor finds them for you.

Frequently asked questions

Only if you want it to. Iden can raise and close the ticket in your ITSM so the existing process is untouched, or own the request end to end.

The request looks identical to the person asking. Fulfilment goes through whatever the app supports: SCIM, an API, or a custom connector driving the admin console.

The app owner by default, with policy able to route differently for sensitive access. Ownership is set once per connector rather than argued about per request.