Map Value: Workstreams and Work Items

Workstream & Item Permissions

Control who can view, comment on, edit, or manage your workstreams and work items at the user, team, and organization level.

DevStride lets you control exactly who can see and act on your workstreams and work items. Permissions are applied to each workstream and item individually, can be granted at the user, team, and organization level, and are inherited automatically by everything nested beneath a parent.

This page explains how to choose visibility when you create a workstream, how to change access later, how inheritance works, and how DevStride resolves overlapping permissions.

Part of a two-layer model

The grants on this page are DevStride's Sharing layer (per-object access). They work alongside your organization role, which decides what kinds of action you can take anywhere. For the full picture, see Understanding Permissions; for sharing in general, see Sharing & Access.

Permission levels

Every workstream and work item supports the following access levels:

Viewer — Only view.
Commenter — View and comment.
Editor — View, comment, and edit.
Owner — Full control, including the ability to manage permissions, transfer ownership, and delete.

You will also see two display-only states that DevStride applies automatically:

Inherited Owner — The same powers as an Owner, but the ownership comes from an ancestor workstream rather than being set directly on the item.
Restricted — Access has been explicitly removed. The organization row shows Restricted when organization-wide access has been revoked.

Who can change permissions

To manage permissions on a workstream or item, you need Editor or Owner access to it. Separately, roles with the Manage all items & workstreams permission — the organization Owner role and the default Admin role — have full access to every workstream and item and can always manage permissions and transfer ownership, regardless of sharing.

Choosing visibility when you create a workstream

When you create a new top-level (root) workstream, the create dialog includes a Visibility section with two choices:

Public — anyone in {Organization} — "All organization members can view and edit immediately." Choosing this grants every member of your organization Editor access right away.
Private — only to you — "Start private, then invite specific users, teams, or set organization-level permissions later." Choosing this keeps the workstream visible only to you (the owner) until you add access.

The dialog is titled Create a Workstream, and the button to confirm is Save New.

The Visibility chooser appears only for root workstreams

The Public / Private radio group only appears when you create a new top-level workstream. For nested workstreams and for all work items, the create dialog instead shows a Permissions note explaining that "Workstreams inherit permissions from the selected location" (or "Items inherit permissions from the selected location" when you are creating an item). There is no Public/Private choice for child workstreams or items — they take their access from their parent. You can adjust their permissions after they are created.

Each workstream and work item drawer has a sharing and permissions status icon in its sub-header. Hovering it shows the tooltip Share and Manage Permissions (or View Permissions if you only have read access). Clicking it opens the Manage Permissions dialog.

This icon is not a padlock. It changes shape to reflect the current sharing state:

Person icon — Private. "Only visible to you."
People icon — Shared. "Shared with specific users or teams."
Organization icon — Organization. "Shared with organization."

Changing access later

To change permissions on any workstream or item:

Open the workstream or item drawer.
Click the sharing status icon in the drawer sub-header to open the Manage Permissions dialog.

The dialog is organized into the following sections:

Add Access — Use the search box ("Search for users or teams...") to find a user or team, choose a level, and click Add.
User Access — The individual users with access and their levels.
Team Access — The teams with access and their levels.
Organization Access — A single row (labeled with your organization name, or Organization Members if no name is set) that sets the access level for everyone in the organization. Choosing Remove Access here sets the organization to Restricted.
Participants — Shown on work items only. This lists the people connected to the item with tags such as Creator, Assignee, Subitem Assignee, and Watcher.

For each user or team, the level options are Viewer (Only view), Commenter (View, comment), Editor (View, comment, edit), and Remove Access (sets that entry to Restricted). Owners also see Transfer Ownership on a user entry.

Click Done when you are finished.

Making a private workstream shared

Because a private workstream starts visible only to you, you make it shared the same way you change any other permission: open the Manage Permissions dialog and either grant Organization Access a level, or add specific users and teams under Add Access. As soon as access is granted to anyone, the sharing status icon updates from the person (private) state to the people or organization state.

Restricting access to a public workstream

To narrow a public workstream, open the Manage Permissions dialog and lower or remove the Organization Access level — for example, set the organization to Viewer, or choose Remove Access to set it to Restricted. You can then grant specific teams or users a higher level under Add Access so only the right people retain edit rights.

You cannot remove your own access when you're the only one

If you are the only user with access to a workstream or item, the access-level control for your own entry is disabled — you cannot remove or change your own access until at least one other user has been given access.

Transferring ownership

The current owner (or anyone whose role grants Manage all items & workstreams) can reassign ownership by choosing Transfer Ownership on a user in the User Access section. When ownership transfers, the previous owner is demoted to Editor.

How inheritance works

Children automatically inherit the permissions of their parent. A work item nested under a workstream, a sub-item nested under an item, and a nested workstream all begin with whatever access their parent has.

When permissions propagate down to children, any Owner is shown on the child as Inherited Owner — the same powers as Owner, but flagged as coming from an ancestor.

Effective access on a child is the combination of what it inherits from its parent and any custom permissions set directly on it. Setting permissions on a child layers on top of the inherited access, and a custom entry on the child overrides the inherited entry for that same user, team, or organization.

How overlapping permissions are resolved

A person can be granted access in more than one way at once — directly as a user, through one or more teams they belong to, and through the organization-wide level. DevStride combines these with inclusive OR logic: the most-permissive grant wins.

In practice, this means a person gets the highest level granted by any of their applicable user, team, or organization assignments.

A higher team or organization level can override an individual restriction

Because access is evaluated as a pure OR across user, team, and organization, a higher team or organization level can still grant access even when that person's individual entry is lower — or even when their individual entry has been set to Remove Access. For example, a user set to Viewer as an individual who is also on a team granted Editor will still be able to edit.

To truly limit an individual, do not rely on a lower (or removed) individual entry alone. Instead, remove them from the team that grants the broader access, lower the organization-wide level, or grant access individually rather than at the team level.

What each level can do

The access level controls which actions a person can take:

Read / view — Viewer or higher.
Comment — Commenter or higher.
Edit / update — Editor or higher.
Archive / delete — the item's Owner or Inherited Owner, plus administrators (see the Manage all override below).

Who can delete — and why not Editors

Two kinds of people can archive or delete a workstream or item: its Owner (or Inherited Owner), and administrators — roles that include the Manage all items & workstreams override (the Owner role and the default Admin role, covered in the next section).

Editors are deliberately left out. A workstream or item can contain children that an Editor doesn't have access to, so letting an Editor delete could remove work they can't even see.

The "Manage all" administrative override

Some roles include the Manage all items & workstreams permission, an administrative override that bypasses the per-object access on this page entirely. A role that has it can view, comment, edit, manage permissions, transfer ownership, archive, and delete every workstream and item in the organization — regardless of how individual sharing is configured.

The Owner role always has this, and the default Admin role ships with it. Because roles are customizable in Configure Settings → Permissions, a role can be tuned to include or exclude this override; a role without it can only act on items shared with it (and can only archive or delete items it owns).

Creating Items
Board & Folder Permissions — the boards and folders counterpart to these item and workstream controls.
Understanding Permissions — how roles and sharing combine across DevStride.
Roles & Permissions — organization roles and the "Manage all" overrides referenced above.

Dependency Graph

Visualize an item's blocking relationships on an infinite canvas, with zoom, color coding, and a Center-on dropdown.

Import Templates

Build out whole workstreams at once from a reusable Excel template — export a template, fill it in, preview the result, and import.