Overview
Request on behalf lets an employee submit an app access request for someone else — a manager onboarding a new hire, an IT admin provisioning a team, or a team lead setting up a contractor.
The request is submitted by one person but filed for another. Torii evaluates the catalog and all access request policies against the target user, so eligibility, approval flows, and provisioning behave exactly as if that person had requested the app themselves. Nothing is bypassed.
Use cases:
- A manager requests all the tools a new hire needs before their first day, while they are still being onboarded.
- An IT admin provisions a tool for a team that is migrating, without chasing each person individually.
- An employee requests a shared tool for a contractor who doesn't use Torii directly
Enabling the feature (admin)
- Go to App Catalog → App catalog settings.
- Open the Request access to an application section.
- Set Allow requesting on behalf to Yes.
- Check "Managers can request for employees"
- Optionally, choose which groups may request on behalf of every user.
Setting the control back to No hides the feature from all users and clears the group selection.
| Setting | What it does |
|---|---|
| Allow requesting on behalf — No (default) | The feature is hidden. Employees can only request apps for themselves. |
| Allow requesting on behalf — Yes | Managers can request for their employees |
| Groups | Users on that groups can request for every user |
Who can change this: users with write permission on the App Catalog.
Where the "manager → employee" relationship comes from
When requesting on behalf is limited to managers requesting for their employees, Torii decides who counts as your employee by reading your organization's organizational hierarchy — it does not maintain a separate reporting structure for the App Catalog.
It's detected automatically
Organizational hierarchy defaults to the manager field in your Employee definition — the identity provider or HR system you use to define current and past employees, such as Google Workspace, Microsoft Entra ID, or your HRIS. In most accounts this works with no setup.
Where to find it
Go to Settings → Users & Employees → Organizational hierarchy. The field shown there is the user field that defines reporting relationships across Torii (for example, Google Workspace User Manager).
Requesting access for someone else (employee)
- Open the App Catalog.
- In the top-right corner, click the arrow next to Request new app
- Search for and select the person you're requesting for.
- Browse and select an application, then click Request access as usual.
- Fill in the request form and submit.
The app list reflects the target user's eligibility — you'll only see and be able to request apps that they are eligible for.
Notifications
| Recipient | What they receive |
|---|---|
| Requester (submitted on behalf) | Confirmation that the request was submitted, and a notification when it is granted or declined. No notifications for intermediate approval steps. |
| Target user (request is for) | The standard access request notifications, with the copy updated to name who submitted it — for example, "Your access request for {app} has been submitted successfully by {requester}." They continue to receive all downstream notifications (approval, rejection, provisioning). |
| Approvers | The standard approval notification, showing both the target user and the requester. |
Tracking on-behalf requests (admin)
On-behalf requests appear on the Requests page alongside all other access requests, labelled with both names: "Requested for [Target User] by [Requester]."
Approvers see the same information in the approval UI, so they can weigh who is asking as well as who the access is for. See App Catalog - Managing Requests.
Workflows
A personalization token is available for the user who submitted the request on behalf of someone else, so you can reference the requester in provisioning workflow actions and notifications — for example, copying them on a confirmation email or including them in a ticket description.
Requesting on behalf from Slack
When the feature is enabled, the Torii Slack agent supports requesting access on behalf of another user conversationally. When it is disabled, the agent replies that this is not permitted by your administrator.
FAQ
Does this let someone bypass access policies? No. All existing access request policies, eligibility groups, and approval flows apply as if the target user had made the request themselves.
Can I request an app I'm not eligible for, on behalf of someone who is? Yes. Your own eligibility is irrelevant — only the target user's eligibility determines what can be requested.
Can I request access for an external user or contractor without a Torii account? Yes, as long as they are visible in the hierarchy org
Who approves an on-behalf request? The same approvers as any other request for that app, following the approval flow configured on the access request policy and the target user's attributes.
Related articles
- Introduction to the App Catalog
- App Catalog Settings
- App Catalog - Configuring Access Request Policies
- App Catalog - Groups
- App Catalog - Managing Requests
- Requesting App Access via Slack (Slack Agent)