Team roles, permissions, and accountability
Assign the least access each person needs while preserving accountable work, sensitive administration, and clear responsibility across the organization.
Before you begin
- You are an owner or administrator authorized to manage people and permissions.
- The person’s responsibilities are defined before an invitation or role change.
- You understand that role changes affect the current organization, not every workspace the person belongs to.
- Critical operational responsibilities are assigned separately from broad software access.
Interface walkthrough
These annotated interface maps describe the current PMA controls. They do not replace a real record review in your workspace.
Choose the lowest role that supports the person’s real work. Do not use ownership as a convenience permission.
A role allows actions; an assignment identifies who is accountable for specific work.
Review the audit trail when investigating access or responsibility changes.
Step-by-step workflow
Define the person’s work
List the records they need to view, actions they need to perform, and administration they must control.
Choose the least sufficient role
Use viewer for read-only access, keeper for permitted husbandry work, manager for broader operational management, administrator for sensitive setup, and owner for ultimate organization control.
Send or review the invitation
Confirm the recipient identity, organization, role, and invitation status before considering access active.
Assign operational work
Use Guided Rounds, tasks, Continuity, Relay, BioShield, or other supported systems to identify concrete responsibilities.
Test the boundary
Verify the user can perform required work and cannot access restricted administration. Do not broaden the role without identifying the missing permission.
Review access regularly
Change or remove access when responsibilities change. Preserve audit evidence and transfer active work before removal.
Expected result
Each team member has an explicit organization role, access appropriate to their responsibilities, and separate operational assignments that can be reviewed and audited.
Safety boundaries
- Read-only roles must never gain write access through onboarding or Help & Learning.
- Do not share owner or administrator credentials.
- A role does not prove training, certification, or authority outside PMA.
- Removing a user must not silently erase their historical actions.
- Transfer critical responsibilities before access is removed.
Troubleshooting
The invitation was accepted but access is missing
Confirm the user opened the correct organization, the membership is active, and the role was saved. Refresh the session after role changes.
A keeper cannot complete a task
Check the task, record, and workflow permission. Increase access only when the work genuinely requires a broader role.
A former member still appears in history
This is expected. Historical evidence preserves the actor even after active access is removed.