Access that moves at the speed of a click, not a ticket queue.
The request
Anyone can ask. It routes to the people you chose.
A request for access starts the same way every other request does: one front door, plain language, no form nobody understands. From there it goes to the people you named as approvers, not into a queue where it waits for someone to notice.
The system owner
Whoever owns the tool or the data being asked for. They know whether the access makes sense for the job.
The security admin
A second set of eyes for the access that carries more weight, so a sensitive grant never rests on one person alone.
Composable for small teams
One person can hold both roles when that is your reality. You set the cast; the rails are the same whether it is two approvers or ten.
The decision
Approve or deny from a link. No login to say yes.
Approvers get a message with a secure, single-use link. They open it, read what is being asked and why, and decide. Nothing to install, no account to create, no password to remember before they can answer.
A token-gated link, not a login
The link carries a short-lived token scoped to that one request. An approver decides in the moment, on whatever device is in their hand, without signing in to anything.
Multi-party requests roll up
When a request needs more than one approver, everyone sees the same request and their decisions fan in. You watch the count fill toward the yes it needs.
A single denial stops it cold
If any required approver says no, the request ends there. No partial grant slips through, and the person who asked gets a clear answer instead of silence.
The execution
Approval is not access. Someone still has to do the work.
This is where a workflow tool hands you a green checkmark and walks away. A yes is a decision, not a provisioned account. When an access request is approved on the platform, a provisioning ticket goes to our operators, and they do the work: create the account, set the scope, and close the loop back to you.
The request clears
Every required approver has said yes. The decision is recorded with who approved it and when, so there is a real trail behind the access.
A provisioning ticket opens
The approved request becomes a task for our operators, scoped to exactly what was asked and approved. Nothing broader gets granted by accident.
An operator grants it
A real person provisions the access in the system it belongs to, with the least privilege the job needs, and marks the work done.
You see it close
The request moves to done in the portal, the person who asked can get to work, and the record stays with the rest of your audit trail.
Joiners, movers, leavers
The same rails run onboarding and offboarding.
Granting access to a new hire, changing it when someone moves teams, and removing it when someone leaves are the same shape of work. They run on the request-and-approval rails you already have, so a departure closes out cleanly instead of leaving live accounts behind.
A new hire starts ready
The access a role needs is requested and approved before day one, so a new person can get to work instead of waiting on a queue.
- Request the standard access for the role up front
- Route it to the same approvers, on the same rails
- Our operators provision it so it is live when they arrive
A change keeps access honest
When someone moves teams, access changes with them. The new access is requested and approved, and the access the old role no longer needs comes off.
- Add what the new role needs, on approval
- Remove what the old role no longer justifies
- One record shows what changed and who approved it
A departure closes out fully
When someone leaves, their access is removed rather than quietly forgotten. Offboarding runs as its own tracked work, so accounts do not stay live after the person is gone.
- Offboarding opens as tracked work, not a mental note
- Access is removed across the systems it touched
- You can see it closed, with a record that it was
Step away without worry
Mark yourself away and requests route around you.
Approvals should not stall because one person is out. Anyone in the cast can mark themselves away, and requests route to whoever is covering instead of waiting on an empty inbox. Nothing sits blocked while you are on a plane or on leave.
Set yourself away; requests route to whoever is covering.
Your team, your cast, your control
The team console is where you name approvers, set who covers for whom, and adjust the cast as your org changes. You hold the roles; we run the work behind them.
The team console: set the cast and the roles you approve with.
Access without the ticket queue, or the orphaned accounts.
See how requests, approvals, and the joiner-mover-leaver lifecycle run on one set of rails, with our operators doing the provisioning behind them.
Walk through how access requests route to your cast, clear in a click, and get provisioned by our operators, mapped to your team.
Access requests are one front door among many. See how the rest of your cloud, IT, and security run in the same place.