Most beta programs have more people watching than running them. A product manager builds the beta, an engineer reads the bug reports, support wants to know what's coming their way, and someone in the leadership team checks in once a month.
Give all of them the same access and sooner or later a live beta gets edited by someone who only meant to have a look. That's what the three workspace roles are for.
In this article
- The three roles
- Roles do not grant access to a beta
- Change someone's role
- Who is allowed to change roles
- Choosing the right role
The three roles
Everyone in your workspace holds one of three roles.
Admins have full control, including other people's roles and workspace settings like branding. Managers do the actual work of running betas: creating projects, inviting testers, editing tasks, publishing changes, handling tickets. Viewers can only read. They see tickets, results, your published betas, and the tasks and steps behind them, with no editing controls anywhere.
Viewer is the role most teams forget they have. It costs nothing to hand out, it can't break anything, and it turns "can you send me an update?" into something the person sorts out themselves. And because viewers can now read the tasks and steps as well as the results, a stakeholder can see the question you put to testers next to the answer that came back.
Roles do not grant access to a beta
Here's the part that surprises people, and it's worth being clear about before you start assigning roles.
A role describes what you can do inside a beta you're already on. It doesn't put you on any beta. That's handled per beta, by invitation, from the beta's Managers area, and somebody already on it has to add you.
Admins included. An Admin can't join a beta they weren't invited to. There's no override, no unlock, no workspace switch that grants it. A beta you're not on won't appear in your projects list, and a direct link to it comes back as nothing found rather than access denied. You might come across its name where the workspace refers to it, but that's as far as it goes.
Which is on purpose. Beta programs tend to involve unreleased hardware, roadmaps nobody's announced yet, and feedback given under an NDA, so "anyone senior can read everything" is a bad default. It also leaves the person running a beta in charge of who sees it, rather than that following from who happens to hold an Admin seat.
Practically, this means a colleague who can't find a beta rarely needs a role change. Promoting them to Admin won't do it. Someone already on the beta has to add them.
Change someone's role
Roles live in your workspace settings under Permissions, where everyone in the workspace is listed with their name, email and a role selector.
Change the selector and it takes effect straight away, with a confirmation that permissions were updated. There's no save button to hunt for.
The Permissions page listing workspace members with a role selector for each
Who is allowed to change roles
The rules here are tighter than on most settings pages, which explains a greyed-out selector when you run into one.
You can't change your own role, so the last admin can't accidentally demote themselves and lock everyone out of the workspace. Viewers can't change anybody's role, which follows from the role being read-only. And a Manager can only change someone who's currently a Viewer, so promoting anyone to Manager or Admin, or demoting them, is an Admin job.
The net effect is that admins own the team roster, while a manager can still bring a viewer up to speed without waiting on one.
Choosing the right role
Quick way to decide. If they'll build or run a beta, invite testers or answer tickets, they're a Manager. If they only need to read what's going on, Viewer. If they need to manage the team, billing or branding, Admin.
That's only half the decision, though. Whatever role you give them, they still need adding to each beta you want them to see.
When you're not sure, start with Viewer. Moving someone up later is one click, and the two mistakes aren't equally expensive: give someone too much access and they can publish a half-finished change to a live beta, give them too little and they send you a message asking for more.
If your workspace uses SSO, you can assign roles at provisioning time instead of by hand. Setup SSO with Okta covers mapping a user attribute to a Stomio role.