Record automation and human actions clearly: Use a stable case reference and consistent time zone for all events.; Capture who acted, what rule applied, and the outcome of each step.; Protect records from unauthorised change and follow APP 11 privacy rules.
Image: Business Automation Desk

Human Oversight

Part of Human oversight in automated processes

Keeping a record of automated and human actions

Build a case history that connects automation attempts, human decisions, verified outcomes and later corrections.

Desk Programme · · 3 min read

Keep a case history that lets a reviewer reconstruct what automation attempted, what a person decided, what the destination confirmed and what happened next. Events may live in more than one system, but they need a reliable way to be joined. A completed run alone does not explain the business outcome or the authority behind an approval.

Start with the questions the history must answer

Which case was affected? What rule or approval allowed the action? Who or what acted? Did the destination change? Was an exception corrected or left open?

Capture each event where the relevant information is available.

A useful case-level entry can include:

  • a stable case reference and event type;
  • the event time with its time zone or a consistent time basis;
  • the person, service identity or process that acted;
  • the attempted action and relevant rule or workflow version;
  • the observed response and verified result, when available;
  • a reference to the related approval, exception or correction.

These are proposed business-record fields, not a mandatory schema. Record a later correction as a new event.

Replacing an earlier failure with a final success hides the sequence. If a person overrides a proposed outcome, retain the proposal and authorised decision; capture the reason needed to explain the departure under the organisation’s rules.

Case History Events in Automated Decision-Making

Event: Case Initiation
Stable case reference assigned; event time recorded with timezone (AEST)
Event: Automation Proposal
Workflow rule applied; system identity acts (e.g., service account); action attempted
Event: Human Decision
Authorised employee reviews proposal; approves, rejects, or overrides; reason captured
Event: Execution & Destination Confirmation
Action executed in destination system; result verified; change tracked using stable reference
Event: Correction or Exception Handling
Later correction logged as new event; original failure preserved; reason documented

Keep proposal, decision and execution separate

A hypothetical service request may be classified by a workflow, approved by an authorised employee and then entered in a destination system by a service identity. Record those as distinct events. If the destination result differs from the approval, leave the difference visible for review.

An error after submission can leave the destination state uncertain. Use a stable business reference across systems where they permit it. Hold the case for checking before a retry that could repeat the action.

Benefits and Risks of Retaining Original Automation Proposals

  • ProsEnables auditability; supports compliance with APP 11; allows review of decision rationale; maintains transparency across human and automated actions
  • ConsIncreases data volume; requires secure storage; may complicate reporting if not well-structured

Protect the history and make it usable

Restrict access and protect records from unauthorised change or deletion. Use consistent event names and a trustworthy time basis so a reviewer can order events from different systems.

Case records may contain personal information. Keep the fields needed for accountability, apply appropriate access controls and follow applicable retention and disposal rules.

For entities covered by the Australian Privacy Principles, APP 11 requires reasonable security steps and addresses disposal when personal information is no longer needed, subject to its exceptions.

Trace a completed case, a rejected case and one that crossed a human handoff. Compare the history with the destination result and check whether a reviewer can explain the decision. Repeat that review after a material rule or workflow change.

Key Compliance Requirements for Case Histories

  • APP 11 – Security of Personal InformationRequires reasonable security steps to protect records from unauthorised access or alteration
  • Retention and DisposalFollow relevant retention schedules; dispose securely when information is no longer needed
  • Access ControlsRestrict access to authorised personnel only; enforce role-based permissions
  • Time ConsistencyUse a single time basis (e.g., UTC or AEST) across systems for reliable ordering

More from Human Oversight