Create a custom credential
Oho ships with a catalogue of credential types it can verify against official registers — Working With Children Checks, NDIS Worker Screening, AHPRA, teacher registrations, police checks, right to work. A custom credential lets you track something that isn't in that catalogue: an internal compliance course, a First Aid certificate, a forklift licence, a food-handling certificate, a company induction — anything your organisation needs to record against a worker.
You define the type once under Settings, and from then on it appears wherever credentials are recorded: on a worker or applicant profile, as a requirement in a screening package, and on the applicant capture form during a recruitment check.
This is the one difference that matters. Oho verifies catalogue credentials against the issuing register; a custom credential has no register behind it, so Oho tracks it but can't confirm it's genuine. Every custom type is stamped Not verified, and someone in your team is responsible for checking the document. Use a custom credential to record and monitor something, not to prove it the way a register check does. If a built-in type already exists for what you need — a WWCC, a police check — use that instead so you get real verification.
Only an Admin can create custom credentials, and the feature is available on plans that include it. If you don't see it in Settings, either you're not an Admin or your plan doesn't include custom credentials — talk to whoever manages your Oho account.
Step 1: Open Custom Credentials
Open Settings (the gear icon), then go to Customize → Credentials. You'll see any custom credential types you've already defined, listed with their Behaviour, number of Custom fields, and the date each was Created.
Expected outcome: you're on the Custom Credentials page, ready to add a type.
Step 2: Create the credential type
Click Create Custom Credential. In the dialog:
- Name the type as your team will recognise it — for example, Internal Compliance Training 2024. This is the label people pick from the credential list.
- Check the code (for example
cred0001). Oho generates it for you; you can change it before saving, using letters, numbers, hyphens, or underscores. It's the stable identifier used by API integrations and the credential type pill. - Choose how the credential expires — see Step 3.
- Add an optional description — what the credential covers and who issues it.
- Turn on Requires attachment if every credential of this type must have a scan or photo of the document uploaded before it can be saved.
Before you save, the code is editable. After you save, it's fixed — changing it later would orphan every credential already created of this type. Get it right first time; the name you can change whenever you like.
Expected outcome: the type has a name, a code, an expiry behaviour, and any attachment requirement set.
Step 3: Choose how it expires
Every custom credential needs a date behaviour, because that's what drives expiry tracking and reminders. Pick one:
- Expiry — you enter an expiry date on each credential of this type. Use this when the document itself carries an expiry (a card valid until a printed date).
- Attainment — you enter the date the worker attained the credential, and Oho calculates the expiry from a validity period you set here, in months or days (at least 1). A First Aid certificate valid for three years, or a short course valid for 90 days, fits this. Reviewers always see a concrete expiry date on the card.
- None — the credential never expires. Use this for a one-off induction or a permanent qualification.
Expected outcome: the credential knows whether — and how — it expires, so Oho can track and remind on it.
Step 4: Add custom fields (optional)
Beyond the dates and attachment, you can capture extra details on every credential of this type. Under Custom fields, add a field for each, giving it a label and choosing its type:
| Field type | Use it for |
|---|---|
| Text (single line) | Short values — a certificate or licence number |
| Long text (multi-line) | Notes or a longer description |
| Number | A numeric value |
| Date | A date other than attainment or expiry |
| Yes / No | A simple toggle |
| Dropdown (single choice) | A fixed list of options you define |
Turn on Required for any field a credential can't be saved without. For a Dropdown, add the options people will choose from. Fields appear in the order you add them, on every surface where the credential is recorded.
The option text is stored on each credential as you saved it. If you rename an option afterwards, credentials recorded under the old wording keep the old value — so settle your option labels early.
Expected outcome: the fields you want captured are defined, in order, with the right ones marked required.
Step 5: Save
Click Save. The type appears in your Custom Credentials list with a Not verified tag, and is immediately available everywhere credentials are recorded.
Expected outcome: the custom credential type exists and is ready to use.
Put it to work
Defining the type is the setup — here's where it earns its keep.
Record it on a worker. On a worker's (or applicant's) profile, open the Credentials tab and add a credential; your custom type is now in the list, and the dialog shows the fields, dates, and attachment you configured. Oho tracks its expiry from the date behaviour you chose, the same as any catalogue credential.
Require it in a screening package. When you build a screening package, your custom type is selectable alongside the built-in checks — so a role that needs your internal induction can list it as a requirement.
Ask for it during recruitment or from an existing worker. When a package that includes your custom type is sent as a recruitment check, its fields render on the applicant's capture form. For someone already on the books, a fetch request asks them to supply it.
Watch it on your dashboards. Because Oho tracks the expiry, custom credentials flow into your Compliance Overview and the expiry notifications you've set up — a worker missing a required custom credential, or holding one that's about to lapse, surfaces in the same queues as any other gap.
Edit or delete a type
From the Custom Credentials list, use the edit icon to change a type's name, description, expiry behaviour, or fields at any time. The code stays locked once the type has been saved.
Deleting is deliberately gentle on your data: removing a type stops it appearing in new Add Credential, Screening Package, and Recruitment Check flows, but credentials already recorded under it are not deleted — they stay on workers' profiles with the values captured at the time.
A deleted type disappears from the pickers from the next page load, so no one can record a new credential of that type. If you only want to tidy up wording, edit the type instead of deleting and recreating it — recreating gives you a new code and won't reconnect to the credentials recorded under the old one.
Common questions
Will Oho verify a custom credential against a register? No. Custom credentials are tracked manually and always show Not verified. If you need real verification, use the built-in catalogue type for that credential.
Can I change the code after saving? No — it locks on first save to protect the credentials already recorded under it. Only the name and other details stay editable.
Someone can't see Custom Credentials in Settings. They're either not an Admin, or your plan doesn't include the feature. Managers and Observers can record custom credentials once a type exists, but only Admins define the types.
What happens to attainment-based expiry? Oho sets expiry = attainment date + validity period, so every credential of that type shows a concrete expiry the
moment it's recorded, and feeds your expiry reminders automatically.
Related
- Custom credentials — the concept, and how they differ from verifiable credentials
- Add a credential — record any credential on a worker
- Create a screening package — require a custom credential for a role
- Roles & access — who can define types and who can record them