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, and Settings. 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.

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, 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 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.

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.