# Understanding roles and custom access roles

> The seven base roles at a glance, plus how custom access roles fine-tune what each person sees and can do — per module and per action.

Canonical: https://enmantle.com/help/custom-access-roles · Section: Admin & Setup · Updated: 2026-08-07

Every person on Enmantle has one **base role** that sets what they can see and do. Most of the time, the base role is all you need. When you want to fine-tune access — give one person read-only billing, or hide a module from a team — you layer a **custom access role** on top. This guide covers both.

## The seven base roles

From most access to least:

- `Platform Admin` — a cross-tenant operator (that's us, not you).
- `Super Admin` — full owner of your account. The only role that sees Workspace and Tenant Settings, Maintenance Mode, and can add custom apps.
- `Admin` — nearly full access: users, locations, clients, announcements, expense approvals, paycheck uploads, and the LMS. Can create and edit users, but not delete.
- `Director` — like Admin, minus creating users and uploading paychecks.
- `Manager` — scoped to their location: their team, their location's expense approvals, clients there, and announcements.
- `DSP` — the front-line default: clock in, own clients and pay, expenses, courses, complaints, and medications.
- `Client` — minimal: courses and their own expenses.

New to adding people? Start with [Adding a staff member and choosing a role](/help/add-staff-and-roles).

## Custom access roles sit on top

Go to `Roles & Permissions` at Settings (Admin and above). As the page puts it, "Custom roles set per-module access on top of each user's base role." So a custom role doesn't replace someone's base role — it adjusts it, module by module.

## Set access per module

For each module — Announcements, Files, Apps, Team/Users, Locations, Settings, Analytics, and more — you pick one tier chip:

- `None` — "Hidden and blocked." The person never sees it.
- `View` — "Read-only." They can look, not change.
- `Default` — "User's base-role behavior." Leaves that module exactly as their base role sets it.
- `Full` — "Module admin." Full control of that module.

Dashboard and Support are always accessible, no matter what — you can't lock someone out of those.

## Allow or deny specific actions

Some modules go a level deeper. For server-enforced actions — like expenses, users, paychecks, and medications — you'll also see per-action toggles:

- `Inherit` — follow whatever the tier and base role already allow.
- `Allow` — permit this specific action.
- `Deny` — block it, even if the tier would otherwise permit it.

This is how you build something precise, like "can see users but can never delete one."

## Start from a preset

You don't have to build every role from scratch. Preset templates give you a sensible starting point:

- `Pharmacy`
- `Scheduler`
- `Tutor (LMS only)`
- `Admin (no Billing)`

Pick the closest one, then adjust. Before you save, use `Preview what this role sees` to check the resulting sidebar — it's the fastest way to confirm a person will land where you expect.

> A custom role is reusable. Build it once, then apply it to everyone who should have the same access, instead of hand-editing each person.