A workspace is a single organisation's private tenant on Jadiroon. One workspace per organisation. Everything else in the platform — people, roles, assessments, plans — is scoped to a workspace.
Properties
Every workspace has:
- A display name (your organisation's name).
- A slug — the URL prefix (
/{slug}/...). Set when the workspace is created and not editable in v0.5. - A default locale — Arabic or English; used for new invitations and stage emails to candidates with no specified locale.
- A sector and its taxonomy slice — one sector, plus the sub-sectors, job families and competencies selected during onboarding; you can extend it with custom job families and competencies. (See Competency and taxonomy.)
- A set of operational toggles for things like the public job page.
- An AI quota — a token-equivalent budget for AI calls per billing period.
Tenancy
Workspaces are isolated from each other. No data crosses workspace boundaries:
- People in one workspace are invisible from another, even if the same human has accounts in both.
- Roles, assessments, growth plans, and the workspace's taxonomy selections (sub-sectors, job families, custom competencies) — all scoped to one workspace.
- AI usage is metered per workspace.
- Audit trails are per workspace.
One workspace, many users
A workspace contains many users (HR admins, line managers, employees) but is owned by the organisation, not by any individual. Removing a single user does not remove the workspace; the workspace persists as long as at least one HR Administrator remains.
Switching between workspaces
The same person can have accounts in more than one workspace — the same email, but a separate password per workspace. When that is the case, the admin sidebar shows a workspace switcher: a chevron beside the workspace name at the top. Opening it lists every workspace that email can sign into, with a tick next to the one you are in.
Choosing another workspace switches you straight into it — no need to sign in again. Because you have already proven you own the email on this session, the switcher quietly re-issues your session for the other workspace and drops you on its home screen. (If that silent switch ever fails, it falls back to the sign-in screen with your email pre-filled, so you are never locked out.) When your email belongs to a single workspace, the switcher is hidden and the name is shown as plain text.
Accounts created through a workspace's public candidate or trainer sign-up form are not part of this. Anyone can type any email into those forms, so the account only counts as yours once you prove you own the inbox: reset its password from the emailed link. Until then the account still signs in with its own password, but it can't switch into your other workspaces, and they can't switch into it.
Per-user vs per-workspace settings
A common source of confusion. Per-user settings are on each user's profile (/{slug}/me/profile):
- Interface language preference.
- Avatar.
- Phone number.
- Password.
Per-workspace settings are at /{slug}/app/settings:
- Default locale.
- Branding.
- Operational toggles.
- AI quota and consumption view.
Changing a per-user setting affects only that user. Changing a per-workspace setting affects the workspace as a whole.
Slug
Workspaces are created by platform super admins in the Platform Console; there is no public sign-up. The slug is suggested from your organisation's name — Acme Holding becomes acme-holding — and must be unique across the platform.
The slug appears in URLs (/acme-holding/app) and in some email templates as a workspace identifier. It is not editable in v0.5; doing so requires a slug-redirect mechanism that is on the v0.6 watch list.
What a workspace cannot do
- Belong to another workspace — there is no parent/child workspace relationship in v0.5. Each workspace is independent.
- Share data with another workspace — even if two workspaces are owned by the same parent organisation, their data is fully isolated.
- Be transferred to another organisation — workspaces do not have an ownership-transfer mechanism in v0.5. Cases of organisational restructuring (a subsidiary spinning off, a merger) require manual support; write to hello@jadiroon.sa.
Decommissioning
A workspace that is no longer needed can be suspended and then deleted by the platform's super admins (see Suspending and deleting a workspace). To request it, write to hello@jadiroon.sa; we export any data the organisation requests first. Full account deletion under PDPL data-subject rights follows the same path.