--- title: "Admin: people, roles and access in Rig — Rig guide" description: "Get a teammate into your Rig workspace with the right role: the signup approval queue, domain auto-join, the default role for new members, and previewing what a role sees." canonical: "https://rig.so/guides/admin-people-and-roles" format: markdown --- Search guides, references, playbooks…⌘K Browse guides # Admin: people, roles and access The practical side of running a Rig workspace: where the access screen is, how a new teammate actually gets in, which role they land on, and how to check what a role can see before you hand it to anyone. For the concepts behind it — masks, row filters, PII policy — read [role-based access control](https://rig.so/guides/rbac) first. This page does not repeat them. ## Where the screen is Everything below happens on one screen, at `/admin/access`, headed **Roles, collections & policies**. There are two ways in: - **Access** in the **Connect** group of the left rail. - **Settings** (bottom of the left rail) → **Workspace** group → **Access Gateway**. The page is admin-only. If neither entry point is there, you are not an admin on this workspace, and that is the answer rather than a bug to chase. Down the side is a section list: **Roles**, **Collections**, **Access Matrix**, **Permissions**, **PII Policies**, **Context Editing**, **Domain Owners**, **Users**, **Sharing**, **Audit Log**, and **Preview as Role** ("Test what each role sees"). ## How a new person gets in There are two routes, and their email domain decides which one applies. 1. **Domain auto-join.** If their address matches one of your configured auto-join domains, signing up puts them straight into the workspace on the default role, with no approval step. Free-mail domains such as gmail and outlook are exempt, and so is an address containing a `+`. 2. **Approval queue.** Everyone else lands on a waiting page headed **Waiting for approval**, telling them their request is queued and they will be emailed when they are in. The page polls, so they can leave the tab open. Someone has to approve them before they see anything. There is a second, invisible way auto-join fires: if your workspace has an email domain set on the organisation itself, anyone signing up on that domain auto-joins too, at the default role and with no approval, even when the auto-join domain list is empty. Nothing in the app surfaces this, so do not read "no auto-join domains configured" as "everyone on our domain lands in the queue". The auto-join domain list has no self-serve edit screen today. It is workspace configuration held by Rig, so changing it is a request to your Rig contact rather than something you do on this page. ## Default role for new members **Default role for new members** is the role every auto-joining person receives. Like the auto-join domain list, it is not editable in the app today: ask your Rig contact to set it, and do it **before** you invite anyone. An unset or wrong default is handed out silently to everyone who auto-joins, and nobody gets a prompt about it. Owner is never used as a default, because anyone signing up on a matching address would receive it. What you can always do from this screen is fix it afterwards. **Users** lists everyone who has landed in the workspace and lets you change any individual's role. ## Roles versus collections These two get confused constantly, and the distinction is what makes the rest of the screen make sense. - A **role** is a named bundle of rights. Everyone in the workspace has exactly one. - A **collection** is a named group of data. Grants attach roles to collections, so a role can see one part of the warehouse and not another. A role on its own therefore tells you very little. What a person can see is the set of collections their role has been granted, plus whatever policies apply on top. **Access Matrix** is the roles-by-collections grid and the fastest way to see the whole picture at once — read it rather than inferring anything from a role's name. When you need a new shape of access, check **Roles** first and confirm no existing role fits before inventing one. Then look at **Collections** to see how the data is grouped, since a collection is the unit you grant. **Audit Log** records what changed and who changed it. ## Preview before you ship **Preview as Role** lets you pick a role and see what it can see. Do this before you assign the role to a person, every time. It is the difference between proving a change is right and finding out from the colleague who could not open something on their first morning. 1. Make the grant or policy change. 2. Open **Preview as Role** and select the role you changed. 3. Confirm it can reach what you intended and nothing more, then check **PII Policies** to see which columns are masked for that role. 4. Only then assign the role to a person. ## Roles and MCP access An MCP connection carries the same role as the person who created it, so access changes reach their Claude or Cursor session too — but not instantly. A role change propagates in tens of seconds for an app or OAuth session, and up to five minutes for a long-lived API token, because each server caches it. To remove someone's programmatic access urgently, go to **Users**, turn off their **MCP** toggle, and then change their role. Do the toggle first: changing the role alone leaves the old role live in cache. There is no sign-out or session-revoke control on this page or anywhere else in the product, so do not plan around one. The toggle also governs sessions signed in through the app rather than a long-lived API token someone generated for themselves; if they hold one of those, it has to be revoked as a token before they are actually out. ## Common problems - **A new person is stuck on "Waiting for approval".** Their domain does not auto-join, so they are sitting in the queue. Someone has to approve them; the page will not clear itself. - **Their signup was declined.** They see a page headed **Signup declined**. It is not recoverable from their side. - **They got in but see nothing.** They have a role with no grants, or the default role is more restrictive than you thought. Check **Preview as Role** for their role. - **Someone cannot see a schema.** Their role has not been granted the collection that schema belongs to. Open **Access Matrix** and check the grant, not the role name. - **They see more than you expected.** Same fix, other direction: the **Access Matrix** is authoritative, and a reassuring role name is not. - **Someone cannot see an admin-only page.** Admin screens including **Access Gateway** only appear for admins. If the rail's **Access** item and the Settings link are both missing for them, they do not have an admin role — change it from **Users**. - **You changed a role and MCP still works.** Expected, briefly. See the caching note above. Step 10 of 10 Was this guide helpful? Yes No --- - [This page as HTML](https://rig.so/guides/admin-people-and-roles) - [Site map for language models](https://rig.so/llms.txt) - [API and agent documentation](https://rig.so/developers)