For Organisation Administrators: licensed Collaborators with the relevant organisation-wide permissions.
What you will achieve
Create a named role, give it the permissions it needs and check the effect on a member. A role is a reusable set of access permissions, not a licence or an audience.
Before you start
Use the correct organisation and an account authorised to manage roles. Agree the work this role should allow and the work it should not allow. Choose a willing test member with an appropriate licence; do not test by granting broad administrator access.
For example, Northstar Works might need a policy editor who can maintain policies without managing organisation membership.
Create the role
- Open Settings > Organisation > Membership > Roles.
- Review existing names and descriptions. Reuse an appropriate role rather than creating a near-duplicate.
- Select Add Role. Enter a clear Role Name and describe the responsibilities and boundaries in Description.
- Review the generated Slug. Use a stable, URL-friendly identifier; it is not the reader-facing job title.
- Select Create Role. Reopen the new role through View details.
- Open Permissions in the role details. Select only the agreed permissions and select Save Changes. Wait for a successful save. Creation of the named role does not itself establish its permissions.
- Open Users and review existing assignments. Under Assign Users, search for the agreed test member. Selecting the person assigns the role immediately; check their identity before selecting. Verify the saved assignment and the member's effective access.
Check it worked
Reload Roles and reopen the record. Check its name, description, permissions and assigned-user count. Run Access troubleshooting for the test member and a relevant page, then ask the member to try the actual authorised task in their own session.
Also test a task they should not be allowed to perform. Page access alone does not prove every record-level action is permitted.
Maintain or retire a role
Use Edit role to update the name or description. Before changing permissions, review everyone assigned to the role: the change affects the role, not just the person who reported a problem.
Deletion is not a tidy-up shortcut. Delete role warns that assigned users lose the role assignment and that the action cannot be undone. Reassign any necessary access first, obtain approval and verify affected users afterwards. Preserve another authorised administrator's access.
If something goes wrong
| What you see | What to check |
|---|---|
| The role exists but the member still cannot act | Permissions, membership, licence, feature availability and the specific record's access rules |
| The member can do more than expected | Other roles and direct grants; removing one role may not remove overlapping access |
| A save is rejected | Keep the error, correct the named field and reload before retrying |
| Access changes unexpectedly | Compare the previous role permission set and reverse only the approved change |
Human judgement matters
Role names do not enforce responsibilities by themselves. Keep the description understandable, but verify the actual permission set. Do not assign administrator permissions simply to make an error disappear.
What next?
For the wider context, see Manage members, roles and access.
Use the access-diagnosis task guide before expanding a role. Keep the role's agreed purpose and review owner in your organisation's access-management records.
Get help
Contact your organisation's support route with this guide reference, the affected page and a sanitised error. Do not include passwords, keys or session details.