Understanding user groups and permissions

Last updated: July 29, 2026

Every user's access in Onboarded comes from the user groups they belong to. This article explains how groups, permissions, and access rules combine to control who can see and do what.

What it is

Onboarded doesn't assign roles to individual users. Instead, you add each user to one or more user groups, and every group carries two things:

  • Permissions — the actions members of the group can take, per entity type: view, create, edit, and delete for Employees, Jobs, Tasks, Placements, Employers, and Clients, plus admin-level areas like Forms and Policies.

  • Access rules — optional conditions that narrow which records those permissions apply to.

If you remember nothing else: permissions decide what a user can do, and access rules decide which records they can do it to.

Why it matters

Group membership is the only lever you have over what a teammate sees and does in your account. Understanding the model matters most when:

  • You want to delegate day-to-day work — editing candidates, working tasks — without handing out the ability to delete records or change forms and policies.

  • Different teams should only see their own slice of the data, like a regional team that manages candidates for one market.

  • Someone reports they can't see a record or a button they expect, and you need to reason about which group is (or isn't) granting it.

How it works

The built-in groups

Every account starts with two groups:

  • Admins — every permission, including the admin-level ones: managing Forms, Policies, User Groups, Custom Views, and API Tokens.

  • Members — view, create, edit, and delete on the day-to-day entities: Employees, Jobs, Tasks, Placements, Employers, and Clients.

Neither group starts with access rules, so members see all records for the entities they're granted. You can edit both groups, or create your own alongside them.

Permissions

Each permission pairs an entity with an action — View Employees, Edit Employees, Create Jobs, Delete Tasks, and so on. Edit, create, and delete each depend on the matching view permission: you can't grant Edit Employees to a group that doesn't also have View Employees — the group won't save.

Admin-level permissions (Forms, Policies, User Groups, Custom Views, API Tokens) follow the same pattern but sit outside the default Members set. Granting them is what separates a working group from an admin group.

Access rules

Access rules are conditions evaluated against each record — for example, employee.custom_attributes.region is Central. A group with that rule and View Employees sees only candidates whose region is Central.

Two things to know in practice:

  • Rules can only reference properties marked as a permission scope. If a property you expect isn't available in the rule builder, open it under your custom attributes settings and turn on Permission Scope.

  • Leaving the rules empty is valid — you don't need a placeholder condition to save a group.

Granting a permission without any access rule condition for that entity grants access to all records of that type. If a group is meant to see only a slice of your data, confirm every entity it has permissions for is covered by a rule.

How access is decided

When a user acts on a record, Onboarded checks each of their groups in turn. If any group grants the action on that record, it's allowed — the most permissive group wins. That cuts both ways: adding a tight access rule to one group won't restrict a user who also belongs to Admins, because Admins still grants everything.

Where you manage all this

User management lives under Organization Settings → User Management, with three tabs: Users, Groups, and Invitations. From there you can Invite User or Create Group. Every invitation requires at least one user group — the invitee's memberships take effect as soon as they register. Groups also determine which data views a user sees: you add groups to a data view, and its members get the view.

Example

Take an account that staffs light-industrial jobs across two regions and wants regional coordinators to manage candidates without the ability to delete anything.

The HR Engineer creates a group called Central coordinators with the permissions View Employees, Edit Employees, View Tasks, and Edit Tasks, and one access rule: employee.custom_attributes.region is Central. Coordinators in that group can update candidate records and work onboarding tasks for the Central region. They can't delete records, can't see the other region's candidates, and can't touch Forms or Policies — those live behind admin-level permissions they were never granted.

When a coordinator later takes on account administration, no group surgery is needed: adding them to Admins grants everything, because access is the union of all their groups.