Access requests
Access requests that leave a paper trail
Most access is still granted the informal way — a Slack message to whoever has admin, a quick “sure, done.” It’s fast, but there’s no record of who asked, who approved, or why. When an auditor asks how a particular person got production access, nobody can answer. An access request workflow fixes that: every grant starts as a request, routes to the right approver, and lands in an auditable log. Useboards gives you that workflow without an enterprise rollout.
What a real access request workflow needs
The goal isn’t a ticket queue — it’s an approval that’s attributable and appropriate to the access being granted. Read access to a shared dashboard shouldn’t take the same chain as admin on your production database. A workflow that actually holds up has a few properties:
- The requester picks a specific system and a specific access level — not a vague “give me access.”
- Approval routes to the person accountable for that system, and the chain can get stricter for higher-privilege levels.
- Who approved, when, and any justification is recorded — not remembered.
- The granted access flows into the same catalog you review and offboard against, so nothing lives only in someone’s inbox.
Approval flows, configured per system and per level
In Useboards, each system in your catalog can define its own approval flow — and you can override that flow for a specific access level. A read-only tier might auto-approve or take a single owner sign-off, while the admin tier on the same system runs a stricter chain. Within a stage, approval is ANY-of: the first holder of any listed role to approve closes that stage. Across stages, it’s ALL-of: every stage must clear before the grant is provisioned. That’s enough to model “owner approves, then security signs off” without building a workflow engine yourself.
- Per-system templates — each app defines who approves access to it.
- Per-(system, access level) overrides — same product, stricter chain for the privileged tier.
- ANY-of within a stage (first eligible approver wins), ALL-of across stages.
- Notification-only stages that inform a stakeholder without blocking.
Routing modes: immediate, manual, or auto-approve
Not every request should wait on a human. Useboards supports three routing modes so the workflow matches the risk. Immediate routing sends the request straight into its approval flow the moment it’s submitted. Manual routing parks the request for a flow admin to direct it — useful when the right approver depends on context. And when a system has no flow defined, the request auto-approves, so low-risk access doesn’t create busywork. Revokes are deliberately different: a revoke never waits in an approval queue — it executes immediately, because delaying the removal of access is the risk.
Where requests fit the bigger loop
An access request isn’t an island. The grant it produces shows up in the system catalog, gets reviewed in your next user access review, and gets removed when the person offboards — all against the same record. Approvers see what’s waiting on them in one queue instead of scattered across channels. Because every step is captured in an append-only audit log, the request you approved in March is still provable in your December audit.
Frequently asked questions
What is access request software?
It’s software that turns informal access grants into a controlled workflow: a user requests access to a specific system and level, the request routes to an accountable approver, and the decision plus the resulting grant are recorded. It replaces the Slack-DM-to-an-admin pattern that leaves no audit trail.
Can approvals differ by system or access level?
Yes. In Useboards each system defines its own approval flow, and you can override it for a specific access level — so a read-only tier can take a light touch while the admin tier on the same system runs a stricter, multi-stage chain.
What do ANY-of and ALL-of mean for approvals?
Within a single stage, approval is ANY-of: the first holder of any eligible role to approve closes that stage. Across stages it’s ALL-of: every stage must clear before access is granted. That lets you model “any owner approves, then security signs off” without custom code.
How does this help with a SOC 2 audit?
Access provisioning through documented approval is a common control under SOC 2’s logical access criteria (commonly CC6.1–CC6.3). Because every request, approval, and grant is captured in an append-only log, you can show an auditor exactly how a given person got their access and who authorized it.
Related
Stop granting access by DM
Route every request through an approval flow and keep the trail — set up in an afternoon.