Set up users, roles & permissions

An end-to-end walkthrough — define roles and their permissions, organize users into groups, invite people in, and keep access current.

Before anyone can work, they need an account and the right level of access — and in a regulated system, who can do what is itself part of the controls. This guide sets up access from the ground up: the roles that define capability, the groups that organize people, and the invitations that bring them in. For the concepts behind each step, see Users, Groups, and Roles & permissions.

Define roles & permissions

Roles describe what a kind of user can do. Set these up first so there’s something to assign when you invite people.

Before you start Open Administration and go to Roles & permissions. You'll need administrator access.

  1. Review the system roles, and create the additional roles your organization needs.
  2. For each role, set its Permission Matrix — the actions it's allowed across the modules and administrative areas.
  3. Set the Access Level where it applies — for example Full Access versus Read Only.
  4. Save the role.

Result A set of roles whose permissions are explicit and enforced — the foundation for least-privilege access. See Roles & permissions.

Organize users into groups

Groups are reusable sets of people — a team, a department, a review board. Granting access to a group is easier to maintain than granting it person by person.

  1. Choose Create Group and give it a Group Name.
  2. Add its Members.
  3. Use the group wherever access is assigned, so adding someone to the group grants everything the group has.

Result Reusable groups that make access grants consistent and easy to update. See Groups.

Invite users

Before you start Have the person's email and know the role they should start with.

  1. Choose Invite User.
  2. Enter their Email Address, assign a Role, and set the License Type.
  3. Add a personal message if you like, and send the invitation.

Result A secure invitation link is sent. The account shows as Pending until they accept, then becomes Active. See Users.

Keep access current

  1. Change a user's role or group membership as their responsibilities change.
  2. Deactivate accounts when someone leaves — deactivating preserves their history in the audit trail rather than erasing it.

Result Access stays aligned to who actually needs it, and every change is recorded.

Note This sets system-wide access. Access within a specific project is layered on top of it — see Project permissions and the per-project setup in Set up a project. For how a user's effective permissions are resolved from all of these, see Access rules.

Where to go next

With people and access in place, configure what they’ll work with — see Item types & fields and Workflows.

Was this helpful?