> ## Documentation Index > Fetch the complete documentation index at: https://docs.useinvent.com/llms.txt > Use this file to discover all available pages before exploring further. # Custom Roles > Create roles with granular, resource-by-resource permissions for your team System roles (Admin, Developer, Manager, Agent) cover most teams. **Custom roles** go further: you define a role with your own name, color, and a precise permission set, resource by resource. Creating custom roles is available on the **Business** and **Enterprise** plans. Custom and system roles ## System vs custom roles * **System roles** are fixed and read-only: Admin, Developer, Manager, and Agent. You can open one to see exactly what it grants, but you can't change it. * **Custom roles** are roles you create with a tailored permission set, color, and description. A member has **either** one system role **or** one or more custom roles. When a member holds custom roles, those define their access, and their base role drops to Agent (see [Assigning roles](#assigning-roles)). ## Permission levels Open a role to see the permission editor. Every resource (Members, Inbox, Contacts, Tables, and so on) is set to one of three levels: | Level | Meaning | | :--------- | :------------------------------------- | | **None** | No access to the resource. | | **View** | Read-only: can see but not change. | | **Manage** | Full access: create, edit, and delete. | The role permission editor with None, View, and Manage levels Resources are organized into groups, **Organization**, **Inbox & contacts**, **AI & automation**, and **Reserved for admins**, with a legend at the bottom of the editor that explains each level. Not every resource offers all three levels. Some are view-only (Analytics, Audit logs) and some are manage-only (Connections, Workflows, Segments). The editor only shows the levels that apply to each resource. ## Sub-resources and cascading Some resources nest a finer-grained permission underneath them: * **System roles** under Members: whether this role can assign the system Manager and Agent roles to others (never Admin or Developer). * **AI Routing** under Assistants: conversation routing and assistant handoff. * **Table records** under Tables: the rows inside tables, separate from the table structure. * **Table views** under Tables: the saved views over those tables. Setting a parent to **Manage** cascades its children to Manage so you don't have to set each one, and setting any child to View or Manage lifts the parent to at least **View**, so a child is never granted under a hidden parent. You can still override a child afterward, for example Tables = Manage but Table records = None. The cascade is a **convenience in the editor only**. Access is always enforced on the exact permission a role holds, on both the backend and the interface. A role with Tables = Manage but Table records = None can edit the table structure but **cannot** edit the rows. ## Reserved permissions A few permissions are **reserved for Admins** and can never be granted through a custom role: **SSO**, **Sub-organizations**, and **Administration** (the reserved admin actions to delete the organization and manage roles). They appear in the editor with a "Reserved" badge and can't be selected. ## Creating a custom role Go to **Settings → Members & Roles → Roles** and select **Create role**. Give the role a name, pick a color (used for its badge across the workspace), and add an optional description. For each resource, choose None, View, or Manage. To start from an existing role, use **Copy from a role** and adjust from there. Select **Save changes**. The role now appears under **Custom roles** and can be assigned to members. The full permission catalog in the role editor You can only grant permissions you hold yourself (the **subset rule**), so you can never create a role more powerful than your own access. ## Assigning roles Assign custom roles from the members list with **Edit roles** next to a member, or stage them on an invite. Assigning a custom role drops the member to the **Agent** base role. They keep only the custom role's access, and removing all of their custom roles later leaves them as an Agent, not their previous system role. This is a safety measure so elevated access never lingers. ## Inviting with custom roles When you invite a member, pick a system role **or** one or more custom roles. If you choose custom roles, the invitee joins at the Agent base plus those roles when they accept. Choosing system or custom roles when inviting a member If a staged custom role is deleted before the invite is accepted, the invite is removed. ## The permissions matrix **Settings → Members & Roles → Permissions Matrix** shows every role (system and custom) as a column and every resource as a row, so you can compare access at a glance. The roles comparison matrix ## Plan and visibility notes * **Creating** custom roles requires the Business or Enterprise plan. Existing custom roles stay viewable and removable on lower plans, but you can't create new ones. * Once your workspace runs on a custom domain, that white-label domain and its email branding apply to every member regardless of role. What the role changes is visibility: members with the Manager, Agent, or a custom role only see Manager and Agent members, so your Admin and Developer members stay hidden from client-side teams. The role picker marks each role **Internal** or **Client** to show which side it puts a member on.