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

# Access governance

> How requests, approvals, fulfillment, and grants fit together in Flow.

Flow keeps access requests, approval decisions, and the resulting access records together.
Use this guide to follow access from the first request through review and removal.

## Follow access from request to removal

| Stage | What happens | Where to go |
| - | - | - |
| Request | An employee names the application, recipient, and duration they need. | [Request and approve access](/setup/access) |
| Check and approve | Flow checks who can request the service and receive access. An eligible approver decides when required. | [Access rules](#understand-access-rules) and [Approvals](/setup/approvals) |
| Provide access | The configured automation changes the connected application and records a grant. | [Provisioning and grants](/setup/access-management/provisioning) |
| Review access | An assigned reviewer decides whether to keep, remove, or defer a decision on active grants. | [Access reviews](/setup/access-management/access-reviews) |
| Remove access | An administrator removes access in the connected application, then updates the grant record in Flow. | [Revoke a grant](/setup/access-management/provisioning#revoke-a-grant) |

A grant is Flow's record of access given to someone. The connected application determines the
access that person actually has. Approval alone does not confirm that the application changed.

Manage grant records and access reviews with the
[Flow command-line interface (CLI)](/setup/cli), a tool for running typed commands.
Ask an administrator to help with these steps if you do not use the CLI.
Revoke commands record the removal after you remove access in the connected application.

## Understand access rules

An access service can limit who can request it, who can receive access, and how long access lasts.
These checks serve different purposes:

| Rule | What Flow checks | Example |
| - | - | - |
| Published audience | Whether the requester can use the service | A service is available to selected teams. |
| Recipient eligibility | For access limited to a team, whether the recipient has an allowed team role | A profile limits access to team managers. |
| Maximum duration | Whether the requested duration fits the access policy | A policy allows access for up to 1 day. |
| Approval | Whether the required person approves the request | A manager must approve before access can be provided. |

An access profile describes who is eligible for the access. The linked access policy sets the
maximum duration and the approval and fulfillment requirements for the access service.

## Request access

<Steps>
  <Step title="Ask for access.">
    Tell Flow what access you need on **Home** or through a [connected channel](/setup/access).
  </Step>

  <Step title="Name the recipient.">
    Include the recipient when requesting for someone else.
  </Step>

  <Step title="Answer follow-up questions.">
    Answer any questions about justification, duration, or resource.
  </Step>

  <Step title="Track the outcome.">
    Follow the conversation for updates.
  </Step>
</Steps>

## Approve access

<Steps>
  <Step title="Open the approval.">
    Select **My approvals** on Home or the related conversation.
  </Step>

  <Step title="Review the details.">
    Review the recipient, application, justification, duration, and earlier decisions before
    approving or rejecting the request.
  </Step>

  <Step title="Decide.">
    Approve or reject the request. Under **My approvals**, the action is labeled **Reject** when
    you are an approver for the stage. It is labeled **Deny** when you decide as an organization
    administrator. The conversation header always shows **Deny**. All of these record the same
    rejected decision.
  </Step>

  <Step title="Confirm fulfillment.">
    Approval allows fulfillment to continue. Check the related automation run to confirm that the
    connected application accepted the change.
  </Step>
</Steps>

## Records

| Record | Purpose |
| - | - |
| **Access request** | Tracks the business request |
| **Approval request** | Records the decision |
| **Automation run** | Performs fulfillment |
| **Access grant** | Tracks the resulting access |
| **Conversation** | Keeps requester and operator communication together |

## Related topics

* [Provisioning and grants](/setup/access-management/provisioning)
* [Access reviews](/setup/access-management/access-reviews)
* [Approvals](/setup/approvals)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.