10: More on Permissions

Sharing & Access

Grant per-object access to items, workstreams, boards, and folders, and understand how sharing combines with organization roles.

Sharing answers the question "Who can open and edit this specific thing?" — it's the per-object half of DevStride's two access systems. Sharing an item, workstream, board, or folder with a person or a team is a lot like sharing a single document with a colleague: you decide exactly who's included and what they can do.

Sharing applies to work items, workstreams, boards, and folders. (Reports, Gantts, automations, and settings have no per-object sharing — access to those comes from your role alone.)

Why it helps: you can open one board to a single team without exposing everything else, keep a sensitive workstream private until it's ready, or give the whole organization view-only access to a shared plan — all without changing anyone's role.

Access levels

When you share an object, you choose a level for each person, team, or for the whole organization:

Level	What it allows
Viewer	View only — no changes.
Commenter	View and comment (on work items).
Editor	View and edit.
Owner	Full control, including managing who else has access. Assigned via Transfer Ownership.

Two related states also appear:

Inherited Owner — ownership passed down from a parent (for example a board inheriting its folder's owner). It reflects inherited ownership and can't be changed directly on the child.
Restricted — shown on the Organization row when organization-wide access is turned off, meaning only the users and teams you've explicitly added can reach the object.

The Manage Permissions dialog

Each object has a sharing status icon next to its name; its tooltip reads Share and Manage Permissions (or View Permissions if you only have read access). You can also open sharing from an object's kebab (⋯) menu → Permissions. Either opens the Manage Permissions dialog.

Inside the dialog:

In Add Access, search for users or teams, pick a level, and add them.
Change an existing grant with the level selector on its row, or choose Remove Access to revoke it.
Set the Organization row to give everyone in the organization a baseline level, or leave it Restricted to keep the object limited to the people and teams you've named.

Access is organized into three scopes: User Access, Team Access, and Organization Access.

Changes save as you go

You don't confirm a save — each change applies immediately. The Done button just closes the dialog.

Transferring ownership

Transfer Ownership appears only when you're the current owner. Use it to hand full control to someone else; you become an Editor afterward (unless your role already grants broader access).

Removing your own access

If you remove your own access while editing, you're dropped from the object and notified that you no longer have access. Make sure another owner or an administrator retains access first.

Inheritance

Children inherit their parent's sharing: a board inherits its folder's access, and items inherit from their workstream. You can override any scope by setting access directly on the child — a custom setting replaces the inherited value for that scope.

This is the part worth getting right. For items, workstreams, boards, and folders, sharing and your role are checked together:

Viewing and listing is governed by sharing. Your role doesn't grant you individual objects — being shared in does.
Editing, archiving, or deleting requires both a role that permits that action and a sufficient sharing level on the object (editing needs Editor; archiving or deleting needs Owner). The more restrictive of the two wins.
The "Manage all…" role overrides (for example Manage all items & workstreams or Manage all boards) bypass sharing entirely — a holder can act on every object of that type, even ones never shared with them. The Owner role and the default Admin role have these.

Why an administrator can see things you didn't share with them

It isn't a sharing setting — it's their role. The "Manage all…" overrides intentionally see past per-object sharing so administrators can manage everything. See Understanding Permissions for the full picture.

Changes take effect almost immediately

Sharing changes are broadcast to everyone connected, so access updates without a refresh. If a change removes your access, the object is pruned from your view and you're notified.

Object-specific details

Workstream & Item Permissions — sharing on work items and workstreams, including visibility on creation and participants.
Board & Folder Permissions — sharing on boards and folders, inheritance, and how board access shows up elsewhere.

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.

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.