# Requests

### 👥 **Who It Applies To**

| Role           | Capabilities                                                                                                                |
| -------------- | --------------------------------------------------------------------------------------------------------------------------- |
| **Users**      | Request access, request permission changes, request new apps, cancel/remove requests.                                       |
| **Managers**   | Approve or deny requests from their team (first step in standard policy). Can also submit requests on behalf of their team. |
| **App Owners** | Approve or deny requests for apps they own (final step in standard policy).                                                 |
| **Admins**     | Monitor all requests in logs, reassign tasks, customize policies, override with top-down actions.                           |

***

### 📖 Key Concepts

* **Requests**: Foundation of access governance in Cakewalk. They route changes (access, permissions, removals, new apps) through the right approvals before execution.
* **Tasks**: Every request is broken down into [tasks](/how-to-guides/tasks.md):
  * **Review tasks** → approvers approve/decline.
  * **Action tasks** → assignee or Agent Cake executes the change.
* **Request Types**: Five supported in Cakewalk:
  * Grant access
  * Change permissions
  * Remove access
  * Add new app
  * Archive app
* **Policies**: Each request follows the policy assigned at global, app, or permission level.
* **Reference**: See [Policy, Request and Task Data Model](/concepts/data-models/policy-request-and-task-data-model.md#requests) for details on how requests connect to policies and tasks for full auditability.

:bulb:*Why this matters*: Requests ensure changes to app access are auditable, governed and aligned with least-privilege principles.

***

### 🛠 Request Workflows

#### Grant Access

* **Definition**: Assigns an app to a user for the first time.
* **Slack**: Open the Cakewalk app and start a conversation.
  * Example: *”I need access to Figma”*
  * The assistant confirms the permission level, asks for a reason and creates the request.
  * Request on behalf of someone (managers and admins): *”Request Figma for @alex”*
  * **Bulk requests**: *”I need Miro, Jira and Notion”*. The assistant handles all three in one thread.
* **Navigation**: Go to the App Catalog → Click *Get* on the desired app and provide justification.
* **Why this matters**: Enables self-serve access without IT tickets or delays, while ensuring oversight.

***

#### Change Permissions

* **Definition**: Modifies the permission level of a user’s existing app access.
* **Slack**: Open the Cakewalk app and describe the change.
  * Example: *"Change my Salesforce access to Reports"*
  * The assistant confirms the current and new permission levels, asks for a reason and creates the request.
* **Navigation**: Go to *My Apps* → Select app → *Change my permissions*. Provide justification.
* **Why this matters**: Allows users to adapt access when roles change, while keeping permission changes governed.

***

#### Remove Access

* **Definition**: Revokes a user’s app access, either voluntarily or triggered by offboarding/review.
* **Slack**: Open the Cakewalk app and ask for the removal.
  * Example: *"Remove my access to Looker"*
  * The assistant validates your current access, asks for a reason and submits the request.
* **Navigation**: Go to *My Apps* → Select app → *Remove my access*.
* **Why this matters**: Lets employees clean up their own access, reducing unused entitlements and risk.

***

#### Add New App

* **Definition**: Proposes a new app to be added to the governed catalog.
* **Slack**: In Cakewalk app, select *Request new app*.
* **Navigation**: App Catalog → *+ New App*. Provide justification and additional metadata (team, use case, urgency) if required.
* **Why this matters**: Expands the official app catalog in a controlled way, reducing shadow IT.

***

#### Archive App

* **Definition**: Retires an app no longer needed while keeping historical request logs.
* **Navigation**: App Governance table → Select an app → *Archive app*.
* **Why this matters**: Keeps the catalog current, reduces spend, and prevents stale risk while preserving audit history.

***

#### Managing Requests

* **Users**: Track requests under *My Requests* in the web app or ask in Slack: *"What's happening with my Datadog request?"* The assistant returns the current state and who needs to act next.
* **Reminders**: Ask the assistant to nudge your approver: *"Remind my approver about my pending request."* A Slack message is sent to the person blocking your request.
* **Assignees**: Complete approvals in Slack or Cakewalk based on policy.
* **Admins**: Monitor all request logs across the org.
* **Cancel a request**: Pending requests can be canceled in the *Request log* before approval.

***

### 📋 Request Actions at a Glance

| Action                 | Who performs it    | What happens                                              | Why it matters                                          |
| ---------------------- | ------------------ | --------------------------------------------------------- | ------------------------------------------------------- |
| **Grant Access**       | Everyone           | Request access to an app. Routed per policy.              | Enables self-serve access with proper governance.       |
| **Change Permissions** | Everyone           | Request to change permission level for an app.            | Keeps permissions aligned to role needs while governed. |
| **Remove Access**      | Everyone           | Request to revoke own access to an app.                   | Reduces dormant accounts and enforces least-privilege.  |
| **Add New App**        | Everyone           | Request to introduce a new app into the catalog.          | Expands catalog securely, reducing shadow IT.           |
| **Archive App**        | Admins, App Owners | Request to retire an app. App is archived; logs retained. | Keeps catalog clean while preserving audit trail.       |
| **Track Requests**     | Everyone           | Monitor request progress in Slack or web app.             | Ensures visibility and accountability.                  |
| **Cancel Request**     | Requester, Admins  | Cancel pending requests before approval.                  | Provides control and prevents unnecessary changes.      |


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.getcakewalk.io/how-to-guides/requests.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.
