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 Organization → Roles.

3:41

Two tabs: Simple and Advanced

The editor opens on the Simple tab. Instead of 24 technical settings, it shows what the person will be able to do in the app, in plain sentences: "Create and edit tasks", "Log time", "Invite members"… Sentinel sets the matching permissions on its own.

Actions are sorted into ten sections, in the order of the sidebar: Tasks and projects, Time, Structures, Checklists, Conversations and follow-up, Trails, Trail conditions, Public reports, Team and Account.

When an action needs another one, the app tells you first: under "Invite members", a chip reads "Will also enable Manage members and their timesheets". The other way round, removing an action that others depend on lists what will go with it, and nothing changes until you confirm.

The Advanced tab keeps the detailed, level-by-level editor described in the rest of this page. Sentinel remembers the tab you picked. If a role carries settings that only the Advanced tab can show, a note says so below the sections.

Read a role before editing it

This section and the following ones describe the Advanced tab.

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

All sixteen 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-four controls

Sixteen three-level selectors — None, View, Edit — for the big domains: Tasks, Projects, Structures, Structure reports, Checklists, Public reports, Trails & Configuration, Trail Conditions, Public reports settings, Work roles, Members, Groups, Roles, Invitations, Billing, Administration.

Eight switches for specific capabilities attached to those domains: Time, Costs ($), Bulk edit, Export, Check off items, Conversations, Dashboard, Planning.

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, Work roles, Billing and Administration. They're the only ones you can set in isolation without side effects.

"Trails & Configuration" at View: what it grants, and what it doesn't

This is the line that surprises people most, because it stays at View even on the Viewer template, and you can't drop it to None while the person can see tasks or structures.

It's harmless. At View, this line opens no screen at all. The Trails, Activities, Difficulties, Task types and Structure types pages all require the Edit level: a Viewer sees none of them in the menu, and can't reach them any other way.

Nor does it change what the person sees elsewhere: trail colours on the map and structure types in the filters and detail sheets show for every member, whatever their role. The colour comes from the difficulties you configure.

The rule to remember: to stop someone from touching trail configuration, leave this line at View. That's already what it does. Edit is the step that actually opens the configuration screens.

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.

Members, Groups and Roles at View: no screen either

Same logic for the three team lines. The Viewer and Editor templates leave them at View, and at that level the Members, Roles and Groups sections don't appear in the menu. Like everything in the sidebar's Organization universe, they need Edit.

What View allows is working with the team without managing it: finding colleagues and groups in a task's Assigned to field, for example.

In practice: for someone to manage the team, set Members to Edit. Add Roles at Edit only if they also need to touch permissions, and Groups at Edit if they put the groups together.

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.