> ## Documentation Index > Fetch the complete documentation index at: https://docs.coderabbit.ai/llms.txt > Use this file to discover all available pages before exploring further. # Seat assignment > Learn how to request and approve review seats and manage automatic and manual seat assignment. export const AdminRoleBadge = ({tip = "This feature requires an organization owner, an admin role or the corresponding permission. Regular Members do not have access.", title = "Admin Only", cta = "View roles", href = "/management/roles", disabled = false}) => { return {title} ; }; CodeRabbit ingests users from your git provider (GitHub, GitLab, Bitbucket, and Azure DevOps) and assigns seats based on your organization's active seat assignment mode. Understanding these modes helps you control who gets access to CodeRabbit reviews and how billing is affected. Team Management is open to Admins only. Billing Admins and Members cannot assign or unassign seats. Admins and Billing Admins can buy Enterprise capacity from **Account → Billing** using **Add seats**. Billing Admins cannot be assigned seats themselves and do not consume your allocation. See [Enterprise seat true-up](/management/enterprise-seat-true-up) for the confirmation and billing details. ## Seat assignment methods ### Trial mode This mode is only active during the trial. In trial mode, users are automatically provisioned with a seat when they raise a PR in a repository where CodeRabbit is installed. During an eligible primary trial, pushing new commits to an existing PR can also assign an available trial seat to a human author. This does not add seats to the subscription or assign seats to bots. Manual assignment restrictions still apply. To prevent users from getting a seat, you can filter them out using the `ignore_usernames` filter. After the trial ends, organizations automatically transition to manual approval mode. ### Manual approval In this mode, admins can continue assigning seats directly from **Team Management**, or **Workspace Team Management** for Enterprise SSO workspaces. A developer does not need to submit a request first. Developer requests provide an additional way to ask for a seat. Eligible users without a seat can [request a review seat](#request-a-review-seat) from the free summary on their private-repository PRs. Public and open-source PRs do not show this request action. Use the `enable_free_tier` configuration setting to disable free tier reviews for users without paid seats. ### Auto-approval In this mode, users are automatically provisioned seats when they raise a PR in a repository where CodeRabbit is installed. For paid subscriptions, automatic assignment is triggered only when a user opens a pull request. Pushing new commits (a synchronize event) to an existing pull request does not assign a seat, so an unseated author remains unseated until they open a new pull request or an administrator assigns one. The available-seat exception during a trial is described in [Trial mode](#trial-mode). Newly provisioned users can open a new pull request to trigger automatic assignment. Other users should ask an administrator to assign a seat from [Team Management](#managing-seat-assignments). If there is an existing user with a seat who has not raised a CodeRabbit pull request in the last 30 days, that seat is reallocated to the new user. If all seats are taken, CodeRabbit can provision a new license and charge a prorated amount for supported non-Enterprise subscriptions. Enterprise automatic assignment remains capped at the purchased seat count until an Admin or Billing Admin explicitly increases capacity. See [Enterprise seat true-up](/management/enterprise-seat-true-up). To prevent users from getting a seat, you can filter them out using the `ignore_usernames` filter. ## Request a review seat In CodeRabbit Cloud, you can request a seat when your selected organization uses manual seat assignment, your membership is eligible for a seat, and you do not already have one. The organization must have an active paid subscription, including a subscription scheduled to cancel at the end of its current term. Requests are unavailable during trials, after the subscription ends, or while automatic seat assignment is enabled. ### Request from a pull request On an eligible **private-repository PR**, the free-summary notice identifies the author who needs a seat. On GitHub, select **Request a review seat for @author**. The request is always for the PR author, even if another person selects the checkbox. On GitLab, Bitbucket, and Azure DevOps, use the **Request a review seat** link to open CodeRabbit. Sign in as the developer who needs the seat and check the selected organization before submitting the request. The GitHub notice also includes an **Open in CodeRabbit** link. Public and open-source PRs do not display a seat-request checkbox or link. If a request fails, the GitHub checkbox remains available to try again. ### Request from the web app 1. Sign in to [CodeRabbit](https://app.coderabbit.ai) and select the organization where you need a seat. 2. In the developer sidebar, under **Reviews**, select **Request a review seat**. 3. Check the organization name in the dialog, then select **Request a review seat** to notify its administrators. The sidebar action is shown only when you are eligible to request a seat in that organization. While a request is pending, its label becomes **Seat request pending**. It disappears after a seat is assigned. ### Pending requests and reminders After submitting, the dialog shows **Seat request pending**, your last request date, and when you can request again. Requests remain pending until a seat is assigned. Submitting again within seven days returns the same pending request without sending another notification. After seven days, select **Request again** to notify administrators again without creating a duplicate request. CodeRabbit also schedules one reminder after three weekdays from the initial request, calculated in UTC and skipping weekends but not holidays, if the request remains pending and eligible. Requesting again does not restart this reminder. Notifications go to the organization's recorded CodeRabbit admins, billing admins, applicable workspace admins, and current billing contact. If no admins are recorded, CodeRabbit uses the billing contact when available. Saving a request does not guarantee that an email has reached an inbox; admins can also find pending requests in Team Management. ### Approve a seat request 1. Open **Team Management** and select the **Seat requests** tab. Its badge shows the pending count. 2. Open a request to review the developer, person who requested the seat, organization, request dates, and source PR when available. 3. Select **Approve**. If another paid seat is needed, review the estimated cost, currency, seat quantity, proration, and billing timing before confirming. An available seat can be assigned without an additional charge. For an eligible Enterprise organization, approval can increase paid capacity through quarterly true-up billing. Review [Enterprise seat true-up](/management/enterprise-seat-true-up) before confirming the billable seat change. The **Review seat request** link in an email opens the request in the correct organization after sign-in. Opening the link does not assign a seat. Approval requires existing seat-management permission; receiving an email as the billing contact does not grant that permission. If pricing or seat quantity changes, refresh and confirm the updated estimate. When your purchasing arrangement does not support adding seats through the app, follow the purchasing instructions shown. Ineligible requests remain visible with approval unavailable. Admins can also assign the seat directly using the existing seat-management controls instead of approving it from this tab. Direct assignment fulfills the matching pending request. Approval does not automatically start a review on the original PR. Request a review through the [PR commands](/guides/commands) after the seat is assigned. ## Managing seat assignments To change your seat assignment mode, navigate to **Team Management** in the CodeRabbit dashboard and click the settings icon next to **Invite Billing Admin**. From this menu, you can switch between auto-approval and manual approval modes. Click **Confirm** to save your changes. Seat assignment settings showing auto-approval and manual approval options Enterprise customers can assign custom roles in addition to the built-in Admin, Member, and Billing Admin roles. For details on creating and managing custom roles, see [Custom roles and permissions](/management/custom-roles). ### Enterprise SSO workspaces Enterprise SSO workspaces manage seats from **Workspace Team Management**. Open the seat assignment settings to switch between **Automatic** and **Manual** modes. In **Automatic** mode, a member is assigned a seat when they open a pull request while purchased seat capacity remains. Once all purchased seats are in use, CodeRabbit does not increase the subscription's seat count automatically, and the pull request author is treated as ineligible for the normal review flow. Automatic seat assignment resumes after seat capacity is freed, such as through reallocation, or an Admin or Billing Admin explicitly [increases the purchased seat count](/management/enterprise-seat-true-up#choose-how-to-add-seats). #### How Enterprise SSO seats are counted Every pull request author is identified by a **Git identity**, such as a GitHub username, GitLab username, Bitbucket account, or Azure DevOps identity. That Git identity must be covered by a seat to receive paid PR reviews. In **Workspace Team Management**, CodeRabbit assigns the seat to a member entry. A member entry can be: * An **IdP member**: A person who signed in through SSO or was provisioned from your identity provider through SCIM. * A **Git-only member**: An entry created for a Git identity that has pull request activity but is not yet linked to an IdP member. A seat on either type of member entry covers all Git identities linked to it. The same Git identity can receive reviews across every organization or group for the same Git provider and provider instance in the workspace without another seat. | Scenario | Seats consumed | | - | - | | One GitHub Cloud username in ten GitHub organizations | One | | One GitLab.com username in multiple GitLab groups | One | | The same person contributing through GitHub and GitLab while the identities are on separate member entries | Two | | The same person using GitHub Cloud and GitHub Enterprise Server while the identities are on separate member entries | Two | | The same person using two GitHub Enterprise Server instances while the identities are on separate member entries | Two | | Multiple Git identities linked to one IdP member | One | When estimating seats, count each separate Git identity unless you know that the identities will be linked to the same IdP member. CodeRabbit does not automatically combine Git identities across providers. Git providers do not expose a shared, stable identifier that reliably links a GitHub username, GitLab username, Azure DevOps identity, or self-hosted account to the same person. Email and SAML attributes can differ between providers or may not be available, especially for self-hosted instances. Enterprise SSO workspaces use one CodeRabbit subscription across the workspace. Adding another organization for an already linked Git identity on the same provider instance does not require another seat. #### How IdP members, Git identities, and seats relate The Git identity that opens a pull request determines who needs review access. The member entry that contains that Git identity determines where CodeRabbit assigns the seat. * If the Git identity is linked to an **IdP member**, the seat is assigned to that IdP member and covers every Git identity linked to the member. * If the Git identity is not linked to an IdP member, CodeRabbit represents it as a **Git-only member**. That entry can receive a seat so the Git identity can receive paid PR reviews. In **Manual** mode, admins assign seats to IdP members or Git-only members from **Workspace Team Management**. In **Automatic** mode, when a Git identity opens a pull request, CodeRabbit finds the member entry that contains it and assigns a seat if needed. If the identity has not been linked to an IdP member, CodeRabbit creates or uses its Git-only member entry. Admins can link Git identities to an IdP member through **Workspace Team Management** by selecting the member and using **Edit member links**. The same links can be managed with the [User Management API](/api-reference/users-manage-seats). Linking identities that were on separate member entries consolidates them under the IdP member. One seat then covers all of the linked Git identities, and any duplicate seat is freed. An IdP member provisioned through SCIM initially appears in **Workspace Team Management** without a seat. SCIM does not automatically link existing Git identities to the new member. An admin must link the appropriate identities through the UI or API. When an IdP member is removed through SCIM, CodeRabbit removes the member, their linked Git identities, and their seat from **Workspace Team Management**. If one of those Git identities opens a pull request later, it reappears as a Git-only member and follows the workspace's current seat assignment mode. #### Choose a seat assignment mode In **Automatic** mode, CodeRabbit assigns a seat to the member entry containing a Git identity when that identity opens a pull request, up to the purchased seat count. If all seats are taken, an Admin or Billing Admin must explicitly [buy more capacity](/management/enterprise-seat-true-up#buying-seats-ahead-of-time) before automatic assignment can use additional seats. In **Manual** mode, admins assign seats to IdP members or Git-only members individually from **Workspace Team Management**. Individual seat assignment controls are disabled while Automatic mode is on. **Workspace Team Management** does not assign consumed seats to billing admins. If a billing admin already has a seat, admins can still unassign it. For role-editing details, see [Workspace roles](/management/sso#workspace-roles). ## Pending unassignment When you unassign a seat from a user on a standard monthly paid subscription, the seat is marked as "Pending unassignment" and stays active until the end of the billing cycle. Enterprise true-up seats are released for reuse when unassigned, while their contracted quantity and charges remain unchanged. ### How "Pending unassignment" works * **Delayed unassignment**: When you unassign a seat from a standard monthly subscriber, it remains active until the end of your current billing cycle * **Continued access**: Users with "Pending unassignment" seats retain full CodeRabbit access until the billing cycle ends * **Automatic cleanup**: At the end of the billing cycle, all "Pending unassignment" seats are automatically unassigned, and the users will lose the seat This "Pending unassignment" behavior applies only to standard monthly paid subscriptions. Annual subscriptions and Enterprise true-up seats are excluded. ### Billing implications "Pending unassignment" seats are still counted as active seats for billing purposes during the current cycle. You will continue to be charged for these seats until they are automatically unassigned at the end of your billing period. For seats added through Enterprise true-up, **Unassign** releases the seat for another teammate. It does not reduce the contracted seat count, reverse the prorated charge, or end the commitment through the current contract term. Contact your Customer Success Manager to discuss a reduction. See [Unassign a true-up seat](/management/enterprise-seat-true-up#unassign-a-seat). This approach ensures you get full value from your subscription while giving you the flexibility to adjust your team composition as needed. ## Troubleshooting ### Existing users having their seats removed When auto-approval mode is enabled, users have their seats reassigned if they have not raised a PR in the last 30 days and a new user without a seat opens a PR. ### New users in auto-approval mode getting new licenses despite open seats This is likely due to bot users or external users that have seats. These users are displayed separately from regular git provider organization members. ### Users without seats still receiving CodeRabbit reviews on their PRs Users without paid seats to CodeRabbit still receive free-tier CodeRabbit reviews unless the `enable_free_tier` setting is disabled. ### Why does a user still have access after I unassigned their seat? For standard monthly paid subscriptions, unassigned seats are marked as "Pending unassignment" and remain active until the end of the current billing cycle. This means users retain full CodeRabbit access during this period. See the [Pending unassignment](#pending-unassignment) section for more details on this behavior. ### When will a "Pending unassignment" seat become available for reassignment? "Pending unassignment" seats are automatically unassigned at the end of your billing cycle. Once the billing cycle ends, the seat becomes fully available for reassignment to a new user. Until then, the seat remains allocated to the original user. ## What's next Access billing history, change plans, and adjust seats Control who can access CodeRabbit and manage administrative settings This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.