Use case · IT access
Access granted deliberately. And provably.
The access request is the one everybody approves in a DM and nobody can evidence a year later. Capture who needs what, why, and for how long — get the owner’s sign-off on the record, then let the workflow trigger the provisioning.
Free plan, no card required. Submitters are always free.
IT-119
Dan R. · Design
Access request — Figma
- System or tool
- Figma — Organisation plan
- Access level
- Editor
- Business reason
- Joining the design system squad
- Needed until
- 31 Dec 2026
- Handles customer data?routes to security if yes
- No
The access level and end date are the two fields auditors ask for and nobody captures.
Access requests die in DMs and live forever in production
Granting is a two-minute favour. Ungranting is nobody's job. That asymmetry is the entire problem.
A direct message to whoever has admin
- No record of why the access was needed, so nobody can judge whether it still is.
- The person who granted it has left; the permission has not.
- Access level is whatever was quickest — usually more than required.
- At audit time, you reconstruct intent from a Slack export.
A routed access request
- Justification and intended end date captured at the moment of asking.
- The system owner approves, not just whoever happened to be online.
- Sensitive systems branch to security automatically, based on a field.
- Every grant has an actor, a timestamp, and a reason attached to it.
Manager confirms the person. Owner confirms the access.
Two different questions, asked of two different people, which is why a single-approver access process always ends up over-granting.
Access request — execution
trigger
Request submitted
Dan R. requests Figma editor access, with an end date.
approval:select-users
Line manager
Confirms the person needs it for the work they're doing.
condition
handles_customer_data == true
Only sensitive systems pull security into the chain.
approval:group
System owners
A reusable reviewer group — any one of them can decide.
action:webhook
POST provisioning.internal
Approval triggers the account creation, and the step waits on it.
action:set-status
Status: Provisioned
The record reflects what happened, not just what was allowed.
In a group chat
Unknown
Nobody measures it, because there's no start event to measure from — the request was a message.
On Requester
Measured
Time to first review, time to provision, and which step is slowest, per system.
The real gain on access requests isn't speed — it's that the process becomes measurable at all. You cannot improve a workflow whose start time is a DM timestamp nobody records.
Least privilege, by construction
Make access level a dropdown rather than a text box and the request stops defaulting to admin. Make the end date required and “permanent” becomes a deliberate choice someone signed off, rather than the path of least resistance.
The evidence an access review needs
A grant history per system
Filter and save a view per tool: who has been granted what, by whom, and on what justification.
Intent on the record
The stated end date makes stale access visible. You can't automate a revocation you never wrote down.
Provisioning that follows the decision
The webhook step turns approval into an actual account, so the record and reality don't diverge.
Exportable, in full
CSV for a request list, or the entire workspace as one JSON file when an auditor wants the raw data.
What this process leans on
Conditional routing
Sensitive systems pull in security; ordinary tools don't. One form, two different chains.
Learn moreReviewer groups
System owners as a reusable list, so a leaver doesn't break every access request at once.
Learn moreWebhook step
Call your provisioning endpoint as part of the workflow, not as a follow-up someone forgets.
Learn moreAudit log
Actor, timestamp, IP, and user agent on every grant decision, retained and exportable.
Learn moreOn access requests
- Can approval actually create the account?
- Yes, via the webhook workflow node. Once the access is approved, the workflow calls your provisioning endpoint as a step and waits on it, so the request reflects what was actually provisioned rather than only what was authorised.
- How do we handle access that should expire?
- Capture the end date as a date field on the form so the intended duration is on the record, and use a delay node plus a notification to prompt a review when it lapses. Requester tracks and reminds; it doesn't currently revoke access in your downstream systems automatically.
- Who should approve — the manager or the system owner?
- Usually both, and that's a two-step workflow. The line manager confirms the person needs it; the system or data owner confirms the access level is appropriate. Route step one to named approvers and step two to a reviewer group per system.
- Does this help with access reviews and audits?
- Substantially. Every grant carries who asked, who approved, on what justification, and when — exportable as CSV or as the full workspace JSON. Scheduled attestation campaigns are a planned feature rather than a shipped one, so recurring reviews are currently something you run against the record rather than something the product drives.
- Can contractors request access without a seat?
- Yes. Submitters never consume a seat, and an external intake link lets someone with no account at all file a request. Only the people approving are billable.
Other processes teams start with
Purchase approvals
Spend requests routed by amount, approved with the numbers attached.
Time off & HR requests
Leave, equipment, and people requests that stop living in DMs.
Vendor onboarding
Collect vendor detail, route legal and finance sign-off, keep the file.
Expense approvals
Receipts, amounts, and cost centers captured before anyone decides.
Client & external intake
A public link that turns outside requests into tracked work.
Stop granting access in direct messages.
Put one access request form in front of your team this week and start building the grant history you'll want at your next review. Submitters are free.