Team and permissions

Team management is the surface for everything that happens to user accounts after the initial invitation: adding new members, changing their workspace role, revoking access, recovering accounts on behalf of someone who has lost theirs. It is the Users tab of Settings → Users & roles; the Roles tab next to it is covered in Roles and permissions.

Where to find it

/{slug}/app/settings/team. Roles holding Users & roles view see the page. Inviting, changing a role and removing a member need Invite people and assign roles or Users & roles Act; two-factor resets and the CSV import need Act. A new workspace has only the Workspace Admin role, so at first only Workspace Admins can invite.

What is on the page

Three tables, top to bottom:

• Active members — every person with an accepted account in this workspace, with their role, last sign-in date, and a small action menu.
• Pending invitations — invitations that have been sent but not yet accepted. The token expiry date is shown for each.
• Removed members — people who used to have access but have been removed. Their record is preserved for audit; reactivation requires a fresh invitation.

Inviting someone

The invite form's role picker has two groups:

• Staff (workspace role): the workspace roles you may assign. A new workspace has only Workspace Admin; every other role is one your workspace built under Roles. Build your roles before inviting your team, otherwise Workspace Admin is the only staff role you can give. Staff land at /{slug}/app and see what their role allows.
• Portal access: Employee, Candidate or Trainer. These people land in their own portal.

Which roles you can assign

You can assign only roles whose permissions are all within your own. A role that manages users and roles (Users & roles Act), and the Workspace Admin role, can be assigned only by a Workspace Admin. The picker shows only the roles you may assign. For example, if you built a recruiting role and a read-only junior recruiting role, a member on the recruiting role can invite the junior one, but not a line-manager role that holds Development & Growth, which the recruiting role doesn't.

Active members — what you can do

The role column shows each member's workspace role (its Arabic name in the Arabic interface), their portal type, or No role. The role filter and the "by role" sort use the workspace roles. A member whose role is above yours shows their role as a badge, without the picker or the delete action.

For each active member you can:

• Change role. Pick another workspace role, subject to the same rule as inviting. Their open sessions end on their next click, and they sign in again under the new role. Editing a role's permissions doesn't sign anyone out: the change applies on their next click.
• Reset two-factor (Users & roles Act). For someone who lost their authenticator app.
• Delete account. The trash icon on a member row permanently deletes that member's account after a confirmation — their login and personal data are erased and they lose access immediately. Three rules apply: you can never delete your own account (the icon is hidden on your row); the last active Workspace Admin cannot be deleted (a workspace must always keep one); and a member who has authored load-bearing records — development-plan actions, competency recommendations, credentials, projects, or plugin manifests — cannot be deleted, so history is never silently destroyed. In that case remove or reassign those records first. Deleting the account leaves the person's roster record on /people intact; delete that separately if you also want them off the roster.

A line manager's team comes from the manager set on each person record, not from the Team page.

Pending invitations — what you can do

• Cancel (revoke). The trash icon on a pending-invitation row deletes the invitation after a confirmation. Its magic link stops working immediately, so the recipient can no longer accept it. Cancelling only affects invitations that have not yet been accepted — once someone has accepted, they are an active member and are managed from the Active members table instead. You can always send a fresh invitation to the same email afterwards.

Removed members — why they are kept

Audit. If someone was a Workspace Admin a year ago and made workspace-changing decisions, their authorship needs to remain visible on those decisions even if they have left. The removed-members table is the reference, and every invitation, role change and removal is also in the Audit log.

You cannot delete a removed member's record in v0.5; account deletion (full erasure under PDPL data-subject rights) is on the v0.6 watch list and requires careful sequencing of audit-trail preservation.

Cross-workspace edge cases

• Duplicate emails across workspaces. A person can have separate accounts in different Jadiroon workspaces with the same email. Each workspace is its own tenant.
• Same person in your workspace twice. Not allowed. The platform enforces email uniqueness per workspace at invitation time.
• A person whose email changes. In v0.5, the path is to remove them and re-invite under the new email; the old account record is preserved in the removed-members table.

/people roster vs the Team page

The Team page manages login accounts. To browse the full roster (candidates, employees, and former employees) go to /{slug}/app/people. That page shows a Nationality column beside each name: Saudis carry an emerald chip, expats a neutral chip. Hover or tap the chip to see the full nationality name. See the Saudi fields page for the underlying field model.

Managing people directly on the roster

Roles holding People Act (always including Workspace Admin) can edit and delete people records directly on /{slug}/app/people. A roster record is distinct from a login account; use the Team page to grant access. People join the roster by being invited (via the Team page) or by applying through the hiring pipeline.

• Edit person. The pencil icon on each row — and the Edit button on a person's detail page — opens a form pre-filled with the person's personal data only: first/last name, email, nationality, national ID / Iqama, and start date. Status, position, and manager are not editable here (status changes flow through the hiring pipeline). For a candidate, the email, phone and national ID are shown masked and disabled unless your role holds See candidate contact details.
• Delete person. The trash icon permanently removes the person and all related data (profile, assessments, growth plan, interviews). You cannot delete your own profile or another Workspace Admin's.

What a Line Manager sees once their team is set

A member on a role with the My reporting line data scope (typically a line-manager role you built), whose account is linked to their person record, and whose reports have them set as manager, automatically gets:

• A "My team" surface at /{slug}/app/grow/my-team — a snapshot of their direct reports (level 1) with target-role match score, growth-plan status, and succession readiness.
• Team-scoped people and development plans — /people, profiles and development plans are limited to the manager's reporting tree (direct + indirect reports, up to six levels deep).

For the precise rule see Roles and permissions matrix.

Mass CSV import

For large onboarding waves, use the mass upload:

/{slug}/app/settings/team → Template to download the CSV template → fill it in → Mass upload (CSV) to upload it.

The template is generated for your workspace each time you download it: the header row, one example EMPLOYEE row, and one example row for each of your workspace's current roles, with role names in your interface language. Download it again after you add or rename roles.

The template columns are:

The role column. HR_ADMIN and LINE_MANAGER are no longer special values; they work only if your workspace has a role with that name. Each staff row with an email gets an invitation carrying that workspace role; each EMPLOYEE row gets an employee invitation.

Position & job family slot each imported employee into the workspace's taxonomy (Sector → Sub-Sector → Job Family → Position), exactly like the Position field on the single Add-person form. Matching is by name, case-insensitive and trimmed — never IDs:

• If position matches an existing position, the person is linked to it.
• Otherwise, if jobFamily matches one of your selected families, a position is created under it (named after position if given, else after the family) and reused for later rows in the same upload.
• If neither resolves — or the family has no matching sub-sector yet — the person is still imported with no position; you can set it later from /people.

The CSV import and the template need Users & roles Act. The importer previews every row with a pass / fail status before any accounts are created, and each row is judged on its own:

• A role that doesn't exist in the workspace fails that row, with the role name, the list of available roles and a hint to download the template.
• A role you aren't allowed to assign (for example the locked Workspace Admin, for anyone who isn't a Workspace Admin) fails that row.
• Other failures show the reason inline (duplicate email, invalid email, missing required field).

Click Import to process only the accepted rows; rejected rows are skipped and can be fixed separately.

Cap: 200 rows per upload. For workspaces larger than 200, split into multiple uploads — existing accounts are skipped automatically.

Roles

The Roles tab (/{slug}/app/settings/roles, Users & roles Act) is where you create and edit workspace roles: View and Act per module, named permissions and the data scope. See Roles and permissions and the Roles and permissions matrix.

What this surface does not do

• Bulk role changes. Changing many members' roles at once is not supported; do them one at a time.
• Single sign-on management. No SSO in v0.5; nothing to manage here yet.

Next

The competency taxonomy — how to use the seeded one and how to extend it — is covered next.