access request intake form that actually works
Designs an access-request intake form that produces actionable tickets. Covers required fields, approval routing, and what to leave out. Use when building or fixing the request process. Not for approving requests.
TL;DR
The form needs exactly five things: who (identity), what (system and access level), why (business justification), how long (end date), and who approves (sponsor). Everything else is optional. Route automatically to the sponsor first, then to IT. A form missing any of the five generates back-and-forth instead of access.
The error
(Process design; no error.)Steps
- Define the required fields: requester identity (auto-filled from SSO), target user if different, system/application, access level or role, business justification (free text, required), start and end date, sponsor/approver. Expected: form drafted.
- Build approval routing: sponsor approves first, then the system owner for sensitive systems, then IT provisions. Expected: routing configured. IT should never be the first approver.
- Add guardrails: end date defaults to 90 days for contractors, justification minimum length, duplicate-request detection. Expected: configured. Defaults shape behavior more than policy docs do.
- Pilot with one team for two weeks and read every ticket. Expected: friction points found. Fix the form, not the users.
- Publish with a one-paragraph guide: what to request, who approves, how long it takes. Expected: announced. A good form with no guide still confuses people.
When to use
- Building a new intake process
- Fixing a form that generates incomplete tickets
When not to use
- Emergency access (use the break-glass process)
- Approving or provisioning (separate steps)
Compatibility
- ServiceNow, Jira Service Management, or any ITSM with forms and workflows
Variants
High-volume simple requests
Offer a catalog of pre-approved bundles (e.g. "sales starter pack") that skip sponsor approval.
Sensitive systems
Add a second approver (system owner) and a justification review step.
Why it happens
Access requests fail on missing information, not on technology. The five fields exist because every provisioning conversation eventually needs all five answers.
Edge cases
- Allow requesting for someone else (managers request for new hires); validate the target identity.
- Keep the form short; every optional field you add reduces completion.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_AUGCH6xlloWoY71L4j51Vw
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.