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.

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.