Roles and permissions

Everyone who works in the workspace app holds exactly one workspace role. A role is a name plus a set of permissions: which modules its holders can view, which they can act in, and a few named authorities such as hiring or seeing candidate contact details. A new workspace starts with only one role, the locked Workspace Admin. You build every other role yourself.

Every check happens on the server. When a role lacks a permission, the menu item or button is hidden, and the page or action is refused even if someone opens the link directly.

Where to manage roles

Settings → Users & roles (/{slug}/app/settings/team) has two tabs:

• Users: members, their roles and pending invitations. Holders of Users & roles view see it.
• Roles (/{slug}/app/settings/roles): the role list and editor. Only holders of Users & roles Act see it.

The list shows each role's name, a Locked badge on the Workspace Admin role, a My reporting line badge where that data scope applies, a summary of its modules, and how many users and pending invitations hold it.

A new workspace starts with Workspace Admin only

A new workspace has a single role: Workspace Admin (locked), which holds everything. Every other role is yours to build under Settings → Users & roles → Roles, with View or Act per module, named permissions and a data scope.

Workspaces created before this change keep the roles they already have. A workspace created from a source workspace copies the source's roles.

Roles you might build

These are common starting points, not built-in roles. Adjust them to how your team works:

The full permission list is in Roles and permissions matrix.

Modules: View and Act

Each module has two levels. View lets the role open the module's pages and read its records. Act (create, edit, delete) also lets it change them, and always includes View.

A junior team member usually gets View; a senior or the person who executes the work gets Act plus the named permissions their job needs.

Named permissions

Some operations carry legal or financial weight, so Act doesn't include them. Tick them one by one under their module:

For example, a recruiter role with Recruitment Act but without Hire candidates can run the whole pipeline but can't make the final hire. A workforce architect role can manage positions without being able to open hiring on them.

Data scope

Each role has a data scope:

• Whole workspace: the role sees every record its modules allow.
• My reporting line: in People and Development & Growth, the role sees only the holder's own reporting tree (direct and indirect reports, up to six levels). The holder's account must be linked to their person record. This covers the people directory and export, growth plans, assessment answers, case-study reviews, assessment reports and AI narratives, competency gaps, credential reviews and the training participation report.
• In the Data editor, the People sheet shows only the reporting line. Saving is refused if it edits or deletes someone outside the line, or adds or moves someone under a manager outside it.

Positions, candidates and the rest of the Functional Structure aren't limited by data scope. Pick My reporting line for a line-manager role.

The Workspace Admin role

Workspace Admin is the locked role. It always holds every permission, including any added in a future release, and it can't be renamed, edited or deleted.

• At least one active member must hold it. Removing, disabling or moving the last one is refused. Super admins' hidden accounts never count.
• Workspace Admins always sign in with two-factor, whatever the workspace setting.
• Only a Workspace Admin can assign the Workspace Admin role, or give a role Users & roles Act.

Creating and editing a role

1. Settings → Users & roles → Roles → New role.
2. Enter the Role name, an optional Arabic name (shown when the interface is in Arabic) and an optional Description.
3. Pick the Data scope.
4. Under Permissions, switch View or Act on per module and tick the named permissions you need. Turning Act on turns View on.
5. Save.

Guards that keep access from growing on its own:

• You can only tick permissions you hold yourself; the others are disabled with "You don't hold this permission".
• You can't edit the role you hold, or a role that has permissions you don't hold.
• A role can be deleted only when no user and no pending invitation holds it.

Changes apply on the holders' next click; nobody needs to sign out.

Assigning a role

A member has one role. You pick it when you invite them ("Staff (workspace role)" in the invite form) and change it from the Users tab. You can assign only roles whose permissions are all within your own, and you can't change, remove or reset the two-factor of a member whose role is above yours. See Team management.

Candidate contact visibility

A candidate's email, phone and national ID are shown only to roles holding See candidate contact details. For everyone else they are masked, for example a•••@domain.sa and 05•• ••• •12, so the person can see a value exists without reading it.

The mask applies everywhere staff see candidates: the pipeline cards, the candidate's profile, people lists, search, the referrals list, the trainer pipeline, the offer letter preview, exports (people and data editor) and the Audit log. It is applied on the server, so the real value never reaches a browser that can't show it.

• Contact details sent to AI features (CV screening, profile drafting) are removed before the request, for every role.
• A role without the permission can't change a candidate's contact fields; the edit form shows them disabled.
• Employees' contact details in People aren't masked: People view includes them.
• Candidates always see their own details in the candidate portal and in emails to them.

Workspace Admin always holds it. Tick it on any other role that needs to contact candidates.

Every change is recorded

Creating, editing and deleting a role, inviting a member and changing someone's role are all written to the Audit log with who did it, when, and what changed (for a role, the permissions added and removed).

Portal accounts aren't roles

Employee, Candidate and Trainer are account types, not workspace roles. They land in their own portals (/{slug}/me, the candidate portal, the trainer portal) and can't be given workspace permissions. A staff member who is also an employee keeps their self-service pages at /me.

Two-factor sign-in

Workspace Admins always sign in with a six-digit code. Every other role, and trainers, are asked when the workspace setting requires it (on by default), or if they turned it on themselves. Candidates never are. See Two-factor authentication and Requiring two-factor for your workspace.

Next

With the role model clear, the next pages walk through inviting people and what they see on the other end.