> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gradial.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Roles & Permissions

> Understand how Gradial calculates access from a user's primary organization role, optional additional access, and workspace role.

A user's effective access in Gradial is calculated from three things:

1. **Primary organization role** — the user's platform-wide role: Owner, Admin, Member, or Viewer.
2. **Additional access** (optional) — add-on permissions layered on top of the primary role: Brand Manager and Designer.
3. **Workspace role** — what the user can do inside a specific workspace: Owner, Admin, Member, or Viewer.

Permissions **combine** across these layers — additional access and workspace roles add to a user's primary organization role; they never replace it.

> **Looking to add someone to your team?** See [<u>Adding Team Members</u>](/docs/integrations-administration-and-setup/managing-access/manage-team-members) for step-by-step instructions on inviting users and configuring workspace access.

***

## Primary Organization Roles

Every user has exactly one primary organization role, set from **Settings → People → Members**.

To see every role and who currently holds it, open **Settings → People → Roles**. Each role row can be expanded to show its members, and the list can be searched and filtered by scope (organization or workspace). Brand Manager and Designer appear here at the organization scope, alongside the four primary roles.

| **Role** | **Access summary** |
| :- | :- |
| **Organization Owner** | Organization administration, billing, organization deletion, and organization ownership transfer. Manages integrations and settings, members, rules, and design systems. Has full access to all standard workspaces. |
| **Organization Admin** | Manages organization settings, integrations, members, rules, and design systems, and has access to every standard workspace. Does **not** include organization deletion, billing, or organization ownership transfer (can transfer *workspace* ownership). |
| **Organization Member** | Access to public standard workspaces as a Workspace Member. Access to a private workspace requires an access grant. |
| **Organization Viewer** | Read access to public standard workspaces as a Workspace Viewer. Access to a private workspace requires an access grant. |

* **Organization Owners** hold billing, organization deletion, and organization ownership transfer rights — permissions no other role has.
* **Organization Admins** manage the organization day to day and can reach every standard workspace, but cannot delete the organization, manage billing, or transfer organization ownership.
* Changing a user's organization role changes their inherited access **immediately**.

***

## Additional Access

A user may have their primary role plus one or both of these add-ons, assigned under **Additional access** in the role picker on the People page. They are organization-level add-ons — they are **not** workspace roles, and they don't replace the primary role.

| **Additional access** | **Access summary** |
| :- | :- |
| **Brand Manager** | Can manage organization rules. Can manage rules in a workspace only when the user is also a member of that workspace — directly or through an assigned custom group. Public workspace visibility alone is not enough. |
| **Designer** | Can manage design systems, personas, and audiences — including viewing, creating, editing, and deleting design systems. This access is organization-scoped — it is not limited to a single workspace. |

<Info>
  Design system creation, editing, and deletion is authorized at the **organization** level: Organization Owners, Organization Admins, and users with Designer additional access. Workspace membership alone — including Workspace Admin — does not grant design-system management.
</Info>

***

## Workspace Roles

Within a workspace, a user has one of four roles.

| **Role** | **Workspace and Task access** |
| :- | :- |
| **Workspace Owner** | Manages workspace settings, members, rules, archiving, and workspace ownership transfer. Has full Task permissions, including delete and lock, and full artifact permissions, including publish. |
| **Workspace Admin** | Manages workspace settings, members, rules, and workspace ownership transfer. Can create, edit, and delete Tasks. Can view and create artifacts, but cannot archive the workspace or edit, delete, or publish artifacts. |
| **Workspace Member** | Can view and edit the workspace and create, edit, and delete Tasks. Cannot manage workspace settings, members, or rules. |
| **Workspace Viewer** | Can view the workspace, its Tasks, and its artifacts. Cannot create or modify them. |

A direct workspace role can **add** rights beyond what a user's organization role provides, but it never removes organization-derived rights.

### Workspace ownership

* A standard workspace has exactly **one owner**. To change it, use the ownership-transfer flow rather than assigning the Owner role directly.
* Workspace Owners and Workspace Admins can transfer workspace ownership.
* The new owner must be a **direct workspace member** or an **Organization Owner or Admin**. Access through a custom group alone is not sufficient.
* After the transfer, the former owner becomes a **Workspace Admin**.

***

## Public and Private Workspace Access

### Public standard workspaces

Public standard workspaces are accessible to everyone in the organization:

* **Organization Members** receive effective **Workspace Member** access.
* **Organization Viewers** receive effective **Workspace Viewer** access.

If a user also has a higher direct workspace role, the higher role applies.

### Private standard workspaces

Access to a private standard workspace can come from any of these paths:

* **Direct membership** — the user is added to the workspace individually
* **Custom group** — the user belongs to a custom group assigned to the workspace, which grants **Workspace Member** access ([User Groups](/docs/integrations-administration-and-setup/managing-access/groups))
* **SCIM group mapping** — the user belongs to an identity provider group mapped to the workspace ([SCIM User Provisioning](/docs/integrations-administration-and-setup/managing-access/scim))

**Exception:** Organization Owners and Organization Admins can access every standard workspace — public or private — without direct membership, and receive admin-level access. Removing a workspace grant does not remove an Organization Owner's or Organization Admin's inherited access.

### Admin workspaces

Admin workspaces are never public and are visible only to the organization's current Owners and Admins. Direct members, custom group assignments, and workspace owner rows cannot grant access to them, and promoting or demoting someone's organization role changes their access immediately.

Admin workspaces cannot have direct members, custom group assignments, role changes, or ownership transfers, and cannot be converted to or from a standard workspace.

***

## How Access Paths Combine

<Warning>
  **There is no deny role.** If any access path allows an action, the user can perform it. To fully remove someone's access, remove **every** path that grants it.
</Warning>

A user can reach a workspace through several paths at once: their primary organization role, additional access, a direct workspace role, a custom group assignment, public workspace visibility, and SCIM group mapping. Keep these in mind:

* **Removing direct membership is not a permanent block.** If the user remains in the organization and is later added to a custom group assigned to that workspace, they regain effective Workspace Member access.
* **Organization Owners and Admins can't be restricted inside a standard workspace.** Removing their workspace membership doesn't remove their automatic access — change their organization role instead.
* **The last Organization Owner is protected.** Transfer organization ownership before demoting or removing that person.

***

## Task Visibility and Explore Chat Privacy

Workspace access does not expose every conversation in a workspace:

* **Committed Tasks** follow workspace access — anyone who can access the workspace can see them according to their workspace role.
* **Explore chats are creator-private.** Another Workspace Member or Workspace Admin cannot view your Explore chat just because they can access the workspace.
* **Organization Owners and Organization Admins** can read another user's Explore chat for governance purposes, but that access is **view-only** — they cannot edit, delete, or add messages to it.

***

## Managing Users

For step-by-step instructions on inviting users, granting workspace access, and changing roles, see [<u>Adding Team Members</u>](/docs/integrations-administration-and-setup/managing-access/manage-team-members).

***

## Recommended Administration Flow

1. **Start with least privilege** — choose the lowest organization role that supports the person's normal work.
2. **Pick the right access path** — use a direct workspace role for one-off access; use a custom group when the same people need access to several workspaces.
3. **When troubleshooting access, check every path** — primary role, additional access, direct workspace role, custom group assignment, public visibility, and SCIM group mapping.
4. **To restrict an Organization Owner or Admin, change their organization role**, not their workspace membership.

***

## Quick Notes

* A user's effective access is the **combination** of their primary organization role, any additional access, and their workspace role.
* **Organization Owners and Admins** don't need to be added at the workspace level — they can access every standard workspace automatically.
* **Brand Manager** and **Designer** are organization-level additional access, not workspace roles.
* Organization ownership can be transferred by an Organization Owner. Workspace ownership can be transferred by a Workspace Owner, Workspace Admin, or Organization Admin.
* **There is no deny role** — remove every granting path to fully remove access.
* **To invite new users** or modify access, see [<u>Adding Team Members</u>](/docs/integrations-administration-and-setup/managing-access/manage-team-members).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.