Sharing & Access

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:

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:

1. In Add Access, search for users or teams, pick a level, and add them.
2. Change an existing grant with the level selector on its row, or choose Remove Access to revoke it.
3. 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.

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

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.

How sharing combines with roles

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.

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.