Give employees exactly the access they need—for exactly as long as they need it, and no longer.

Temporary Access Requests let employees request time-bound access to applications directly through Torii Access Requests. You define which durations are allowed, and once a request is approved Torii provisions the access, tracks it until it expires, and then automatically revokes it—no manual follow-up required.

This article walks you through setting up temporary access, what your employees will see when they request it, and how to monitor and troubleshoot active grants.

How it works

Every temporary access request moves through the same lifecycle:

1. Request — an employee requests access under a policy that allows temporary access and picks a duration.
2. Approval — the request goes through your normal approval flow.
3. Provisioning — once approved, your provisioning workflow grants access and Torii starts the expiration timer.
4. Pending revocation — access is active while the timer runs.
5. Revoking — when the timer expires, Torii runs the deprovisioning workflow.
6. Access revoked — access is removed and the request closes (or is flagged if revocation fails).

Setting up temporary access

Setup has two steps: set your global duration defaults and confirm the deprovisioning workflow that will revoke access. Optionally, you can customize the durations for a specific policy.

Step 1 — Set your global duration defaults

Start by defining the durations employees can choose across your organization. Every policy that uses the default settings inherits these, so you only configure them once—and temporary access is available on those policies right away.

Go to App Catalog Settings → Access duration and set:

• Access duration options — choose whether employees can request Permanent access, Temporary access, or both. Both are enabled by default.
• Allowed durations — the preset durations employees can pick from. Torii provides 3 hours, 1 day, 7 days, and 30 days—you can remove these or add your own.
• Allow employees to request a duration not in this list — leave this on to let employees enter a custom duration, or turn it off to restrict them to the presets.

When you change these settings, Torii asks you to apply or discard the changes. Any policy set to Use defaults will update automatically.

Step 2 — Confirm the deprovisioning workflow

The deprovisioning workflow is what removes access when the timer runs out. Torii now separates workflows into two types:

• Provisioning — grants access (the workflow type you already use).
• Deprovisioning — revokes access when temporary access expires.

You'll find both under App Catalog → Access workflows, where a Type column labels each one. Deprovisioning workflows run automatically on the Temporary access expired trigger.

Every organization starts with a default deprovisioning workflow that creates a Revoke access task for the app owner:

• Assigned to: App owner
• Title: Revoking access – [App name]
• Message: Temporary access has expired for [First name] [Last name] ([Email]). Please revoke access to [App name] and mark this task as done.

To create your own, click New workflow in the Access workflows tab and choose Deprovisioning workflow. The builder starts from the default (including the Revoke task), and you can add more actions or conditions as needed.

Optional — Customize durations for a specific policy

Most policies can simply use your global defaults. But if a particular access request policy needs different duration options—for example, shorter durations for a highly privileged app—you can override the defaults on that policy.

On the Access Request Policies page, open the policy and:

1. Under Access Duration  → Choose Custom options 
2. Select Permanent/temporary/both access, Under allowed durations - set the durations for this policy. 
3. Set the deprovisioning workflow —user the default or create a custom deprovisioning workflow

The policies table shows a Temporary access enabled column and a Deprovisioning method column so you can confirm each policy's setup at a glance.

Optional — Create a custom deprovisioning workflow

When a temporary access period expires, Torii runs a deprovisioning workflow to automatically remove or reduce the access that was granted—so no one holds access longer than intended, without IT having to remember to step in.

Every policy that allows temporary access uses a deprovisioning workflow. By default it uses the default deprovisioning workflow, but you can create a custom deprovisioning workflow when a specific policy needs different behavior on expiry.

When to use a custom deprovisioning workflow

Use a custom deprovisioning workflow when the default action isn't the right outcome for that app or access type—for example, when you want to:

• Downgrade instead of fully remove access (e.g., move from Zoom Pro back to Zoom Basic)
• Remove a specific license or role rather than revoking the account entirely
• Remove the user from a group that grants the elevated permission
• Open a ticket for apps Torii doesn't deprovision directly
• Notify the user, their manager, or the app owner when access is removed

How to create and assign it

On the Access Request Policies page, open the policy and:

1. Under Access Duration, make sure temporary access is enabled (see customizing durations above).
2. Under Deprovisioning workflow, choose Create custom deprovisioning workflow (or select an existing one).
3. Build the workflow with the action(s) that should run when the access period ends—for example, remove or downgrade the license, remove the user from a group, or open a ticket. You can add branches and conditions just like any other Torii workflow.
4. Save.

The workflow now runs automatically whenever a temporary grant under this policy expires.

Tip: The policies table shows a Deprovisioning workflow column, so you can confirm at a glance which policies use the default and which use a custom deprovisioning workflow.

What employees see

When a policy has temporary access enabled, the request experience changes for your employees:

1. They open Request Access and select the app or access profile.
2. They see the option to request temporary access and choose one of your allowed durations (or enter a custom duration, if you allow it).
3. They submit the request, which is clearly marked as temporary.

When their access is later revoked, they're notified automatically by email and Slack/Teams, with a note that they can submit a new request if they still need access.

Tracking active temporary access

Follow a request through its statuses

Temporary requests use these statuses so you can see where each one is:

Use the Active Temporary Access view

For a live picture of everything currently granted, go to the Requests page → Active Temporary Access tab. It lists every request that is Pending revocation, Revoking, or Revocation failed, with columns for:

• User, App, and Access (the requested access profile)
• Granted on and Expires at
• Time remaining — a friendly countdown (for example, "less than an hour", "3 days", "1 week and 2 days")
• Status

You can sort by any column (Expires at, ascending, by default), filter by App, User, or Status, and search by user or app name.

When a revocation fails

If a deprovisioning workflow fails, the request moves to Revocation failed and Torii surfaces it so you can act:

• You'll receive an error alert (managed from the Error alerts card in App Catalog Settings) and, in Slack, a 🚩 Temporary access revocation failed message with the failure details and a link to the request.
• Open the request to see an info link to the workflow execution, then click Mark as completed once you've revoked access manually. This moves the request to Access revoked, closes it, and notifies the requester.
• Note: stopping a deprovisioning workflow marks the request as Revocation failed (unlike stopping a provisioning workflow, which cancels the request).