Roles: deciding what each person can do

The role is the only thing that grants permissions in Sentinel. Not the group, not the activity, not seniority: the role, and nothing else. That is why it's worth understanding how it works before hand-rolling one.

Every place starts with three roles: Viewer, Editor and Admin. For many organizations that's enough. You only need a custom role when someone must do a bit more than Viewer without getting everything Editor has.

The names and descriptions of those three roles can't be changed — they're translated automatically, and renaming them would break that. You can change their permissions, though, and create as many roles as you like.

Where: left navigation bar, under Administration → Roles.

Read a role before editing it

The editor opens with a summary, before the role's own name. Get into this habit: read the summary rather than the grid.

All twelve domains are always shown, including the ones at "None". Nothing is hidden: what is denied reads in its place, which keeps you from concluding too fast that a role grants less than it does.

The characterisation at the top is more than a count. A role that touches many domains but only in read mode is described as "Read-only access" rather than "Near-full access" — because that's the useful information.

The "except X" notes are filtered: an option is only flagged as off if it could be turned on as things stand. No point announcing "except Bulk edit" on a read-only role, where that option is structurally unavailable.

The twenty controls

Twelve three-level selectors — None, View, Edit — for the big domains: Tasks, Projects, Structures, Checklists, Trails & Configuration, Trail Conditions, Members, Groups, Roles, Invitations, Billing, Administration.

Eight switches for specific capabilities attached to those domains: Time, Bulk edit, Export, Structure reports, Check off items, Discussion, Dashboard, Planification.

A template bar at the top lets you start from Viewer, Editor or Admin and then adjust. Careful: applying a template replaces the whole configuration, with no confirmation. Changed lines flash so you can see the scale of what just happened.

The surprising part: permissions depend on each other

This is the heart of it. You can't grant "Projects" without granting at least "View" on Tasks — a project is a bundle of tasks, the screen would be empty. About thirty links like this exist in the app.

Sentinel never blocks a control over it. It does two things instead:

When turning something on, it raises whatever is missing. A "Will also enable…" chip warns you beforehand, and automatically raised lines flash — even when they're off-screen.

When turning something off, it shows you the consequences and asks for confirmation.

So no control is ever greyed out. You can always cut everything — you're simply shown the price first.

The dependencies you'll actually hit

Four controls depend on nothing and condition nothing: Dashboard, Trails & Configuration, Billing and Administration. They're the only ones you can set in isolation without side effects.

One special case is worth knowing: setting Checklists to Edit always turns on "Check off items", and it can't be undone. That's deliberate — server-side, managing checklists already authorises ticking. The state "manages checklists but can't tick" does not exist; showing it would make the screen lie.

Your choices don't get erased on their own

Sentinel remembers what you chose yourself, separately from what a dependency raised. When a cascade steps back down, it only lowers what you never set by hand.

Concretely: if you deliberately set Members to "View", turning off an unrelated switch later won't wipe it.

The guard that keeps you from locking yourself out

Sentinel refuses to remove role management from the last role that has it and has members. Without that guard, one bad move would make the Roles section permanently unreachable — nobody could undo it.

In the same spirit, editing your own role to remove your roles access triggers an explicit confirmation. Read it before clicking.

Assigning roles to your members

The Members tab of the Roles section shows a board: one column per role, one card per person. You change someone's role by dragging their card from one column to another.

Dropping someone into a privileged role — one that manages roles, billing or account settings — asks for confirmation. That's the kind of mistake nobody notices for a long time.

Changes are immediate: the person sees their permissions change without signing out, even while using the app.

Deleting a role

A deleted role doesn't take its members with it: they are reassigned to the base role (Viewer), and their new permissions apply right away. The base role itself can't be deleted.

Three pieces of advice

Start from a template. Pick Viewer, Editor or Admin, then adjust. Building from scratch walks you through inconsistent intermediate states that the cascade will fix behind your back.

Re-read the summary before saving. That's what it's for. If the characterisation at the top doesn't match what you intended, something got past you.

Don't create one role per person. A role describes a function, not an individual. If you're at seven roles for nine people, it's probably the activity or the group that needed adjusting, not the permissions.