Admin: people, roles and access

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.