Summary
You give access to a workspace by adding members, each with a role: viewer, editor or owner. That role applies to every project in the workspace — and any project can override it for someone, including hiding the project from them entirely.
This page assumes server mode
Accounts, roles and access rights only exist with a backend. In the browser, working alone on your own machine, the question does not arise — see Deployment modes.
The roles
A member is given one of these roles, from the most restricted to the broadest.
No access
The resource is hidden. Mostly useful as an override, to take one specific project away from someone without touching the rest.
Viewer
Reads dashboards, cohorts, documentation. Changes nothing. This is the role for people you present work to.
Editor
Creates and changes content: projects, cohorts, datasets, dashboards, code. The role for those who produce the work.
Owner
All of the above, plus running the workspace: adding members, configuring language models, deleting the workspace.
Inheritance into projects
This is what saves you from configuring every project separately: a role given on the workspace applies in all of its projects. Adding someone as an editor makes them an editor everywhere.
That default suits most teams. When it does not, a project can override someone’s role: the override wins over inheritance, for that project only.
Two common overrides
A workspace viewer becomes an editor on the one project they actually work on.
An editor drops to no access on a project whose data is closed to them — the project then disappears from their view.
Custom roles
The four base roles cover most situations, but their boundaries are not always your institution’s. So you can create roles and choose precisely what they allow, resource by resource.
Roles come in two scopes that should not be confused.
- Workspace and project role — what a member can do inside a workspace. That is the one this page is about.
- Global role — what a person can do to the instance: manage accounts, manage the roles themselves, change configuration. See Authentication and permissions.
System roles cannot be changed
Viewer, editor and owner ship with Linkr and cannot be redefined — a role everything rests on must not be able to change meaning under your feet. For a different split, create a role alongside them.
Going further
- Settings — the other workspace settings.
- Authentication and permissions — accounts and global roles, on the administration side.