Review & Decide
Most checks settle themselves. A register answers, the answer is unambiguous, the worker's status changes, and nobody needs to be involved. Review & Decide is where the rest go — the results where an automatic decision would be either wrong or presumptuous, and a person has to look.
The queue lives at the top of the left menu. Every open item is visible to every administrator: there is no per-person assignment, so anything sitting there is the whole team's to pick up.
Why a queue, and not just a status
Two failure modes drive the design.
Oho could guess, and quietly change someone's status on a partial match. A worker whose name resembles a name on a ban register is not the same as a worker who is on it, and standing the wrong person down is not a recoverable mistake. So the ambiguous result is parked rather than applied.
Oho could also do nothing and leave the result on the worker's profile for someone to notice. That fails the other way: the finding is real, and nobody is looking at that profile. So the item is pulled out to one shared place where the open work is countable.
What comes out of the queue is a decision, attributed and dated. On the surfaces that matter — what a worker's status says, what gets published back to your ATS or HR system — it is that decision, not the raw automated answer, that leaves the building.
What lands in the queue
Items arrive from several places. The common shapes:
Something ambiguous needs adjudicating
| Item | Raised when |
|---|---|
| Ban match review | A worker scores a probable match against a ban register and the match isn't certain |
| Weak-signal ban match | A low-scoring match — typically a name-only hit with no date of birth on the register row |
| Police check review | A check returns disclosable court outcomes, or the provider couldn't process it |
| Credential verification review | A register answers, but not conclusively — a visa carrying work conditions, for instance |
| Credential name mismatch | The name printed on a credential doesn't match any name Oho holds for the person |
A person has to see the document
| Item | Raised when |
|---|---|
| Attachment review | An uploaded document scores low confidence, or is recognised as the wrong document type — see document recognition |
| Mandatory credential review | A credential of a type your organisation has flagged for compulsory manual review is submitted |
A consequence needs owning
| Item | Raised when |
|---|---|
| Credential downgrade review | A register moves a credential you were relying on to "may not engage", and its type is on your downgrade-review list |
| Accreditation transfer review | A new worker looks like an applicant already screened — confirming copies their credentials across |
Something needs a human's judgement, but nothing is blocked
| Item | Raised when |
|---|---|
| Credential amended review | Someone edited a credential after its verification had already settled, so the verdict no longer describes what's on file |
| Credential expiry update | A register cleared a credential whose stored expiry had lapsed, and that register doesn't publish expiry dates |
| Import name conflict | A spreadsheet import carried a different name from one a person had corrected by hand |
| Qualification provider status | A qualification's issuing RTO is no longer currently registered on training.gov.au |
| Qualification product status | A qualification's training product is superseded or no longer current |
| Reference IP match | A referee submitted a reference from the same network as the applicant's own submission |
What blocks, and what doesn't
This is the distinction worth internalising, because it decides how urgently the queue needs clearing.
Some items hold the credential. A mandatory review on a blocking credential type, and a credential downgrade review, pin the credential at "review required" until someone decides. The worker does not count as compliant on it meanwhile — that's the point.
Most items don't. An expiry-update review leaves the credential active and the worker working: what's missing is a date, not a verdict. An import name conflict has already resolved itself in the record's favour. The qualification reviews deliberately write nothing back, because a provider's later deregistration says nothing about a qualification attained while it was registered — that's an organisational judgement, not a register's.
A credential downgrade review that nobody answers auto-confirms the downgrade after your configured window. Of the two ways to be wrong, a genuinely revoked credential still reading "may engage" because nobody opened the queue is the worse one.
Deciding
Each item offers the decisions that make sense for it. Across the queue these are:
| Decision | What it means |
|---|---|
| Confirmed | The flag is real. The subject is updated to match — a ban match is upgraded, a downgrade is confirmed |
| False positive | The flag is wrong. The subject is returned to a clear state, with the override noted |
| Dismissed | Closed without substantive action — a duplicate, or an informational item acknowledged |
| Escalated | Passed to a more senior reviewer. Nothing changes on the subject |
| Request a re-upload | For attachments: the document was wrong, so ask for a replacement rather than judging it |
| Keep / accept a value | For import conflicts: whose version of a name stands |
A free-text note goes with the decision. It isn't compulsory, but it's the thing an auditor reads in twelve months' time — and for anything you're calling a false positive, it's the difference between a defensible decision and an unexplained one.
Reverting
Some decisions can be undone. Oho records exactly what the decision overwrote, so reverting restores the prior state rather than guessing at an inverse — which matters, because these write-backs don't reverse cleanly on their own. A decision can't be reverted while it has raised follow-on items that are still open, and items with no write-back have nothing to revert, so the action simply isn't offered.
How an item clears
Three ways:
- You decide it, in the queue.
- The decision is recorded elsewhere. Some items resolve themselves when the underlying decision is made on the record — recording a final decision on a police check clears its review.
- The reason evaporates. An expiry-update review clears the moment a real expiry date arrives from any source: the review itself, a capture request, an HR connector, or the API.
Resolving an item can also raise a new one. Asking for a replacement document creates a request; when the new document arrives it raises its own review, linked back to the decision that asked for it.
Configuring what needs review
Two lists under Settings → Manage → Review & Decide decide how much lands in the queue:
- Mandatory review types — credential types where a person must always confirm the document, whatever the automated answer. Marked blocking or informational per type.
- Downgrade review types — credential types where a register's move to "may not engage" is held for confirmation rather than published straight through.
Both are deliberate trades: more assurance against more queue. Start with the credential types where being wrong is expensive.
Related
- Understand your Compliance Overview — the dashboard these items are flagged from
- Ban checks — one of the result types that needs a decision
- Document recognition — what raises an attachment review
- Audit trail — where decisions are recorded
- Credentials — what each outcome means for the credential