Overview
The App Catalog — previously available in Labs — is now the standard Application Catalog experience for all customers. It keeps everything the previous version did and adds new capabilities for controlling, approving, and tracking access requests.
The most important thing to know: nothing you've already set up changes. All of your existing configuration stays intact, your automations run exactly as before, and the experience for your employees stays the same. You don't need to rebuild anything or take any action to keep working the way you do today.
This article explains what stays the same, the one setting we recommend checking, and the new capabilities now available to you.
What stays the same
Everything carries over automatically. Specifically:
- All your configurations remain intact — catalog visibility, app fields, and every policy you've set up.
- Your existing request flows run exactly as before. All "Request Access" methods are still supported, including Compose email, Open link (redirect), and Run automation policy.
- The end-user experience is unchanged. Employees browse and request access from the same catalog, the same way.
- The "Request New Application" flow works exactly the same.
In short, there's nothing you're required to do. The sections below are only about one setting worth checking and the new options you can now take advantage of.
One thing to check: automatic requester notifications
The new App Access Catalog can automatically notify a requester about the status of their request. For existing customers, this automatic notification is turned off by default — because your current workflows most likely already send messages to the requester, and we don't want to double up.
If you'd like Torii to send the automatic requester notification, turn it on:
- Go to App Catalog → Settings.
- Enable the automatic requester notification option.
Leave it off if your existing workflows already handle requester messaging.
What's new and available to you
You can adopt any of these when you're ready — they're additive, not required. The new experience organizes access control into reusable building blocks:
- Access Request Policies (Access Profiles) — define, per application, how users request access. Each profile has a name, an optional description, an approval flow, a provisioning workflow, and eligible groups. A single app can now have multiple profiles (e.g., "Standard Access" vs. "Admin Access").
- Groups — control who is eligible to request access, defined by user filters such as department, role, or location, or by IdP groups.
- Approval Flows — reusable, multi-step approval sequences you can apply across many apps. Each step becomes a Torii approval request task.
- Provisioning Workflow — the workflow's role is now focused purely on provisioning. It runs after a request is approved and performs the action (grant access, assign a license, open a ticket, etc.). Approvals, eligibility, and requester notifications are handled by the dedicated building blocks above rather than inside the workflow.
- Temporary (timed) access — requesters can ask for access for a defined period (or indefinitely), and Torii automatically revokes or downgrades it when the term ends via a configured workflow.
- Requests tab — a centralized view of all access requests (pending, approved, rejected, and historical), with predefined views, CSV export, and reporting/dashboard support. It also includes an Active temporary access view so you can see, at a glance, who currently holds time-limited access and when it expires.
- Requester visibility — employees can now see all of their own current and closed requests on the catalog's My requests page, giving them more transparency into where each request stands.
- Slack Agent — employees can discover and request app access from Slack through a natural-language, AI-powered experience (not just a bot). They can request access to a catalog app, request a new app, check a request's status, and ask questions about apps — all conversationally.
How request statuses work now
Request statuses now reflect the state of the flow itself, so a request's status always tells you exactly where it is in the process:
- For example, the Pending approval status reflects the approval flow: if a policy has no approval flow, the request skips straight to the provisioning status. Other statuses follow the same principle — each reflects the stage the request has actually reached in the flow.
- Because status tracks each stage of the flow, the requester is notified on every status change of their request (when automatic requester notifications are turned on — see above).
Exploring the new capabilities
The best way to explore the new capabilities is by the goal you're trying to achieve. Here are common use cases and how to set each one up.
Use case: Let only certain users request a specific app
If you want to limit who can request access to a particular application, use Groups.
- Go to the Access Request Policies tab and open the policy for the app.
- Edit the policy.
- Under Groups, choose an existing IdP group (or several groups) — or create a new Torii group defined by user filters (department, role, etc.).
- Save. Only users in the selected groups will be able to request that app.
Use case: Offer different types of access for the same app
If a single app needs to support different access types — by license type, role, permission level, and so on — create a separate policy for each type.
- In the Access Request Policies tab, create a New policy (or duplicate an existing one) for the app.
- Define an Access Profile that matches the use case (e.g., "Standard Access" vs. "Admin Access").
- Configure that profile's settings — approval flow, provisioning workflow, and eligible groups — either differently from or the same as your other profiles.
- Save. Requesters will see the applicable profiles and choose the one that matches their need.
Use case: Limit high-permission access to a set time
If you don't want users holding a sensitive, high-permission level of an app for longer than necessary (for example, no more than one day), set an access duration on that app's policy.
- In the Access Request Policies tab, open the app's policy and edit it.
- Set up access duration with a custom duration (e.g., 1 day).
- Define the deprovisioning action that runs when the duration expires (for example, remove the license or downgrade to a lower tier).
- Save. Once granted, track active grants in the Active temporary access view under the Requests tab to see who currently holds time-limited access and when it expires.
Use case: Add an approval step before access is granted
If certain requests need oversight, apply an Approval Flow to the app's policy.
- In the Access Request Policies tab, select the application and open its policy.
- Edit the policy and, under Approval flow, choose an existing flow — or create a new approval flow directly from the policy.
- Define the flow name, approval steps, and approvers for each step (approvers can be specific users or tokens such as the requester's manager).
- Save. The approval flow now applies whenever users request access through that policy.
Approval flows are reusable across apps, and each approval step becomes a Torii approval request task. A single-step flow creates one task; a multi-step flow creates one task per step.
Use case: Get visibility into all requests
To track and report on access requests across your organization, use the Requests tab.
- Go to App Catalog → Requests tab.
- Use the predefined views — Open requests, Open for more than 1 week, and All requests — to track activity.
- Use the Active temporary access view to monitor current time-limited access and expiration dates.
- Export to CSV or build reports and dashboards for ongoing monitoring.
Use case: Track request statistics and adoption
To understand request volume, trends, and how widely the catalog is being adopted, use the out-of-the-box Access Request dashboard.
- Open the out-of-the-box Access Request dashboard.
- Review request statistics — such as request volume over time, status breakdowns, and top requested applications — to spot trends.
- Use these insights to measure catalog adoption and inform decisions about approvals, provisioning, and which apps to surface.
Use case: Let employees request from Slack
To let employees request access from Slack through a conversational, AI-powered experience, enable the Slack Agent.
- Make sure the Slack integration is connected in Torii.
- Go to App Catalog → Settings → Slack agent and follow the setup steps to install the agent in your Slack workspace.
- (Optional) A Slack admin can rename the bot to something familiar for your org (e.g., "IT Help") from the Installed Apps page in Slack.
Once installed, employees can DM the agent in plain language (for example, "I need access to Airtable") to request access, request a new app, check a request's status, or ask about an app.
Frequently asked questions
Do I need to rebuild or reconfigure anything? No. All of your configurations, automations, and request flows carry over automatically and work exactly as before.
Will my employees notice a change? The core experience is unchanged — employees browse and request access the same way — with one addition: they now get more visibility through the catalog's My requests page, where they can see all of their current and closed requests.
Can I still use "Compose email" and "Open link" for request access? Yes. All existing request access methods are still supported.
Does the "Request New Application" flow change? No, it works exactly the same.
Why aren't requesters getting the new automatic notification? For existing customers it's turned off by default, since your workflows likely already message requesters. You can turn it on in App Catalog → Settings.
Where do I see the status of requests now? In the Requests tab, which gives you a single view of all pending, approved, rejected, and past requests.
Where do I manage the catalog now? On the main Access Request Policies page. It's where you set which apps appear in the catalog along with each app's access profiles, approval flows, groups, and provisioning workflow.
What's the workflow's role now? Provisioning only. The workflow runs after a request is approved to perform the action (grant access, assign a license, etc.). Approvals, eligibility, and requester notifications are handled by their own building blocks.
Can employees request access for a limited time? Yes. With temporary (timed) access, employees can request a license for a set period, and Torii automatically revokes or downgrades it when the term ends. You can track active grants in the Active temporary access view under the Requests tab.
Why does a request skip the "Pending approval" status? Request status is driven by the approval flow. If the policy has no approval flow, the request moves straight to the provisioning status. An approval request task inside the provisioning workflow does not set the status to pending approval — use an approval flow if you want that status to appear.
Can employees see their own requests? Yes. Employees can view all of their current and closed requests directly in the App Catalog.
Can employees request access from Slack? Yes. The Slack Agent lets employees request access, request new apps, check status, and ask questions conversationally from Slack. Enable it in App Catalog → Settings → Slack agent (the Slack integration must be connected).