Permissions

Understanding Permissions

How DevStride controls access with two complementary systems — Sharing (access to a thing) and Roles (access to a capability) — and how they work together.

DevStride controls access with two complementary systems that work together. Knowing the difference between them is the key to everything else in this section.

System	The question it answers	Think of it as	Set where
Sharing	"Who can open and edit this specific thing?"	Sharing a single document with a colleague	The Manage Permissions dialog on each item, workstream, board, or folder
Roles	"What is this person allowed to do across the whole organization?"	A job description — which features someone can use at all	Configure Settings → Permissions

The simplest way to hold both in your head: sharing controls access to a thing; roles control access to a capability.

Sharing is per-object. When you share a workstream, item, or board with a person or a team, you choose whether they can view, comment on, edit, or own that one thing.
Roles are organization-wide. A role decides which features someone can use at all — whether they can create boards, view reports, manage billing, or change settings — independent of any single item.

How the two work together

Both checks run together, so people get exactly the access they should — no more, no less. A teammate might be shared into a board (sharing) but still not be able to open the Reports module or manage cadences, because their role doesn't allow it.

A bit more precisely:

Seeing and opening a specific item, workstream, board, or folder is governed by Sharing. Your role doesn't hand you individual objects — sharing does.
Doing something with it (edit, archive, delete) needs both: your role must permit that kind of action, and you must have a high enough sharing level on that object. The more restrictive of the two wins.
A few areas — reports, Gantts, automations, and settings — have no per-object sharing. Access to those is decided by your role alone.

A quick way to think about it

Your role opens the door to a type of work. Sharing decides which individual things you can walk up to. You need both: the right kind of key, and access to that particular room.

The Owner role is always all-access

Every organization has exactly one Owner — a built-in role with full access to everything. The Owner role can't be deleted or stripped of permissions, which guarantees there's always someone who can administer the organization.

Administrative overrides

Some roles include "Manage all…" permissions (for example Manage all items & workstreams or Manage all boards). These are administrative overrides: they let a role act on every object of that type, bypassing per-object sharing. The Owner always has these, the default Admin role has them, and you can grant them to a custom role. This is how an administrator can manage content that was never explicitly shared with them.

Changes take effect almost immediately

When a role's permissions change, or an object is shared or unshared, the change reaches affected people within seconds — no sign-out or page refresh required. If a change removes your access to something you're viewing, it's pruned from your view and you're notified.

Where to go next

Roles & Permissions — build roles and choose what each can do, in Configure Settings → Permissions.
Sharing & Access — grant access to individual items, workstreams, boards, and folders.

For the object-specific details, see Workstream & Item Permissions and Board & Folder Permissions.

API Keys

Create and manage API keys for programmatic access to DevStride, and — for administrators — view and revoke every member's keys across the organization.

Roles & Permissions

Build roles that decide what each member can do across DevStride — module access, discrete permissions, and a default role for new members — in Configure Settings → Permissions.