Skip to main content

Roles & access

Not everyone who logs in to Oho should be able to do everything. A role decides what a person can see and do — from full control of the platform down to read-only reporting. This page explains the four roles, what each one can do, and how you narrow a person's view to just the part of the business they look after.

Roles are set when you invite someone, and an admin can change them at any time. If you're ready to add people, see Invite your team & assign roles.

Who changes your access

A Super Admin in your own organisation — not Oho support, which has no way to grant anyone a role, an organisation or a workflow. If you don't know who yours is, or you've been asked to give someone the same access as a colleague, see Asking for access and Give someone the same access as a colleague.

The four roles​

Everyone who signs in to Oho is one of four roles. The two admin tiers split running compliance from setting the platform up:

  • Super Admin — the technical tier, usually IT or whoever owns the Oho setup. Super Admins do everything an Admin does, and additionally connect data sources and verification sources, manage users and roles, edit policies, and issue API tokens. This is the role that gets your organisation running, and the only one that sees every organisation.
  • Admin — full control of compliance within the organisations they're assigned. Admins work with the workers in those organisations, configure screening packages, tags and email templates, and verify credentials — but they don't touch the technical setup.
  • Manager — runs compliance day-to-day. Managers add and edit workers, record and verify credentials, and send recruitment and fetch requests — but only within the organisations they've been assigned, and they can't change organisation settings. They can set their own alert preferences under Settings → Manage → Notifications.
  • Observer — read-only. Observers can view workers, credentials, and the compliance dashboards, and export reports, but they can't make changes.

Most people are Managers or Observers. You need at least one Super Admin — without one, nobody can connect a data source or invite the rest of the team.

What each role can do​

CapabilitySuper AdminAdminManagerObserver
View workers, credentials & compliance✓✓✓✓
Export & download reports✓✓✓✓
Add & edit workers, credentials & exemptions✓✓✓—
Send recruitment & fetch requests✓✓✓—
Request a police check✓✓✓—
Configure screening packages, tags & email templates✓✓——
Connect data sources & verification sources✓———
Manage users, roles & policies✓———
Issue API tokens & service accounts✓———
AccessAll organisationsAssigned organisationsAssigned organisationsAssigned organisations

Each role includes everything the one below it can do. Only Super Admins see the whole business; Admins, Managers and Observers all see only the organisations they've been given access to (below).

Only a Super Admin can create another Super Admin

The Super Admin role doesn't appear in the role dropdown for anyone else, so nobody can promote themselves to it by accident. Keep more than one Super Admin — if the only one leaves, no one can connect a source or invite a replacement.

Scoping access to organisations​

Your people are grouped into organisations — sites, business units, or regions. When you invite an Admin, Manager or Observer, you choose which organisations they're responsible for, and from then on their view of workers, credentials, compliance and requests is limited to those organisations.

Super Admin is the only unscoped role. An Admin is scoped exactly like a Manager: they have more settings, over fewer people. An Admin assigned one site can only add workers to that site, and only sees fetch requests, police checks and compliance for that site.

You can also narrow a scoped person to one or both sides of Oho:

  • Recruit — screening applicants before they start.
  • Continuous checks — the ongoing monitoring of workers already on the books.

So a recruiter might be a Manager scoped to Recruit for two sites, while a site supervisor is a Manager scoped to Continuous checks for their own location only.

Giving an Admin access to every organisation​

There's no "all organisations" switch. You have two options:

  • Tick every organisation on their invite, or afterwards with Switch Organisation on their row under Settings → Access → Users & Groups — see Manage your users. This keeps them an Admin, with no technical-setup access.
  • Make them a Super Admin, which is unscoped by definition. Only do this for people who should also reach data sources, users and API tokens.
New organisations aren't added automatically

An organisation created after someone was scoped — by hand, or by an HRIS sync bringing in a new site — is not added to their access. Every scoped person who needs it has to be updated with Switch Organisation. Until then the new organisation's workers are invisible to them, and a Super Admin is the only one who can see the whole picture.

Groups​

Settings → Access → Users & Groups has a Groups tab, and it's already full before you've created anything. There are three kinds of group in there, and only one of them is yours to manage directly.

Organisation groups​

Oho creates one group per organisation, automatically, named after it and described as "Organisation group for …". Membership of that group is what actually grants access to the organisation's workers, credentials, requests and tasks.

Don't add or remove people here. Use the organisation pickers instead — on the invite, or Switch Organisation afterwards (see Manage your users). Those write both halves of a person's scope; editing the group by hand writes only one, and the two halves then disagree: lists show the organisation's workers while the pickers in Add Worker and Add Applicant don't offer that organisation at all.

You can't delete an organisation group while its organisation exists — Oho blocks it and tells you to delete the organisation instead, because nothing would recreate the group and everyone in it would lose that organisation.

Workflow groups​

Recruit Access and Continuous Access back the two permissions of the same name. Adding someone to one of these groups grants that workflow on top of whatever their invite set, so a person can hold access that Edit Workflow Access doesn't show as ticked. The tooltip on the Workflow Access column says which grant is in play — invite, group policy, or both.

Normally you'd set workflow access on the person with Edit Workflow Access, and leave these two groups alone. They're the escape hatch for granting a whole team the Recruit side in one go.

Groups you create​

A group you create yourself grants nothing. It's a list of people and no more, until you either:

  • give it a role from the role control on its row, which grants that role to every member; or
  • name it as an actor on a permission — see Manage policies.

So don't recreate your organisation names as groups: an organisation group of that name already exists, and a second one that merely looks like it controls access doesn't.

Seeing personal information​

Some of what Oho holds about a person is more sensitive than the rest: their date of birth, personal email address and phone number, home address, ABN, and any alternate names recorded for identity checks. Oho hides these from everyone by default. If you don't have access, you see a partially masked value instead of the real one:

FieldWhat you see without access
Personal emailj•••••••••@••••.com
Personal phone+•• ••• ••• 678
Date of birth••••-••-••
Home address••••••••, Melbourne VIC ••••
ABN•• ••• ••• •56

Enough is left showing to confirm you're looking at the right person — the last few digits of a phone number, the suburb and state of an address — without exposing the value itself.

Names, work email, work phone, job title and organisation are not treated as personal information and are always visible. Searching, filtering and reporting on those is unaffected.

Giving someone access​

Access is granted through a policy called View PII, not through a role — because needing someone's date of birth is about the job they do, not their seniority. A payroll officer who is a Manager may need it; an Admin who never handles personal data doesn't have to have it.

To grant it:

  1. Go to Settings → Access → Permissions. This is a Super Admin screen — if you can't see it, ask whoever set your Oho up.
  2. Open the View PII policy.
  3. Set it to Active if it isn't already — it ships switched off.
  4. Add the people or groups who need it, and save.

Both admin tiers have this access automatically. Everyone else sees masked values until they're added.

Editing a worker without this access is perfectly safe: the masked values you were shown are ignored when you save, and the real ones underneath are left exactly as they were.

First sign-in​

Nothing is asked of a new person on their first sign-in — the organisations and workflows chosen on their invite apply straight away, and they land on the part of Oho those choices give them. If someone signs in and the workers they expect aren't there, their scope is the first thing to check: open their row on Settings → Access → Users & Groups and read the Organisation column — see Manage your users.

Signing in with your company login​

If your organisation uses single sign-on, people reach Oho through your identity provider (Okta, Microsoft Entra ID, Google Workspace, or another) rather than an Oho password. SSO decides who can sign in; the roles and scoping on this page still decide what they can do once they're in. See Set up SSO.