2026-06-12

🔐 Role-Based Access Control (RBAC)

DevStride now gives organization owners precise, role-based control over what every member can see and do — layered cleanly on top of the sharing model you already use.

🤝 Two kinds of permission, working together

DevStride now has two complementary permission systems, and it helps to know the difference:

• Sharing (ACL — Access Control List): "Who can open and edit this specific thing?" You've had this for a while. When you share a workstream, an item, or a board with a person or a team, you're using sharing. It's per-object — like sharing a single document with a colleague.
• Roles (RBAC — Role-Based Access Control): "What is this person allowed to do across the whole organization?" This is new. A role decides which features and actions someone can use at all — for example, whether they can create boards, view reports, manage billing, or change org settings — independent of any one item.

The simplest way to hold both in your head: sharing controls access to a thing; roles control access to a capability. A member might be shared into a board (sharing) but still not be allowed to open the Reports module or manage cadences (roles). Both checks run together, so people get exactly the access they should — no more, no less.

👥 Build your own roles, with a pinned default

Instead of being limited to fixed "Admin" and "Member" tiers, you can now 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.

You can also pin one role as the default for new invites, so everyone you add to the organization automatically starts in the right role — no manual setup per person.

Why it helps your daily workflow: new teammates land productive on day one with the right access, sensitive areas (billing, settings, reports) stay protected, and you can shape roles around real responsibilities instead of squeezing everyone into one of two buckets.

🧭 Module Access controls

You can decide, per role, which modules even appear for a person — Map, Boards, Gantt, Reports, Automations, Items, and Settings. If a role doesn't need Reports, you can simply turn the whole module off for it, and it disappears from their 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

Under each module, 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, and every org-settings area). Apply a ready-made template like "Manage work items" or "View reports" to set a sensible bundle in one click, then fine-tune individual toggles from there.

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. Go to Settings → Organization → Permissions.
2. Pick a role from the list on the left (or click + New role to create one). The Owner role is pinned and locked — it always retains full control.
3. Use the Templates section to apply a sensible bundle in one click, then refine in the permissions matrix below — toggle individual capabilities, and switch whole Module Access controls on or off.
4. To set the role new members start in, open the role you want and set it as the Default for new invites (the pinned chip).
5. Save. You'll see a clear summary of who's affected before changes apply.

🙋 How to assign roles to people

1. Go to Settings → Organization → Users.
2. Find the member you want to update.
3. Change their role — they immediately take on that role's permissions and module access across the organization.