Mammoth roles and permissions, and custom roles

Roles at a glance

The built-in roles carry these summaries in the app:

Workspace Owner vs Workspace Member permissions

Workspace roles are assigned by a Workspace Owner and apply across the whole workspace.

What a Workspace Member can do in Workspace Settings

• View the people in the workspace (User Management, read-only).
• Create projects.
• Create, edit and remove API tokens, and use the two setup cards on API Keys.
• View external AI keys, but not add or remove them.
• View the plan and storage (Plan & Storage).
• View and export the Activity Log.

Everything else in Workspace Settings needs the Owner role: renaming or deleting the workspace, inviting and removing users, changing roles, changing the plan and billing, export destinations, adding external keys and registering OAuth apps.

Project Admin vs Project Editor vs Project Viewer permissions

Project roles are assigned per project. A Workspace Member must be added to a project to open it: membership in the workspace alone doesn't grant project access.

For how to give someone a project role, see Share a project and set project roles.

Dashboard Editor vs Dashboard Viewer permissions

Dashboards have their own sharing model, set in the dashboard's Share panel.

Editors of a dashboard must have access to the same project as the dashboard. See Publish and share a dashboard.

Row-level security for dashboards is a plan feature, included on the Pro plan. Whether your workspace has it depends on your plan. See Row-level security.

Read the role matrix in Roles & Permissions

Open Workspace Settings and choose Roles & Permissions, between User Management and Email groups. Workspace Owners see this section, and so does anyone whose role has Manage custom roles (workspace and project). Everyone else can open the same matrix read-only from View Roles & Permissions in any role menu or project role dropdown, in a modal with Workspace Permissions and Project Permissions tabs.

Switch between Workspace and Project at the top. The note under the switch explains each: "Workspace roles control billing, users, governance, and cross-project settings." and "Project roles control access within individual projects and are available across all projects."

Each permission is a row and each role a column, with a tick or a cross per cell. Built-in roles show their short names (Owner and Member; Admin, Editor and Viewer). Each column also shows:

Use Search permissions… to find a permission, and the roles menu (Showing all roles) to hide columns. At least one role stays shown.

Custom roles: plan and who can make them

A custom role is a role you build from a list of permissions when the built-in roles don't fit. You can make custom workspace roles and custom project roles. Custom roles belong to the workspace: a custom project role can be given to anyone in any project of that workspace. Mammoth enforces a custom role on the server in the same way as a built-in role.

• Plan: custom roles are included on the Pro plan, and during a Pro trial (New Role shows a Trial pill). On a plan without them, clicking New Role shows the upgrade prompt described in When a feature isn't on your plan.
• Who: Workspace Owners, and anyone whose workspace role includes Manage custom roles (workspace and project).
• What they can grant: a Workspace Owner can put any permission in a role. Anyone else can only tick permissions their own role has. The others are greyed out with "You can't grant this permission because your own role doesn't have it."

There is no limit on the number of custom roles in a workspace.

Create a custom role

1. Open Workspace Settings and choose Roles & Permissions.
2. Click New Role (top right). The Create role panel opens.
3. At the top, choose Workspace or Project for the role's scope. Switching scope clears the permissions you've ticked.
4. Enter a Name, up to 40 characters, for example Sales reviewer.
5. Check the description. By default it's an Auto-generated description built from the permissions you tick, for example "Manage the Data Library. View connections." To write your own (up to 120 characters), click Write my own. Use auto switches back.
6. Under Select permissions, tick the permissions the role should have. Tick a section's box to tick every permission in it. The counter beside Select permissions shows how many you've picked out of the total.
7. Click Create Role.

Mammoth shows "Role created". The new role appears as a column in the matrix, marked Custom.

Create Role stays disabled until the role has a name and at least one permission. Hover it to see why, for example "Enter a name and select at least one permission." A name already used by another role in the same scope, including a built-in name such as Owner or Admin, shows "This name is already in use. Choose another." Names are compared without regard to capitals.

Workspace permissions you can pick

Every custom workspace role can also open the workspace, whatever you tick.

Project permissions you can pick

Every custom project role can also open the project it's given on.

Permissions that tick another permission

Some permissions can't work without a read permission. Ticking one ticks the permission it needs, and unticking the needed permission unticks the ones that rely on it.

Edit a custom role

1. In Roles & Permissions, find the role's column and click Edit.
2. In Edit role, change the name, description or permissions.
3. Click Save Changes.

Mammoth shows "Changes saved". The change applies to everyone who holds the role. Built-in roles have no Edit link and can't be changed.

If you close the panel with unsaved changes, Discard changes? asks "You have unsaved changes to this role. Discard them?" Click Discard or Keep editing.

Give someone a custom role

Custom roles appear in the same role pickers as the built-in roles, listed after them with their description:

You can only assign a custom role whose permissions your own role has. Other custom roles are greyed out with "You can't assign this role because it has permissions your own role doesn't have." Workspace Owners can assign any role. See Invite and manage workspace members.

Delete a custom role

1. In Roles & Permissions, click Edit on the role.
2. Click Delete Role.
3. In the dialog, for example Delete "Sales reviewer"?, click Delete role.

Mammoth shows "Role deleted". Deleting a role is permanent.

Keep workspace access tidy

• Limit Owner access to the people responsible for billing and workspace administration. A workspace can have more than one Owner, so keep the number small.
• Default to Project Editor for new members who work with data, and Project Viewer for people who only need to look. Give Project Admin only when the person needs to manage project membership or Live Connections.
• Remove users promptly. Removing a user from the workspace revokes all their project access at once.
• Scope API keys. When a key is for an integration that targets one project, set the project scope so it can't reach other projects. See API keys, AI assistants and connected apps.
• Review access periodically. In Workspace Settings → User Management, check who belongs to which projects and in what role, against your current team.

Limits

Troubleshooting custom roles

Related

• Invite and manage workspace members: change someone's workspace or project role.
• Share a project and set project roles: roles from inside a project.
• Security: sign-in, data security and compliance: how access is enforced and workspaces are kept apart.
• Audit logs: who changed what.
• Publish and share a dashboard: dashboard roles in practice.