Roles & Permissions

A role is an organization-wide set of capabilities. Every member is assigned exactly one role, and that role decides what they can do across DevStride — which features and actions they can use at all, independent of any single item. Roles are one of the two systems that control access; the other is per-object Sharing & Access.

The built-in roles

Every organization starts with three:

Build your own roles

Instead of being limited to the built-in Admin and Member tiers, you can create your own roles named for how your team actually works — "Reviewer," "Delivery Lead," "Finance," "Contractor," and so on. Each role is a tailored set of permissions you control, and you can adjust the built-in Admin and Member roles too.

You can also pin one role as the default role for new members, so everyone you invite starts in the right role automatically — no per-person setup.

Why it helps: new teammates are productive on day one with the right access, sensitive areas (billing, settings, reports) stay protected, and roles map to real responsibilities instead of forcing everyone into one of two buckets.

What a role is made of

You build a role in Configure Settings → Permissions from three kinds of control.

Module Access — what a person even sees

Per role, you decide which modules appear for a person — Map, Boards, Gantt, Reports, Automations, Items, Settings, and Templates. Turn a module off for a role and it simply disappears from those members' navigation.

Why it helps: a cleaner, less cluttered app for each person — they see the parts of DevStride that matter to their job, and nothing they don't.

Plugin menus

Enabled plugins appear in the navigation for every role by default. To take one away from a role, switch on that plugin's Hide control in the role's Module Access. It hides the menu entry only; it does not change any other permission, and roles you have not touched keep seeing every plugin.

Discrete permissions and templates

Under each area, roles are built from fine-grained, discrete permissions — create vs. manage your own vs. manage everyone's — per area: items & workstreams, comments, time entries, boards, Gantts, reports, automations, saved views, item templates, API keys, and every organization-settings area. ("Manage everyone's" is the administrative override that reaches everyone's content and bypasses per-object sharing.)

Apply a ready-made template like Manage work items, Manage templates, or View reports to set a sensible bundle in one click, then fine-tune the individual permissions from there. (If you later switch off one permission from an applied template, it's marked modified so it's clear it no longer matches exactly. Templates are a convenience in this screen only — what ultimately governs access is the set of permissions the role ends up with.)

Why it helps: you can grant precisely what a role needs — for example, "can comment but not delete others' comments," or "can view the Throughput report but not change settings" — without over-granting.

Example: the Item Templates area

The Item Templates group of the matrix shows how the pattern reads in practice. Each row is a permission and the description the screen shows for it:

Seeing the module at all is a separate Module Access switch, Templates — "Navigate to the Templates module." The Manage templates template bundles Create Item Template and Manage Own Item Templates, the everyday "manage your own" set; the admin override is granted on its own. The default Member role holds the module switch and the first two permissions, and Admin adds the third. For what each one unlocks inside the module, see the Templates overview.

Example: the Time Entries area

The Time Entries group has the same three-step shape — Create Time Entries, Manage Own Time Entries, Manage All Time Entries — plus one switch that sits above them: Time Entry Access. It is on for every role by default. Switch it off to remove every time-entry surface from that role — the item drawer's Time Tracking tab, the drawer sidebar's Time Spent control, the time-spent cell in the items table, and the time badge on board cards — and the three permissions beneath it turn off with it and stay unavailable ("Unavailable while Time Entry Access is off for this role") until you switch access back on. Switching it back on unlocks them without re-granting them. This is a screen-level control: it decides what the role sees in the app, not what the API returns.

How to manage roles and permissions

1. Open Configure Settings, then under Organization select Permissions.
2. Pick a role from the Roles rail on the left, or click New Role to create one. The Owner role is pinned at the top and locked — it always keeps full control.
3. Give the role a Name and Description. Apply a Template for a quick starting point, then refine in the permissions matrix below — toggle individual capabilities and switch whole Module Access controls on or off.
4. To make a role the one new members start in, open it and choose Set as default for new members.
5. Click Save changes. Before they apply, you'll see a summary of how many members are affected. (You can also Rename role or Delete role from the role's menu; the Owner role can't be renamed or deleted.)

How to assign a role to someone

1. Open Configure Settings, then under Organization select Users.
2. Find the member in the list.
3. Change their role in the Role column — they take on that role's permissions and module access across the organization right away.

Changes take effect almost immediately

When you change a role's permissions, or assign someone a new role, the change reaches affected members within seconds — they don't need to sign out or refresh. If a change removes access to something a member is currently viewing, it's removed from their view and they're notified.

How roles relate to sharing

Roles decide the kinds of actions you can take; Sharing & Access decides which specific objects you can take them on. For items, workstreams, boards, and folders, both are checked — see Understanding Permissions for how the two work together.