Skip to main content

Background verification: consent, review and audit (mock provider)

Continuing the Meridian Interiors story: this page follows two background verification cases through the Background Verification screens, from a case that cannot be submitted without consent, to a case that cannot be approved by the person who sent it for review. It also says plainly what is real and what is not.

Illustrative demonstration prepared using publicly available company context and synthetic data. This page does not represent a production deployment, customer endorsement, or use of real employee data.

What is real, and what is a mock

In the workspace used for this page the verification provider is a mock provider. No external verification agency is contacted and no check is run against a real source: the results you see are simulated and entered by hand. Nothing on this page should be read as a verified identity, address, education or employment record.

What is real BlueOneHR behaviour, and the same whichever provider is connected:

  • the case and the status it moves through;
  • the consent gate that stops anything being submitted before consent is recorded;
  • the review rule that the person who sent a case for review cannot also approve it;
  • the audit trail, which records refused attempts as well as successful ones.

Where the screens are

The Background Verification list opens at the /bgv/ address of your workspace, and has two tabs, Cases and Policy. You only see it if an administrator has granted your role the background-verification manage permission. The list shows each case's Reference, Subject, Package, Status, Consent and Due date, and can be filtered by status and by check type.

A case belongs to either a candidate or an employee and carries a package: basic (identity and address), standard (identity, address, education and employment) or comprehensive (those four plus criminal record, reference and court record). A case moves through Draft, Consent pending, In progress, Awaiting review, then Approved or Rejected, and finally Closed (or Cancelled).

A new case opens as a Draft with consent not yet recorded. Opening it shows the Case details (including Provider), a Consent section, Actions, the Checks table, and below them Documents, Tasks, Provider events and the Audit trail.

If you choose Submit to provider before consent is recorded, BlueOneHR refuses and tells you that consent must be recorded first. The refusal is itself written to the audit trail.

To record consent, fill in the Purpose, the Notice version and a Consent evidence reference, then click Record consent. The case keeps the consent details on the page. After that, Submit to provider hands each pending check to the provider and the case becomes In progress.

Results and review

Each check shows its own status, a risk level and a result summary. With the mock provider, HR records a result by hand against each check. When every check has a final result, the case moves to Awaiting review and an open task asks someone to review it.

Send for review opens a review through the approvals engine, using the company's BGV Review approval chain. The Reviewer decision form then offers Approve and Reject. A rejection needs a reason and an adverse-action note. Approving despite a discrepancy needs a recorded reason.

The review is maker-checker: the person who sent the case for review cannot also decide it. If they try, BlueOneHR refuses with a message that a different person has to approve it, and records the refused attempt.

Audit trail

The Audit trail at the bottom of a case lists When, Who, Action, Outcome, Reason and Mode for each step: case created, consent recorded, each check submitted, each result received, and review decisions. It is append-only, refused attempts are recorded, and identity numbers are never written to it. Mode shows MOCK for steps handled by the mock provider.

No comments to display