Read the audit trail

What the audit trail records #

Audit lists the actions recorded against your workspace: an application submitted, a payment matched to a check, an identity document approved, a reminder sent. Each row carries five things — Event, Actor, Subject, Severity and Time — so you can tell what happened, who recorded it, which applicant or check it belongs to, how much attention it needs and when it landed.

The overview's Recent activity panel shows the newest of these events. Audit is the same material without the cut-off, which is where you go when you need the history rather than the headline.

Read one entry #

Select Open on a row to read the entry in full. The detail names the actor, the subject it was recorded against and the time it was written, alongside the severity recorded with it.

Entries are records, not tasks. Opening one changes nothing, and nothing in the trail can be edited or removed afterwards. If an entry looks wrong, raise it with ClearDBS rather than attempting to correct the record.

Narrow the list #

Use the search box for an event, actor, subject or severity. The Actor column filters to one person, which is the quickest way to follow a colleague's involvement in a check, and the Time column sorts and filters by date.

Filtering changes what you see, not what exists. A narrowed list is not evidence that nothing else was recorded; clear the filters before concluding that an action is missing.

What audit is not #

The trail records workflow activity in ClearDBS. It does not record a DBS decision, and no severity in the list is an official result. A demo workspace shows synthetic events for fictional applicants.

Access follows your role: colleagues without audit permission do not see this section at all. Retention of audit records follows the compliance schedule rather than your own deletion of a check, which is what makes the trail dependable.

Detailed walkthrough #

1. Narrow the history carefully

Use the event time, actor and subject together to locate the activity you need. A person may have acted on several checks, so match the check reference as well as their name. If a filter hides the expected entry, broaden the view before concluding the event is missing.

2. Interpret the recorded event

Read what happened, who acted and which subject was affected in the selected audit entry. Severity helps identify entries worth investigating; it does not by itself establish a DBS outcome or the legal meaning of an action.

3. Use an entry when investigating

Keep the event reference or time and affected check reference when raising an operational question. Audit entries provide history and are not an editing form. Correct the underlying record through its own authorised workflow rather than trying to rewrite this entry.

Practise this section #

Open Help & tutorials, select this guide and choose Start practice walkthrough. Read each highlighted component before continuing. Use Back to revisit an explanation and Retry if a sample has not loaded. The walkthrough uses fictional records; do not enter real applicant information.

Use Exit tutorial to leave and keep your place, then Resume walkthrough in this guide to continue. When returning from practice to a real workspace, review the actual record and your permissions before making a change. Tutorial completion does not perform the underlying task.

Before using this guide #

Open Audit in an organisation workspace with audit access. Use a check reference, actor or approximate event time to identify the activity of interest.

Worked example #

If two colleagues worked on a similar applicant name, compare the subject reference and actor in the event detail before deciding which action needs investigation.

Guided component walkthrough #

Each component has one short guided step. Read the explanation, then choose Next; Back revisits the previous component. The cursor only demonstrates useful navigation or an explicit action. Replay action repeats that demonstration, and Skip animation keeps the explanation. Use this written guide for feature details.

The audit trail

• The audit trail: Every recorded action, with its Event, Actor, Subject, Severity and Time. Filter by Actor to follow one person.
• Read the table headings: The headings tell you what each audit event value means. Read across one row rather than comparing values from different rows; this keeps the identity, status and other details associated with the correct record.
• Open the intended record: Use the open control on the intended audit event row to inspect its details. Check the row identity first. Opening details lets you read more information without assuming that the record needs a change.
• Narrow the history carefully: Use the event time, actor and subject together to locate the activity you need. A person may have acted on several checks, so match the check reference as well as their name. If a filter hides the expected entry, broaden the view before concluding the event is missing.
• Open an entry: This opened audit entry gives the detail behind one event. Read the actor, subject and time together so you can distinguish this change from other events on the same record.

Inside one entry

• Inside one entry: The entry names who acted, on which check, and when. Entries are records: nothing here can be edited afterwards.
• Interpret the recorded event: Read what happened, who acted and which subject was affected in the selected audit entry. Severity helps identify entries worth investigating; it does not by itself establish a DBS outcome or the legal meaning of an action.
• Use an entry when investigating: Keep the event reference or time and affected check reference when raising an operational question. Audit entries provide history and are not an editing form. Correct the underlying record through its own authorised workflow rather than trying to rewrite this entry.

Related guides