Skip to main content
Once an application has time-based access configured, requests to it can carry a duration. This page covers the full lifecycle: how users request a time-boxed grant, what AccessOwl does when it expires, and how to keep track of it.

​
Requesting a duration

When an application offers more than just Unlimited, the request form gains a Duration step. This works the same in Slack and in the App Hub. The user picks a duration alongside the app, the permissions and the reason. Everything else about the request is unchanged: the same approval policy applies, and provisioning happens the same way — automatically for apps with an integration, or via the application admin otherwise.
If an app only offers Unlimited, no duration step appears. Users see the normal request form.

​
When the clock starts

The countdown starts when the access is actually granted — not when the request is submitted or approved. A 4-hour access that waits two days for an application admin to provision it still gives the user a full 4 hours from the moment it gets granted.

​
One time-based access at a time

A user can only have one running time-based access per resource. If they already have a time-boxed grant for a resource, requesting another one with a duration is rejected, with a message asking them to resubmit without a duration. They can still request Unlimited access to the same resource — that’s how a temporary grant gets converted into a permanent one.

​
What happens at expiry

AccessOwl checks for ended grants continuously and acts within about a minute of the window closing. What it does depends on what the user had before the temporary grant:
The access is removed. AccessOwl creates a revocation with the reason “Time-based access ended” — deprovisioning automatically if the app has an integration, or notifying the application admin to remove it.
For resources where multiple permissions can be selected, only the permissions the temporary request added are taken away. Permissions the user gained in the meantime through other requests are kept. Permissions that were deleted from the app’s structure in the meantime are skipped — AccessOwl won’t try to reinstate a permission that no longer exists.

​
Notifications

The user and their manager are notified in Slack when a time-based access expires, and told whether the access was removed entirely or reduced back to the user’s previous permissions. Users who finish early don’t have to wait for the timer. They can revoke their own access from the Slack home tab at any point.

​
When the access changes before expiry

AccessOwl re-evaluates a running time-based grant as soon as the user’s access to that resource changes, whether someone edited the permissions directly, an integration sync brought in a change, or the access was removed. It does not wait for the expiry to find out. In all of these cases the access itself is left untouched.
When the permissions were changed, the user may still hold the elevated permission. The Slack notification to the application’s admins names the cause and asks them to review whether the user should keep it. This is the one situation where time-based access needs a human to close the loop.

​
Tracking time-based access

Time-boxed grants are marked as such wherever access is listed, together with when they expire:
  • My Requests in the App Hub, for a user’s own accesses
  • The application’s access list, for admins
  • Access reviews, so reviewers can see a permission is already set to expire and don’t need to act on it
  • CSV exports of access requests and revocations, which include the duration and expiry columns
Both the original request and the automatic rollback appear in the request history, giving a full audit trail of when access was elevated and when it was taken back.

​
FAQ

No. The duration is fixed when the request is created. To change it, revoke the access and submit a new request with the duration you want.
Not directly. Submit a new request for the same resource with Unlimited to make the access permanent, or wait for the current grant to expire and request a new time-boxed one.
Then nothing was actually granted, and no expiry is scheduled. The user keeps the access they already had.
Nothing — the clock only starts once the access exists. A pending or unapproved request has no expiry attached to it yet.
Access requests returned by the API include duration (an ISO 8601 duration such as PT1H or P7D) and expires_at, and applications expose their configured time_based_access_durations in the same format. Creating a time-based request through the API is not supported — use Slack or the App Hub.
Last modified on September 14, 2026