# 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.*

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

## 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**). ## Consent comes first 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. ## Related reading - [The connected HR lifecycle: hiring to workforce operations](https://docs.blueonehr.com/books/enterprise/page/the-connected-hr-lifecycle) - [Interview feedback, an approved offer, and a new hire](https://docs.blueonehr.com/books/enterprise/page/interview-feedback-an-approved-offer-and-a-new-hire)