Permission models fail in one of two directions. Too granular and nobody configures them correctly, so everyone ends up an administrator and the model is decorative. Too coarse and people are blocked from work they legitimately need to do, so they share logins.
ReqLens uses three roles, deliberately few, and ranks them rather than treating them as unrelated buckets.
Three roles, ranked
Viewer, member, owner, in ascending order of access.
Ranking matters more than it sounds. When a check asks whether someone has at least member access, an owner satisfies it automatically because owner outranks member. There is no matrix of role against capability to maintain, and no possibility of an owner being unable to do something a member can, which is the classic bug in flat permission models.
- Viewer. Reads everything in scope. Writes nothing. The right role for a stakeholder who needs visibility into coverage and readiness without touching artefacts.
- Member. The working role. Creates and edits requirements, elaborations, test cases, runs, and defects. This is where most of a delivery team sits.
- Owner. Everything a member can do, plus workspace administration: membership, billing, and settings.
Read is wide, write is scoped
The general shape is that reading is permissive and writing is not.
This is a deliberate bias. A requirements platform whose value is shared understanding fails if half the team cannot see the requirement. Most of the harm in a delivery tool comes from unexpected changes, not from unexpected reads, so the restriction sits where the risk is.
Adding a stakeholder as a viewer costs you nothing and removes a whole class of "can you send me the latest" requests. It is usually the right default for anyone outside the delivery team.
Projects, and how access resolves
Workspaces contain projects, and a person can have a role within a project as well as within the workspace.
The resolution rule is that a workspace owner carries their access across every project. They do not need to be added individually to each one, and they cannot be locked out of a project inside their own workspace. Below that, project membership determines the role; someone with no explicit project role resolves to viewer rather than to nothing, which keeps the read-wide bias intact.
Teams sit inside this as a grouping construct, with team administration restricted to workspace owners and team leads rather than to any member.
What belongs to the workspace rather than to a person
A recurring design decision, and the one most likely to matter to you in practice: things set up by a person belong to the organisation.
The clearest case is an integration. Someone enters the credentials, but the connection belongs to the workspace. It survives that person leaving, and it is not silently duplicated per member. The alternative, credentials scoped to whoever typed them, produces an integration that breaks on a departure and a support conversation nobody wants.
The same logic runs through shared artefacts. Work is created by a person and owned by the workspace, so continuity does not depend on individual accounts remaining active.
Key takeaways
- Three ranked roles rather than a capability matrix, so higher roles automatically satisfy lower checks.
- Reading is wide and writing is scoped, because unexpected changes cause more harm than unexpected reads.
- Workspace owners carry access into every project; no explicit project role resolves to viewer.
- Integrations and shared artefacts belong to the workspace, so they survive people leaving.
Choosing roles for a delivery team
A workable default for a standard team:
- Owner: one or two people. Usually whoever is accountable for the account and for who has access. More owners is not safer, it is just more people who can change membership.
- Member: the Business Analysts, QA Engineers, Product Owners and Delivery Managers doing the work. All four roles need to write, in different places.
- Viewer: stakeholders, adjacent teams, anyone who reads readiness and coverage but does not produce artefacts.
Resist the pull toward making everyone an owner because a permission got in the way once. If members are regularly blocked, that is worth reporting as a scoping problem rather than solving by promotion, because promotion solves it in a way that removes the model entirely.