> For the complete documentation index, see [llms.txt](https://www.cakewalk.security/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.cakewalk.security/docs/human-access/how-to-guides/time-based-access.md). # Time-Based Access Request an app or a permission level for a set time, and Cakewalk removes the access or reverts the level when the time is up. Time-Based Access lets people request an app, or a higher permission level, for as long as they need it. When the time is up, Cakewalk starts the removal itself, so nobody has to remember the end date. ### 👥 **Who It Applies To** | Role | Capabilities | | ------------- | ------------------------------------------------------------------------------------------ | | **Users** | Request access to an app, or a permission level, for a set time. | | **Approvers** | See the requested duration on the review task and shorten it before approving. | | **Admins** | See which users hold temporary access and when it ends, on the user and app access tables. | *** ### 📖 Key Concepts * **Temporary access**: access to an app that ends after the approved duration. * **Temporary elevation**: a permission level that reverts to the previous level after the approved duration. The access to the app stays. * **Duration**: a whole number of days, weeks or months, chosen when the request is made. * **End of the period**: Cakewalk creates the request that ends the access or reverts the level. It runs through the app's [policy](/docs/human-access/how-to-guides/policies.md) like any other request, so Agent Cake carries it out where auto provisioning is set up, and the assignee gets an action task everywhere else. * **App Owners**: an App Owner always holds permanent access to the apps they own. A user with temporary access to an app cannot be made its App Owner. :bulb: *Why this matters*: Contractors, project work and single admin tasks need access for a known period. Recording the end date up front means the access goes away on its own, instead of waiting for an access review to find it. *** ### 🛠 Time-Based Access Workflows #### Request Temporary Access * **Definition**: Grants an app for a set duration. * **Navigation**: Go to the App Catalog → Click *Get* on the desired app. Under *How long do you need it?*, select *Temporary* and enter the duration in *Day(s)*, *Week(s)* or *Month(s)*. Provide justification. * **Why this matters**: The requester knows how long they need the app. Capturing it in the request means the end date is never lost. *** #### Request a Temporary Permission Level * **Definition**: Raises a user's permission level for a set duration, then reverts it to the previous level. * **Navigation**: Go to *My Apps* → Select app → *Change my permissions*. Select the new permission level, then under *How long do you need it?*, select *Temporary* and enter the duration. * **When Temporary is not available**: while your access or your current permission is waiting for the app to confirm it, and while your current permission is already temporary. The page says which one applies. * **Why this matters**: Admin rights for a single task do not have to become standing admin rights. *** #### Approve a Temporary Request * **Definition**: Review tasks for temporary requests show the *Requested duration* next to the usual request details. * **Steps**: 1. Open the review task. 2. To grant less time than requested, edit the duration before approving. The new duration can be shorter than the requested one, never longer. 3. Select *Approve*. The request then shows the *Approved duration* and the date the access *Expires on*. * **Access from onboarding or a user group**: this access is permanent, so approvers cannot set a duration for it. * **Why this matters**: Approvers keep control over how long access lasts, not only whether it is granted. *** #### When the Time Is Up * **Temporary access**: shortly after the period ends, Cakewalk creates a [Remove Access](/docs/human-access/how-to-guides/requests.md#remove-access) request for the user, which runs through the app's removal policy. * **Temporary elevation**: shortly after the period ends, Cakewalk creates a [Change Permissions](/docs/human-access/how-to-guides/requests.md#change-permissions) request that sets the permission level back to the previous one, which runs through the app's policy. * **Why this matters**: The end date turns into a real removal without anyone tracking a calendar. *** #### See Who Holds Temporary Access * **Navigation**: * For a user: *User overview* → select user → *Access* table. * For an app: App Governance table → Click into an app → *Users* table. * **Visibility**: The *Expires* column shows the date temporary access ends, or *Permanent*. Sort by it, or filter it by date. Filter by *Access duration* to list only permanent or only temporary access. Temporary access carries an icon; hover over it to see how much time is left. * **Auditing**: Changes to an end date are recorded in the audit log. *** #### Temporary Access and User Groups * **Definition**: When a user with temporary access joins a group that includes the same app, or their group adds that app as a default, the admin's choice decides what happens to the end date. * **Create requests** or **Add access as admin action**: the access becomes permanent. Cakewalk cancels the pending removal and any open temporary request for that app. * **Leave access unchanged**: the access stays temporary and ends as planned. On apps provisioned through your company's identity provider, the access becomes permanent. * **Temporary permission levels** are not affected. They still revert on their date. * **Why this matters**: Group access is permanent by design. Leave access unchanged when the end date should still apply. *** ### 📋 Time-Based Access Actions at a Glance | Action | Who performs it | What happens | Why it matters | | ---------------------------------- | --------------- | ------------------------------------------------------------------------ | ----------------------------------------------------- | | **Request Temporary Access** | Everyone | Request an app for a set duration. Routed per policy. | Access lasts as long as the work, not longer. | | **Request a Temporary Permission** | Everyone | Request a higher permission level for a set duration. | Elevated rights do not become standing rights. | | **Shorten a Duration** | Approvers | Approve a shorter duration than requested. | Approvers decide how long, not only whether. | | **End of the Period** | Cakewalk | Creates the removal or the permission change back, routed per policy. | Nobody has to remember the end date. | | **Review Temporary Access** | Admins | See temporary access and its end date in the user and app access tables. | Shows what will end on its own and what is permanent. | *** ### 🤖 With Agent Access Agent Access can be requested for a set time like any other app. When the time is up, its removal also revokes the Connections the person holds. See [How They Connect](https://www.cakewalk.security/docs/human-access-and-agent-access/how-human-access-and-agent-access-connect). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://www.cakewalk.security/docs/human-access/how-to-guides/time-based-access.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.