Overview

The App Access Catalog is Torii's self-service hub for application access. It gives your employees an organized, transparent view of the applications your organization supports, and gives you full control over who can request access to what, how those requests are approved, and what happens once they are.

Making an accessible catalog available to your employees helps you:

• Remove application duplications. When employees can see the applications already in use, they choose existing, approved tools instead of introducing duplicate apps or duplicate accounts.
• Identify owners. Application owners are listed alongside each app, making them easier to reach for questions and action.
• Increase utilization and adoption. Employees can easily find and access solutions you already own, rather than requesting new ones.
• Control access requests. Define exactly who is eligible to request each application and route requests through the approval process you decide.
• Automate provisioning. Once a request is approved, a provisioning workflow can grant access automatically with zero touch.
• Gain visibility. Track current and past requests, and use the data in reports and dashboards for better decision-making.

How the catalog is structured

The App Access Catalog has two sides:

• Admin console — where admins manage which apps appear, who can request them, how requests are approved, and what happens after approval.
• Employee catalog — the employee-facing catalog where users browse applications and request access in an organized process you define.

Key concepts

Four building blocks work together to control how users request and gain access to applications:

These are combined into Access Request Policies (access profiles). Each policy has a name and optional description shown to employees, an approval flow, a provisioning workflow, and eligible groups. A single application can have multiple policies to support different access types or user groups — for example, "Standard Access" (auto-approved, for all employees) and "Admin Access" (requires manager approval, for selected groups only). When requesting access, the employee selects the profile that matches their need.

Default behavior

Out of the box, the App Access Catalog is configured so it works immediately, with no setup required:

• Visibility: Applications are included based on your application filters.
• Groups: Set to Everyone — all users can request access.
• Approval flow: Set to Auto approval — requests are approved automatically.
• Provisioning workflow: Set to the default provisioning workflow (with a send-email action).

You can refine any of these settings to match your organization's needs. A good approach is to start with the defaults and tighten access for sensitive applications by adding groups and approval flows where oversight is required.

How the process works end to end

1. An employee browses the catalog and submits an access request for an application.
2. The request appears in the Requests tab for tracking and review.
3. The request follows the configured approval flow (or is auto-approved).
4. Once approved, the provisioning workflow carries out the action to grant access.
5. The requester is notified automatically as the request progresses.

The diagram below shows the full request path — from submission through approval and provisioning to granted access, including the temporary access branch where access is automatically revoked when it expires.

The provisioning workflow

What it is

The provisioning workflow is the automation that runs after an access request is approved. Where the access request policy handles whether and how a request gets approved (eligibility, approval flow, notifications), the provisioning workflow handles what actually happens next — the concrete action that grants the user what they asked for.

In the App Catalog, this is the workflow's sole job. Approvals, eligibility, and requester notifications are managed by their own building blocks, so the provisioning workflow is focused purely on carrying out the result of an approved request.

What it does

Once a request is approved, the provisioning workflow performs the actual action, for example:

• Granting the user access to the application
• Assigning or upgrading a license
• Creating an account via a Torii integration
• Opening a ticket (e.g., in Jira or Freshservice) for apps Torii doesn't provision directly

Because it's a full Torii workflow, you can build in any actions and logic your process needs — including branches based on the requested access type, duration, or user attributes.

Default behavior

Every app's policy has a provisioning workflow assigned. By default it's set to the Default Provisioning workflow, which sends an email notification. You can keep this default or assign a custom workflow tailored to a specific application or access type.

When you'd customize it

Use a custom provisioning workflow when the default email isn't enough — for example, when you want Torii to:

• Automatically provision access for apps that support it, and open a ticket for those that don't
• Assign a specific license tier based on the access profile the user requested

How to assign a provisioning workflow to a policy

1. Go to the Access Request Policies tab and open the app's policy.
2. Edit the policy.
3. Under Provisioning workflow, choose the Default workflow or a create custom workflow.
4. Edit the custom workflow in the workflow editor 

Temporary access

Not every request should last forever. With temporary (timed) access, employees can request a specific license — for example Zoom Pro or Figma Developer — for a defined period, after which access is removed or downgraded automatically. This is ideal for contractors on a fixed engagement or employees who need premium access for a short project, and it helps you:

• Reduce unused or forgotten licenses.
• Improve compliance with internal and external policies.
• Give employees a flexible, self-service experience.
• Maintain full visibility and governance over temporary access.

Temporary access is powered by Access Request Policies and provisioning workflows. Once a timed request is approved, Torii grants access, tracks the duration, and — when the term expires — runs a deprovisioning workflow to revoke or downgrade access, with no manual intervention required. If revocation fails, an admin is notified to resolve it. For setup details and workflow tokens, see Timed Access Request.

Managing requests

The Requests tab provides a centralized view of all application access requests across your organization. From a single place you can review request details, track status, and monitor activity across applications. It shows pending, approved, rejected, and past requests, with predefined views to help you focus:

• Open requests — all currently pending requests.
• Open for more than 1 week — requests that may need attention.
• All requests — a complete history.

Request data can also be exported to CSV, used to create reports, and surfaced in dashboards for ongoing visibility.

Employee access to the catalog

Employees reach the catalog at https://app.toriihq.com/team/appCatalog, where apps are organized into categories that in most cases match employee roles (for example, Customer Success tools, Design tools, and so on).

Signing in with SSO

If SSO authentication is configured for your account, employees can click the Torii tile on your identity provider dashboard (Okta, OneLogin, Google, Microsoft, etc.) and go straight into the catalog. A Torii user is provisioned automatically — there is no separate sign-up. These users are created as members with access to the catalog but not the Torii dashboard. You can grant access to your entire organization or limit it to specific groups or people.

Signing in with or without SSO

With SSO
💡 Having your SSO SAML connected to Torii will ease the login process of employees to the catalog, as they will not need to create a new username/password since they can use your organization's SSO platform.

If SSO authentication is configured for your account, the user can click on the Torii button on your identity provider dashboard (Okta, OneLogin, Google, Microsoft, etc...) and be sent directly into the application catalog. A Torii user will be automatically provisioned for them and there is no need for signing up.

You can allow your entire organization access to Torii from your identity provider or limit it to specific groups or people. Users will be created as members without access to the Torii dashboard but with access to the Application Catalog.

Without SSO

If SSO is not configured for your account, users can sign up using an email and password.
This is the flow for your users:

Step 1

The user visits https://catalog.toriihq.com.

Step 2

The user clicks on the "Sign up" button.

Step 3

The user enters their email address and clicks "Confirm".

Step 4

The user will receive an email with a confirmation link. A click on that link will send the user directly to the application catalog where they will be asked to choose a password.

Requesting access from Slack

Employees can also request app access directly from Slack using the Torii Slack Agent. See Requesting App Access via Slack (Slack Agent).

Set up and learn more

Use these articles to configure and operate the App Access Catalog:

• Configuring Access Request Policies — define visibility, groups, approval flows, and provisioning, including multiple policies per app.
• App Access Catalog - Groups — control who is eligible to request each application.
• App Access Catalog - Approval flow — set how requests are approved.
• App Access Catalog - Managing Requests — track, review, and report on requests.
• Timed Access Request — grant temporary access that expires automatically.