Manage members
In a collaborative workspace, one accountable person manages who is in it and what they can do. Here is how.
Whoever holds workspace administration - usually the principal investigator - invites people, assigns each a role, and can change or remove them. Roles follow the project's governance; permissions follow the role.
Who manages members
Membership is managed by whoever holds workspace administration for that workspace. In most projects that is the principal investigator, who is accountable to the project's governance for who has access - but the role can sit with someone else, and your institution decides how it is assigned.
Everyone else works within the access they have been given. Members do not add or remove people, and cannot grant themselves more than their role carries.
Who can join, and with what role, is set by the project's rules rather than decided ad hoc. See the data access model.
Invite a member
Open the workspace members
In a collaborative workspace, open its Members settings.
Invite by identity
Add the person by their institutional identity.
Assign a role
Choose their role - the role sets what they can do.
Change someone's role
From the same Members settings, the workspace administrator can change a member's role at any time. Permissions follow the role, so the change takes effect straight away - there is nothing else to update, and no window in which the old permissions linger.
Roles are scoped to this workspace. Giving someone wider privileges here does not give them anything anywhere else on the platform, and does not follow them into another project.
Remove a member
The workspace administrator removes a member when they leave the project, and access is revoked immediately.
Removing someone does not remove what they contributed. Data they uploaded and results they produced belong to the project and stay in the workspace.
Why membership is not simply "whoever needs it"
It is tempting to add a helpful colleague for an afternoon. Two reasons not to.
The project was approved under specific terms, and those terms usually name who may see the data - not just how many people. Adding someone outside them can put the project's approval at risk, whatever the intention.
And access granted informally tends to outlive the reason for it. A workspace that accumulates members nobody can account for is exactly what the Five Safes model calls unsafe people, however trustworthy each of them is individually.
If someone genuinely needs access, the route is through the project's governance - which usually takes less time than people expect.
What each role can do
For the full breakdown, see Roles & permissions.