> ## Documentation Index > Fetch the complete documentation index at: https://docs.dmly.io/llms.txt > Use this file to discover all available pages before exploring further. # Control what your team can do > Set a base role for each team member and build custom roles that grant an exact set of permissions. Every person who logs in to your workspace has a **base role** — Admin, Member or Viewer. That role decides what they can open and change. When none of the three fits, you can build a **custom role** with an exact set of permissions and assign it to a member. Only an Admin (or the workspace owner) can reach **Workspace Settings → Team Members**. The **Team Roles** page needs the *Create & edit custom roles* permission — Admins and the owner have it by default, and a custom role can grant it to a Member. ## The three base roles Can access and edit everything, including billing, channels and team settings. Can access and edit everything except the configuration section — a full day-to-day operator. Can view the messaging modules (Inbox, Contacts, Broadcasts, Automation and so on) but cannot edit, send, or change configuration. **Member** is the everyday role: it covers the work, but stops short of the destructive and admin-only actions — deleting, importing or exporting contacts, approving or deleting broadcasts, deleting automations and templates, seeing the whole team's appointments, booking or blocking time for other people, managing working hours or booking settings, deleting offerings, issuing refunds, changing finance settings, editing business info on Google, exporting reports, setting up integrations, and anything under team settings. **Viewer** gets read-only access and nothing else. The workspace **owner** always has full access and carries an **Owner** badge in the members list. You can't change the owner's role or remove them, and you can't change your own. There's no way to hand a workspace to a different owner from inside the app — contact your agency or DMLY support if you need that. How many people you can have in a workspace depends on your plan, and pending invitations count toward the limit. See [Plans](/billing/plans) and [Add-ons](/billing/add-ons). ## When to build a custom role DMLY ships **no ready-made custom roles**. A new workspace has the three base roles and nothing else, which is why the Team Roles page starts empty. Build one when you need someone in between — more than a regular Member, less than an Admin. A bookkeeper who should issue refunds and change finance settings but touch nothing else. A marketer who can approve and send broadcasts but can't delete contacts. A manager who can see the whole team's appointments. If a base role already fits, use it. A custom role is extra to maintain. ## The module and action model A custom role is built from **62 permissions** grouped into **13 modules**: | | | | ------------------- | ------------------------ | | **Inbox** | **Contacts** | | **Broadcasts** | **Automation** | | **Templates** | **Appointments** | | **Offerings** | **Finance** | | **Reputation** | **Reports** | | **Growth Tools** | **Setup & Integrations** | | **Team & Settings** | | Each module holds separate actions — viewing, creating, editing, deleting, exporting and so on — so you grant the specific thing rather than the whole module. You can tick a module whole, or tick individual permissions inside it. Permissions are enforced when a page loads, not just by hiding menu items. A member without any permission in a module can't reach it even with a direct link. ## Build a role Go to **Workspace Settings → Team Members** and select **Team Roles** in the panel header. Select **Back to Team Members** to return. Select **New role**, name it something a person would recognise on a picker — "Bookkeeper", "Front desk" — and open the **Permissions** matrix. Work module by module. Tick a whole module when the role owns that area, or tick individual actions when it doesn't. Start narrow — you can always add more later. The role now appears on the Team Roles list, ready to assign. Creating a role changes nobody's access until you assign it. Grant a view permission wherever you grant an edit permission. A role built from edit permissions alone will reach the module, but pages and lists it can't view will be incomplete. ## Assign a role Members are invited by email — there's no way to add someone directly. Go to **Workspace Settings → Team Members** and select **Invite member**. Enter their email address and pick a base **Role**. Under **Custom role**, choose the role you built, or leave **None — use the base role above** to stay on the base role. Select **Invite**. The invitation appears at the top of the members list with a **Pending** badge until they accept. To change an existing member, open the actions menu on their row and select **Edit role**. You can set both the base role and the custom role there. A pending invitation's role can't be edited. If you picked the wrong one, select **Cancel** on that row and send a fresh invite. ## How access is decided DMLY works down this order for every member: 1. **Owner or base role Admin** — full access, always. A custom role assigned on top of Admin makes no difference. 2. **A custom role is assigned** — exactly the permissions ticked on that role, and nothing else. The custom role replaces the base role's defaults. 3. **Base role Viewer** — view permissions only. 4. **Base role Member** — the standard operator set described above. So a custom role decides access for base role Members. Base role Viewers stay read-only whatever the role grants — a Viewer with a custom role that grants editing or sending still can't write anything. Put someone on **Member** before assigning a custom role that needs to edit or send. Members on that role revert to their base role — Member or Viewer — and keep working. Nobody is locked out. The confirmation says so before you delete. Check their row in **Team Members** first. If they have a custom role, the base role is being ignored — the fix is a permission on the role, not a different base role. Then check that the role has the module's view permission as well as the action they're trying to take. If their base role is **Admin**, no custom role will narrow them. Drop them to **Member** and let the custom role do the work. ## Related Invite people, cancel invitations, and remove members. How many members your plan allows. Workspace settings an Admin controls. Owner-only workspace actions.