Build the Action Board and Failure History

What you will complete

A styled test action board and event history derived from the same fixture data.

Make the operating decision

Create one event history for intake, normalization, match review, response attempts, qualification, ownership, booking changes, opt-out, and failures. Preserve actor, previous and new state, time, evidence reference, and actual effect where available. Do not overwrite a failed attempt with the later successful state.

The action view should surface unowned leads, response failures, safety escalations, clarification needed, qualified-unbooked records, booking uncertainty, cancellations, no-shows, and stale human tasks. Counts must identify whether they represent leads, events, messages, or bookings. Test data stays separate from live totals.

A static snapshot can support review but should not be labelled live. If the implementation queries current state on refresh, state that precisely. Empty results and failed collection are different. The operator must be able to reach the source record and understand the next action without reading raw logs.

Worked fictional example: Harbourlight Roofing

Harbourlight's board shows one routine enquiry awaiting review, one duplicate attached to its original event, one warranty callback, one safety escalation, one message failure, and one cancelled inspection awaiting rebook. Every card has an owner or an explicit unassigned alert.

Harbourlight Roofing, its staff, customers, enquiries, service rules, and results are fictional. The course does not claim a live deployment, faster response, more bookings, or revenue improvement.

Complete workbook section 6

Use the evidence available for your own bounded job. Write unknown when the evidence is missing, and record the person or action that can resolve it.

1. Define the event fields and state transitions.
2. Choose action-list categories and owners.
3. Create fixture data for normal, duplicate, escalation, failure, and booking changes.
4. Reconcile board totals with underlying records.

Open the course workbook PDF or read the workbook details.

Critical gate before continuing

• Failures cannot disappear from history.
• Counts name their unit.
• Every actionable card has an owner or escalation.
• Snapshot and live status are labelled accurately.

If a gate fails, repair the current section, narrow the scope, leave the route manual, or record a blocked or stop decision. Continuing is not the only successful learner action.

Common failure modes

• Expanding beyond a styled test action board and event history derived from the same fixture data. before the current artifact can be graded.
• Turning a missing value, unavailable source, or blocked integration into a confident conclusion.
• Treating a prompt instruction as proof that the effective tool or permission boundary works.
• Marking a manual, simulated, or untested route as live.

Check your application