Screening Packages

A screening package is a reusable, named bundle of the checks a role requires. You define it once — "Disability Support – Standard needs an NDIS Worker Screening clearance plus a Working With Children Check" — and then reuse it every time you screen someone for that role, rather than re-listing the requirements each time.

Think of it as the job description's compliance half: the role says what the checks are, the package holds them together so everyone screened for that role is asked for exactly the same thing.

What a screening package represents

One role's screening requirements. Examples:

• Disability Support – Standard — NDIS Worker Screening + Working With Children Check.
• Volunteer Coach — Working With Children Check + a First Aid certificate.
• Registered Nurse — AHPRA registration + a police check.

A package is a template, not a record about a person. It carries no one's data — it simply lists the credential types a role needs, in one named place, ready to attach to a screening.

How a package bundles the checks

A package's core is its requirements — the list of credential types the role needs. These are the same credential codes used everywhere else in Oho (Working With Children Checks, Blue Cards, teacher registration, AHPRA, NDIS Worker Screening, First Aid, and so on).

For simple roles, that's just a flat list of credential types. For more involved roles, a package can also express:

• AND/OR logic and nested groups — "a police check AND (a WWCC OR a Blue Card)", for roles where one of several credentials will satisfy a requirement.
• Per-credential settings — whether an attachment is required, or whether a particular credential can be skipped.
• Guiding text — a short note shown to the person against a specific credential ("Please upload the certificate, not the wallet card").

Each package is identified by a short code you choose (for example oho0001), unique within your account. A package is either active (selectable when sending screenings) or inactive (staged, or retired from circulation) — so you can build one up before it goes live, and take it out of use later without deleting its history.

Keep packages role-shaped

Resist one giant "everything" package. Small, role-specific packages mean people are only ever asked for what their role actually requires — faster for them, cleaner for your audits.

Relationship to recruitment checks

A screening package is a template; a recruitment check is the act of applying it to one person. When you send a recruitment check, you name the package, and Oho asks that applicant to supply the credentials the package lists.

Crucially, Oho snapshots the package's requirements onto the check at send time. Once a check is in flight, later edits to the package don't change it — so an applicant part-way through onboarding never has the goalposts moved. Editing a package only affects checks you send after the edit.

Screening Package (template — the role's required checks)
      │  named when you send a check; requirements snapshotted onto it
      ▼
Recruitment Check (one applicant, screened against that snapshot)
      │  applicant supplies the requested credentials
      ▼
Verified Credentials (carried onto a Worker when the applicant is hired)

The worker-side analogue of a recruitment check is a fetch request, which asks an existing worker for a credential. Fetch requests take a plain list of credential types rather than a package — packages are specifically the pre-hire, role-based screening tool.

Where to next

• Applicants → — the people you screen with a package, before they become workers.
• Credentials → — the credential types a package bundles.
• Create a Screening Package → — build one in the app.
• Screening an Applicant tutorial → — the same flow against the API.