Skip to main content

Manage Policies

Policies are the rules that decide who can do what in Oho. Every role — Super Admin, Admin, Manager, Observer — is itself a set of policies that Oho ships and maintains. Assigning someone a role assigns them those policies.

This page is about the layer underneath: viewing those policies, and writing your own when a role doesn't fit.

Most teams never need this

Assigning roles covers almost every case, and roles are the supported way to manage access. Reach for policies only when you have a specific requirement the four roles genuinely can't express — and expect to maintain what you write. A hand-written policy is not covered by the guarantees that come with a role.

Before you start​

Policies are visible only to Super Admins — the tier that also manages operator accounts and platform settings. If Settings → Access → Policies isn't in your menu, you don't have the privilege, and assigning a role is the right tool for what you're trying to do.

Read Roles & access first. Most requests that sound like "we need a custom policy" — this manager should only see two sites, this person should only handle recruitment — are organisation scoping, which you set when you invite someone. No policy required.

What a policy is made of​

Each policy answers three questions:

  • Type — Platform policies grant platform-wide abilities (managing users, editing settings). Metadata policies grant access to records: workers, credentials, applicants.
  • Actors — who it applies to. Specific users or groups, or the broad selections All Users, All Groups, and All Owners.
  • Privileges — what they may do.

A policy is either Active or Inactive. Inactive policies keep their definition but grant nothing, which makes deactivating safer than deleting when you're testing a change.

Step 1: Open Policies​

Go to Settings, then Access → Policies.

The list shows every policy with its type, its actors, and its state. Use the status filter to switch between Active, Inactive, and All — it defaults to Active, so policies someone turned off earlier won't be visible until you change it.

Step 2: Read the shipped policies before writing one​

You'll see Oho's own policies here, named for the role they implement — Admins, Managers, Observers, Super Admins — alongside scoping policies such as Recruit Access, Continuous Access, and View PII.

Read the one closest to what you want first. It shows you which privileges actually exist and how Oho combines them, and it's usually faster than assembling a policy from scratch.

Don't edit the shipped role policies

They are what the roles mean. Editing one changes access for everyone holding that role, in ways the rest of Oho assumes are true — and Oho may restore them on upgrade, silently undoing your change. Create a new policy alongside them instead.

Step 3: Create a policy​

Click Create new policy and work through it:

  1. Name and describe it. Say what it's for and why it exists. Whoever audits access in a year needs to know whether it's still needed.
  2. Choose the type — Platform or Metadata, per the definitions above.
  3. Choose the actors — the users or groups it applies to. Prefer a group over a list of individuals; then access follows group membership instead of needing an edit per person.
  4. Choose the privileges — grant the narrowest set that does the job.

Step 4: Verify it​

Policies are additive: a person gets the union of everything that applies to them, so a new policy can only widen access, never narrow it. You cannot take an ability away by writing a policy — if someone can do something you don't want, find the policy or role granting it.

After saving, check the result on a real account rather than assuming. If it granted more than you intended, set the policy to Inactive and revise it.

Common questions​

Can I use a policy to restrict someone? No. Policies only grant. To narrow what someone sees, give them a more limited role or scope them to fewer organisations.

Someone has access they shouldn't. Something is granting it — their role, a group, or a broad policy such as one aimed at All Users. Set the status filter to All and look for policies with broad actors.

What happens on upgrade? Oho's shipped policies may be restored to their defined state. Your own policies are left alone — another reason to add rather than edit.

Can I delete a policy? Deactivate it first and confirm nothing breaks. An inactive policy grants nothing but can be turned back on.