> For the complete documentation index, see [llms.txt](https://help.transform.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.transform.ai/organizations-and-projects/teammate-access-requests.md).
# Teammate Access Requests
Ask for a teammate to be added to or removed from an Organization or Project, and approve or reject those requests.
{% columns %}
{% column %}
**What is covered**
* Request access for a new person or an existing contact
* Request a teammate's removal from an Organization or Project
* Review, approve, and reject requests
* Who can approve, and what approving changes
{% endcolumn %}
{% column %}
**At a glance**
* **Time:** \~1–2 minutes per request
* **Access:** **Request Access** to raise requests; **Give Access** to decide them
* **Prerequisites:** the person's email address, or their row on the Teammates list
{% endcolumn %}
{% endcolumns %}
### Overview
Teammates who can't add or remove people directly can now **ask** for it. The right approvers decide in one click from their Inbox or from the **Access Requests** list.
* **Request Access**: ask for a person to be added to an Organization or Project. Type anyone's email, or pick a contact already on the Teammates list. If the email belongs to someone already in your Account, Transform recognizes them instead of adding them twice.
* **Request Removal**: ask for a teammate to be removed from one Organization or Project. Their account and other memberships stay untouched.
* **Review, Approve, Reject**: approvers see each request with the requested role and note, can adjust the role, and decide.
It's built for Client Collaborators and Project Managers who staff Projects day to day, and for the administrators who govern access.
### Benefits
* **No more dead-end buttons.** People without permission used to see **Invite User** and get an error. Now they see **Request Access** instead.
* **Built for volume.** Approvers can bulk-approve a queue of requests. Requesters can request access for many contacts at once.
* **Safe by default.** Approving runs the same checks as a direct invite, so nobody gets more access than the approver could grant themselves.
* **Everyone stays informed.** Approvers are notified as soon as a request is raised. The requester is notified when it's decided.
### How a request moves
1. **Raise:** the requester submits a request from **Teammates**.
2. **Notify:** everyone who can approve it gets an Inbox notification.
3. **Decide:** the first approver to approve or reject closes it for everyone, and the requester is notified.
The requester can cancel the request any time before a decision.
### Request access or a removal
{% stepper %}
{% step %}
#### Open Teammates
Open the Organization or Project and go to **Teammates**.
{% endstep %}
{% step %}
#### Choose who the request is for
* **Anyone, by email:** click **Request Access** in the toolbar. Enter their email; name and a note are optional. This works for new people and for teammates who already use Transform elsewhere in your Account: the email is matched to them on approval, and they keep their current role.
* **A contact already on this list (added, but never invited):** open the row menu and choose **Request Access**.
* **Remove someone:** open a member's row menu and choose **Request Removal**. This removes them from this Organization or Project only.
* **Many contacts at once:** select their rows and choose **Request Access** in the selection bar. One role and note apply to all.
{% endstep %}
{% step %}
#### Pick a role
For access requests, choose the role to request. It's required whenever the picker lists roles. Removal requests have no role.
{% endstep %}
{% step %}
#### Send
Click **Send Request**. The row shows **Request pending**, and you can choose **Cancel request** from the same menu.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
Follow your requests under **Access Requests** in the navigation, and watch your Inbox for the decision.
{% endhint %}
### Review requests
{% stepper %}
{% step %}
#### Open the request
Open the Inbox notification, or go to **Access Requests**. It sits in Account navigation, in an Organization's **Current Blueprint** group, and in a Project's **Governance** group, each with a pending count.
{% endstep %}
{% step %}
#### Decide
Choose **Approve** to accept the suggested role, **Review** to change the role or its scope first, or **Reject** with an optional note.
{% endstep %}
{% step %}
#### Clear a queue (optional)
Select several rows and choose **Approve** or **Reject** in the selection bar. A confirmation appears first, then a summary of what succeeded.
{% endstep %}
{% endstepper %}
### Details and rules
Two role permissions control the feature: **Request Access** lets someone raise requests, and **Give Access** lets someone decide them. Admins can turn either on or off per role in the role editor.
#### Who can approve requests
Anyone whose role has the **Give Access** permission can approve or reject requests, as long as:
* **It covers the request's scope.** Give Access applies to the request's Organization or Project. For a request on an Organization, it must cover the whole Organization.
* **They can make the change.** The same role can add teammates there (for invite requests) or edit teammates there (for removal requests). Approving performs that change on the approver's behalf.
* **It's an internal role.** Give Access on a client (External) role doesn't allow approving.
Everyone who meets these conditions is notified of new requests and can approve or reject them. Someone with Give Access who can't add or edit teammates there can see the requests on the **Access Requests** list, but can't decide them.
{% hint style="success" %}
To make someone an approver, turn on **Give Access** for their role in the role editor, and make sure that role can add or edit teammates in the Organizations or Projects they should approve for.
{% endhint %}
#### Roles and scope
* **Suggested role:** the role the requester picked, or the requester's own role if they didn't pick one. Approvers can change it with **Review**.
* **Limited to the request's scope:** by default, access is restricted to the Organization or Project the request came from.
* **Outside email domains:** people whose email isn't on the Account's internal domains can only get client (External) roles, and their access always stays limited to that scope.
* **People who already have a role keep it.** Approving adds the new Organization or Project to their current access. See the next section.
* **Broader access:** only approvers who can add teammates across the whole Account can approve without the scope limit.
#### Requesting access for someone already in Transform
If the email you type belongs to a teammate who already has a role, they keep that role. The role picked in the request is not applied.
**When you send the request**
* The role picker still appears, and the role you pick is saved and shown to approvers.
* The email-domain rule still applies: internal roles can't be requested for outside email domains.
**When it's approved**
* **Role:** unchanged. Approvers see "already has this role; approving keeps it" instead of a role picker, and can't choose a different role or remove the scope limit.
* **Access:** their current role is extended to the new scope.
* Already covers the whole Account or that Organization: nothing changes.
* Covers only some Projects and the request is for the Organization: it now covers the whole Organization.
* Request is for a Project they can't reach yet: that Project is added.
* A different Organization: it's added alongside their current access.
* **Membership:** they're added to the Organization or Project if they weren't a member.
* **Invitation:** active teammates get no new invitation. Contacts who were never invited do get one.
{% hint style="info" %}
**Exception:** an existing contact with no role is treated like a new person. They get the requested role, or the requester's own role if that one is no longer available, limited to the request's Organization or Project.
{% endhint %}
To change an existing teammate's role, ask someone who can edit teammates directly. Requests can't change roles.
#### What approving does
* **New person or contact:** they're added to the Organization or Project and sent an invitation email.
* **Existing active teammate:** they're added, with no new invitation.
* **Removal:** they leave that Organization or Project only. Removing from an Organization also removes them from its Projects. Their account and other access stay the same.
* **If the invitation email fails,** the approval still stands. Resend it with **Invite User** on the contact.
#### Other rules
* Only one pending request per person, scope, and type. A duplicate is refused with a clear message.
* The first decision wins. Other approvers see who decided, and their notifications clear automatically.
* Only the requester can cancel their request. Approvers reject instead.
* You can't request your own removal.
* Notifications are in-app only. Approvers don't get email for new requests.
### FAQ
I don't see Request Access. Why?
Either you can already invite people there (you'll see **Invite User** instead), or your role doesn't include the Request Access permission. Ask your administrator.
The role picker says "The reviewer will choose the role." Is something wrong?
No. No role could be offered for that person, usually because no available role fits their email domain (for example, an outside email when the Account has no client roles). Send the request as normal, and the approver will pick a role.
Why can't I pick an internal role for someone?
Their email isn't on your company's internal domains, so they can only receive client (External) roles.
Who gets notified about my request?
Everyone who can approve requests for that Organization or Project.
How do I know when my request is decided?
You get an Inbox notification saying whether it was approved or rejected, with any note from the approver.
Can I change a request after sending it?
Not yet. Cancel it and raise a new one.
Two approvers clicked Approve at the same time. What happens?
The change is applied once. The second approver sees that the request was already decided.
Does removing someone delete their account?
No. It removes them from that Organization or Project only.
Will approvers get an email?
Not today. Notifications appear in the Transform Inbox and on the Access Requests list.
### Summary
* Requesters raise access and removal requests from **Teammates**.
* Approvers decide from the Inbox or **Access Requests**.
* Approving applies the change with the same checks as a direct invite or removal.
Related:
* [Add Teammates](/organizations-and-projects/add-teammates.md)
* [User Roles and Permissions](/organizations-and-projects/user-roles-and-permissions.md)
* [Understanding Access Levels](/organizations-and-projects/understanding-access-levels.md)
---
# 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://help.transform.ai/organizations-and-projects/teammate-access-requests.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.