> ## Documentation Index
> Fetch the complete documentation index at: https://docs.accessowl.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How Time-based Access Works

Once an application has [time-based access configured](/guides/time-based-access/setup), 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](/guides/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](/guides/requests/approval-policies) applies, and provisioning happens the same way — automatically for apps with an integration, or via the application admin otherwise.

<Info>
  If an app only offers **Unlimited**, no duration step appears. Users see the normal request form.
</Info>

### 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:

<Tabs>
  <Tab title="User had no access before">
    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.
  </Tab>

  <Tab title="User had access before">
    The access is **reduced** back to the permissions the user held before the temporary grant. AccessOwl creates this as an access request on the user's behalf; it skips approval and goes straight to provisioning.

    This is the case that matters for elevated access: someone with read access who temporarily gets admin lands back on read access, not on nothing.
  </Tab>
</Tabs>

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](/guides/requests/access-requests#revoke-your-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.

| What changed                                                                                                                 | What AccessOwl does                                                                                                                |
| ---------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| **The temporary permissions are still in place** (multi-select resource, other permissions were added or removed)            | The grant keeps running and is rolled back as planned at expiry.                                                                   |
| **The previous state can no longer be restored** (single-select resource changed, or the temporary permissions were removed) | The time-based access is closed right away and the application's admins are notified. Nothing happens at the original expiry time. |
| **The access was already removed**                                                                                           | Same: closed right away, admins notified.                                                                                          |
| **The user was deactivated**                                                                                                 | Same: closed right away, admins notified. [Offboarding](/guides/onboarding-offboarding/offboarding) handles their access.          |

In all of these cases the access itself is left untouched.

<Warning>
  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.
</Warning>

## 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](/guides/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

<AccordionGroup>
  <Accordion title="Can I change the duration after a request was submitted?">
    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.
  </Accordion>

  <Accordion title="Can I extend a time-based access before it expires?">
    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.
  </Accordion>

  <Accordion title="What if the user already had exactly the permissions they requested?">
    Then nothing was actually granted, and no expiry is scheduled. The user keeps the access they already had.
  </Accordion>

  <Accordion title="What happens if the duration runs out while the request is still pending?">
    Nothing — the clock only starts once the access exists. A pending or unapproved request has no expiry attached to it yet.
  </Accordion>

  <Accordion title="Does the API support time-based access?">
    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.
  </Accordion>
</AccordionGroup>