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:

• Admin in the Connect group of the left rail, then the Access tab.
• Settings (bottom of the left rail) → Workspace group → Access Gateway.

The page is for workspace owners. If you can find neither the Access tab under Admin nor Access Gateway in Settings, you are not an owner on this workspace. In a workspace that Rig manages for you, everyone sees Admin in the left rail, but only owners get its Access tab.

Down the side is a list headed Sections: Users, Roles, Agents, Collections, Access Matrix, Permissions, Writes, PII Policies, Context Editing, Domain Owners, Sharing, Audit Log and Test access ("See what a role or person sees").

How a new person gets in

A person gets in one of three ways, depending on whether you invite them and on their email domain:

1. Invite them. In Users, click Invite user, enter their email, pick a role (left as Org default role, they get the default role) and click Send invite. They get an email with a sign-in link and a temporary password, or just the access if they have already signed in to Rig. It is the route for a contractor or anyone outside your auto-join domains. Rig refuses an invite that would create a new login at a domain that auto-joins a different Rig workspace; someone there who has already signed in to Rig can be invited as normal.
2. Domain auto-join. If their address matches one of your auto-join domains, signing up puts them straight into the workspace on the default role, with no approval step. They have to confirm their email address first. An address containing a + does not auto-join.
3. A new workspace request. Someone who signs up on a domain that is not mapped to any workspace is asking for a workspace of their own. They fill in a form headed Set up your workspace with a workspace name and handle, click Submit for approval, and land on a page headed Waiting for approval, which polls, so they can leave the tab open. Rig reviews these requests by hand and emails them when they are in. If the person meant to join your workspace, invite them instead.

Two kinds of signup stop before that queue: a personal address such as gmail, outlook or iCloud gets a page headed Use your work email, and an address on a domain that already has a workspace which does not add new members automatically gets Ask for an invite, and that person needs an invite from one of the workspace's owners.

When Rig approves a new workspace, it adds that workspace's own email domain to its auto-join domains, so colleagues who sign up on the same domain later join on the default role without waiting for approval. It skips a shared domain, such as a public email provider's, and a domain already mapped to another workspace. In the Auto-join domains card that domain is listed and tagged primary. The workspace's primary domain auto-joins people even when it has no entry in the card, so new members can still arrive while the card reads None configured.

The card sits on the Roles section. Adding or removing any other domain is a setting only Rig can change, and the card says so: Only Rig can change this list — ask Rig support.

Default role for new members

Default role for new members is the role every auto-joining person receives. Set it in its card on the Roles section, and do it before you expect anyone to join. It applies to future joins only, so people who already have a role keep it, and nobody gets a prompt about which role they landed on. The card always shows a role, and it is editor until someone changes it. Only the built-in editor, analyst and viewer roles can be chosen. Owner is not offered, because anyone signing up on a matching address would receive it, and custom roles are not offered either. On a workspace that keeps its configuration in its own database, the card says so and asks you to ask Rig to change it for you.

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.

Built-in roles and what they can do

Every workspace has four built-in roles, from most to least access. The older names still work: admin means owner and data_engineer means editor.

• Context edits. Who edits directly and who only requests is set per role in Context Editing, with the columns Edit context and Request context edit. The table above shows the defaults.
• Connections. Adding and managing data sources needs the owner role, or a role with Manage connections ticked.
• Custom roles. Owners can click Add custom role on the Roles section. Fill in Role name first: a lowercase identifier such as data_steward, which cannot be changed later. Then give it a Display name. Under Start from, choose Blank (read access to every collection) or a Copy of an existing role, which takes its grants, masks, filters, hierarchy level and ticked settings too. Adjust Hierarchy level if you need to (viewer is 0, analyst 1, editor 2 and owner 3), tick any of Can edit context, Unrestricted SQL (bypasses certified-query enforcement) and Manage connections (view + add data connections), and click Create. Create stays greyed out until the role has a name.
• Slack. The Roles section also holds Slack bot access, the role @rig reads data with when it answers in a channel. See Ask Rig in Slack.

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.

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.

Test access before you ship

Test access lets you pick a role and see what it can see. Do this before you assign the role to a person, every time. Nothing you run there changes any data.

1. Make the grant or policy change.
2. Open Test access and select the role you changed.
3. Click What can <role> see? to list every table and VDM as readable, with any masked columns, or blocked, with the reason. To see the rows themselves, run a SQL query as that role.
4. Only then assign the role to a person.

Owners can also set As to Person and pick someone from the people directory (Settings → People). Your SQL then runs as that person, with their own row scope applied as well. The What can <role> see? check is only offered for a role.

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, though not instantly. Each server caches the role for about 30 seconds, so a change usually lands within half a minute, for a session signed in through the app and for a long-lived API token alike. A token can occasionally take up to a minute.

To stop someone's MCP access, go to Users and turn off the switch in their MCP column. It blocks their MCP connections, including MCP calls made with one of their API tokens, and their app login keeps working. API tokens they use outside MCP, such as for triggering workflows or updating the people directory, keep working after the switch is off. To cut off every token, remove them from the workspace: click the button on their row whose tooltip reads Remove from workspace. That revokes their API tokens for this workspace and the shared links they made in it. There is no separate sign-out or session-revoke control on this page or anywhere else in the product.

Rig always asks you to confirm a removal. If their email domain is listed in Auto-join domains, removing them only lasts until their next visit, when they join again on the default role, so Rig warns you about that and asks a second time. The workspace's primary domain can bring them back the same way even when the card does not list it, as long as they belong to no other Rig workspace, and in that case there is no second warning. To keep them out for good, ask Rig support to remove the domain mapping. If you only want them to see less, leave them in the workspace and change their role instead.

Common problems

• A new person is stuck on "Waiting for approval". Their domain is not mapped to your workspace, so they asked Rig for a new workspace of their own. If they should be in yours, invite them from Users.
• Their signup was declined. They see a page headed Signup declined, which gives Rig's address to write to if they think it is a mistake. The contact form works too. They cannot undo it themselves.
• They got in but see nothing. They have a role with no grants, or the default role is more restrictive than you thought. Check their role in Test access.
• Someone cannot see a schema. Their role has not been granted the collection that schema belongs to. Open Access Matrix and check that grant for their role.
• 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 owner-only page. Screens including Access Gateway only appear for owners. If the rail's Admin item and the Settings link are both missing for them, they are not an owner. Change their role from Users.
• You changed a role and MCP still works. Expected, briefly. See the caching note above.