By the end of this chapter you can

• Say what a structured, signed handover is and which tools and records it replaces.
• Name what the module does and what it leaves to M05, M11 and the alarm system in SCADA.
• Name the four governing standards and say what each is used for in the module.

What Shift Handover does

Shift Handover gives every area a structured, searchable operations log and a consistent, signed handover that is filled in from live data, so critical information cannot be lost between crews: open issues, holds, permits, equipment out of service. Its table prefix is shf_.

It replaces electronic shift logs and shift handover software. The module specification names Hexagon j5 Shift Operations Management ^[1][2], Eschbach Shiftconnector ^[3], Tervene, Shiftworx, MaintainX (partly) and SharePoint or Excel logs. Comparison pages such as Fabrico's list of shift handover software ^[4] show what a buyer will expect to see. Your own business may use none of these: a paper logbook, a whiteboard or a chat group is a shift log too, and is just as likely to lose a note.

What the module does, and what it leaves out

The module is wide enough to carry the whole handover and narrow enough to leave permits, repair work and alarms to the systems built for them.

• In: categorised, equipment-linked log entries with carry-forward; a handover report template filled in from MES, CMMS, EHS and QMS state; standing orders with read-and-acknowledge tracking; shift tasks and rounds, and an event manager that turns tag conditions into log entries; outgoing and incoming sign-off.
• Out: permit-to-work issuance (M11); work order execution (M05); the alarm management system of record, which stays in SCADA.

The log can still point at those modules. From a log entry the module can create a work request (M05), an observation (M11), an NCR or hold (M08) or an action item. The log holds the link and the note; the other module owns the work. In this course only the action-item target is built, because it needs no other module; the links to M05, M08 and M11 are named so you know where they go.

Eight capabilities in three tiers

Each capability in the module's map carries a tier. MVP must exist for a plant to cancel the incumbent tool with confidence. STD is parity with mainstream tools. BIC marks a best-in-class difference. All three tiers are taught in this course, and you build all of them; BIC, the event manager, is the advanced part.

The standards, and what each one is used for

Two ideas from the HSE material ^[5] shape the design most. The handover is two-way: the incoming lead can ask, not only read, so a handover carries comments. And it is written plus verbal: the module keeps the conversation and the record together, and does not replace one with the other.

References

1. Hexagon: j5 Shift Operations Management help. https://docs.hexagonppm.com/r/en-US/j5-Shift-Operations-Management-Help/Version-30/1046047
2. Hexagon: j5 Shift Operations Management product sheet (PDF). https://bynder.hexagon.com/m/51c130045a97962b/original/Hexagon_PPM_j5_ShiftOperationsManagement_ProductSheet_A4.pdf
3. Eschbach: Shiftconnector digital shift book. https://www.eschbach.com/en/shiftlog/
4. Fabrico: best shift handover software 2026. https://www.fabrico.io/blog/best-shift-handover-software/
5. UK Health and Safety Executive: human factors (find the briefing note on safety-critical communications at shift handover here). https://www.hse.gov.uk/humanfactors/

By the end of this chapter you can

• Name the nine shf_ tables and say what each one holds.
• Give an entry its category, priority, status, equipment link and carry-forward flag from the allowed values.
• Explain why a free-text-only entry with no equipment link is a problem, and which links are soft.

Nine tables on the shared spine

Every table in the module starts with the standard columns every platform table has: id, tenant_id, created_at, created_by, updated_at, updated_by, row_version, archived_at and ext. The module keeps no list of people, equipment or shifts of its own. It points at the spine: core_shift_instance, core_equipment, core_person, core_shift_definition, core_data_tag and core_e_signature. A shift instance is one real run of a shift definition, such as the afternoon shift of a given date; an area is a piece of core_equipment at the area level of the equipment hierarchy ^[1]. For a commercial tool's view of a shift log, see the j5 help ^[4].

The table below is the full definition: every column the module adds to the standard ones, with its type and whether it is required (req). Types are as in the specification: text, int, bool, ts (a timestamp with time zone ^[2]), uuid and json (jsonb in Postgres ^[5]). An arrow means a foreign key to that table. Your agent builds from it in Session 2.

A few columns need a plain word. auto_snapshot holds the handover's data as JSON, a text format a database can search ^[3]. rrule is a recurrence rule such as FREQ=DAILY (RFC 5545), used in chapter 4. origin says whether an entry was typed by a person, made by an event rule or imported from the old tool. linked_type and linked_id name the record an entry led to, such as a work request. The lessons build only the action item (core_action_item) as a target; the other modules' records are soft links you can fill in once those modules exist.

An entry people can find again

A log entry is one operational event or note. Choose its fields as you would label a box before filing it. The category is one of production, quality, safety, maintenance, environmental, process, logistics or general. The priority runs info, low, medium, high, critical. The status is open, monitoring or closed. carry_forward says whether the next shift must see it.

Two links are deliberately soft: a uuid with no database foreign key. shf_task_template.form_template_ref points at a form template from M01, and linked_type with linked_id points at whichever record an entry led to. A business may not have those modules installed, so the log must work without them. Every other link keeps its foreign key.

Exercise · Turn six real notes into six good entries15 minutes

You need: The last two weeks of shift notes you read in Session 1, the allowed values in this chapter, and your AI coding agent

Work on paper or in a text file first; the agent comes in at step 5. Use roles, never the names of people, and leave out anything that describes an injury.

1. 1. Pick six notes from the real log or handover notes of one area: at least one that is about safety, one about maintenance and one that was still unresolved when the shift ended.
2. 2. For each note, choose its category and priority from the allowed values and write a title of one line. Write why you chose the priority.
3. 3. Name the piece of equipment the note is about, or write whole area. If you cannot name one, mark that note as one nobody could count.
4. 4. Choose its status (open, monitoring or closed) and whether carry_forward is true. Write who on the next shift needs to see it.
5. 5. Ask your agent: "Write six shf_log_entry rows for these notes with origin manual and typed columns, and one SQL query that lists every open entry with carry_forward true for an area, oldest first." Read the answer against your list.
6. 6. Check three things: no row has a null equipment_id or category; every status and priority is an allowed value; and the query returns exactly the entries you marked to carry forward.

Outcome: Six real notes turned into typed entries with category, priority, equipment link and carry-forward decision, and a query that finds the open carried ones.

References

1. ISA: ISA-95 series of standards (equipment hierarchy: site, area and below). https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
2. IETF RFC 3339: Date and Time on the Internet: Timestamps. https://www.rfc-editor.org/rfc/rfc3339
3. IETF RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format. https://www.rfc-editor.org/rfc/rfc8259
4. Hexagon: j5 Shift Operations Management help. https://docs.hexagonppm.com/r/en-US/j5-Shift-Operations-Management-Help/Version-30/1046047
5. PostgreSQL Documentation: JSON Types. https://www.postgresql.org/docs/current/datatype-json.html

By the end of this chapter you can

• Say which data goes into the auto-snapshot and where each part comes from.
• Explain why the snapshot is stored at sign-out and never recomputed when the handover is viewed.
• Describe the draft, signed_out, accepted and escalated states, and who signs each side.

The snapshot

The handover report is built from the state of the ending shift. The module consumes five events from other modules: mes.shift_summary.ready, cmms.work_order.status_changed, ehs.permit.activated, qms.hold.placed and ehs.incident.reported. From them it fills the report with production against plan, OEE (overall equipment effectiveness), downtime, open work orders, holds, active permits, safety events and quality alerts. The module's own log adds equipment out of service, open and carried entries and the active standing orders.

For how a commercial digital shift book presents handover content, see ^[3]. The result is stored as JSON in shf_handover.auto_snapshot. The outgoing lead adds a short summary in words, because a number cannot say what the incoming crew should worry about first.

Stored, not recomputed

The specification names two pitfalls to teach. The second, free text with no equipment link, was chapter 2. The first is recomputing the snapshot whenever the handover is viewed. It looks harmless, because the data is all there. But a week later the work orders have moved on, the holds are released and the permits are closed, so the handover now shows something the incoming crew never saw. The record has drifted. The compliance note says the snapshot must be stored with the handover so the record reflects what the incoming crew actually saw. In data-integrity terms ^[2], the stored snapshot is the original record, and a recomputed one is a copy of something else.

Two signatures, four states

A handover has an outgoing lead and an incoming lead, which is what makes it two-way, as the HSE human factors material asks ^[4]. Each signs with an e-signature held in core_e_signature: the outgoing lead's signature is stored as outgoing_signature_id and the incoming lead's as incoming_signature_id. Where the log is a regulated record, 21 CFR Part 11 asks that a signed record show who signed, when, and what the signature means ^[1]; the module's signature carries the signer, the meaning (authored for the outgoing lead, acknowledged for the incoming lead), the time and a hash of the record.

Signing out and signing in are also news for the rest of the platform. The module publishes four events of its own: shf.handover.signed_out, shf.handover.accepted, shf.log_entry.created and shf.standing_order.issued. In this build a database trigger writes each one into core_event_outbox when the row changes, so another module can react without reading the shf_ tables, and no person or route is given a right to write to the outbox.

Two rules guard the pair. Nobody signs both sides of one handover, because the second signature would then check nothing. And an escalation is not a failure to be hidden: it is the way an unsigned handover stops being silent.

When nobody signs

The specification says unsigned handovers escalate, and the first of its KPIs is the on-time sign-off rate: handovers accepted within N minutes of shift end, divided by handovers. The specification leaves N to the business. This course uses 30 minutes for its seed and asks you to take your own number from your Session 1 inventory.

• On time: accepted within N minutes of shift end. In the seed, handover 1.
• Late: accepted, but after N minutes. In the seed, handover 2. It counts against the rate even though it was accepted. Under the scheduler rule below it would have been escalated at minute 30 and then accepted; the seed stores it as accepted.
• Escalated: signed out but not accepted by the due time, and still not accepted. In the seed, handover 3. In this course's build the scheduler marks it once, at the due time, however many times it runs, and tells the shift's supervisor.
• Never signed out: a draft still unsigned at the due time is not set to escalated, so the outgoing lead can still sign out. The supervisor is told once, and in this build that one notification is what counts as the escalation the specification asks for when a handover was never signed out.

On the seed the on-time sign-off rate is 1 ÷ 3, about 33%: one handover of three was accepted within the window.

Exercise · Prove a snapshot does not drift20 minutes

You need: Your platform from Sessions 2 to 4 with the seed loaded, a test user for each lead, and your AI coding agent

Use the seed's synthetic people and data only. If you have not built the sign-out route yet, do steps 1 and 2 on paper and the rest after Session 4.

1. 1. List the items your handover report must carry for one area. Mark each as coming from MES, CMMS, EHS, QMS or your own log, and write the event name that brings it in.
2. 2. Ask your agent to sketch the auto_snapshot JSON for the seed's first shift log. Check that every item in your list has a place in it.
3. 3. As the outgoing lead, write a summary and sign out. Check that the handover has status signed_out, signed_out_at and an outgoing_signature_id, and that auto_snapshot is filled in.
4. 4. Now change the source data: insert a new hold event for the area and set one piece of equipment out of service.
5. 5. Open the handover again, as the incoming lead. It must show the snapshot as it was at sign-out, without the new hold. Write down what you see.
6. 6. Rebuild that same object ({"auto_snapshot": ..., "summary": ...}, keys sorted, no extra spaces) from the stored summary and the stored auto_snapshot, hash it and compare the result with the record_hash on the signature. They must match.
7. 7. Try two things that must be refused: change the summary of the signed_out handover, and accept it as the outgoing lead.

Outcome: A handover whose stored snapshot is unchanged after the live data moved, a hash that matches its signature, and two refused attempts to change or double-sign it.

References

1. eCFR: Title 21, Part 11, Electronic records; electronic signatures. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
2. FDA: Data integrity and compliance with drug CGMP: questions and answers (2018). https://www.fda.gov/regulatory-information/search-fda-guidance-documents/data-integrity-and-compliance-drug-cgmp-questions-and-answers
3. Eschbach: Shiftconnector digital shift book. https://www.eschbach.com/en/shiftlog/
4. UK Health and Safety Executive: human factors. https://www.hse.gov.uk/humanfactors/

By the end of this chapter you can

• Explain how a standing order is acknowledged, tracked per person and expired.
• Explain how an event rule makes exactly one log entry for each condition episode.
• Name the five roles and the screens they use, count the three KPIs on a seed, and describe the cut-over from the old tool.

Standing orders

A standing order is a time-bound instruction for an area: for example a temporary limit on a machine until a repair is done. It has an order number, a title, a body, an issuer, an effective_from and optional effective_to, a priority of normal, high or critical, and a status of draft, active, expired or withdrawn. When requires_ack is true, each person in the area must acknowledge it, and each acknowledgement is a row in shf_standing_order_ack with the person, the time and an e-signature: in this course's build every acknowledgement is signed with a fresh password, and signature_id holds that signature.

The measure that matters is acknowledgement compliance: acknowledged, divided by required, before the order takes effect. It counts people, not clicks, so the module allows one acknowledgement per person per order.

Shift tasks and rounds

A shf_task_template defines a recurring task for an area, on a shift definition, with a recurrence rule such as FREQ=DAILY (the RFC 5545 standard for repeating events ^[1]). For each shift the scheduler makes a shf_shift_task. An operator finishes it with a result: done, not_done, not_applicable or issue_found. A task can use an M01 form, and an issue_found result raises a log entry linked to the task, so the finding reaches the next crew.

Event rules: one entry for each episode

The event manager watches data tags. A shf_event_rule names a tag and a condition (a threshold, a state change or a duration), and when the condition is met it writes a log entry or a task with origin event_rule. Each firing is recorded in shf_event_occurrence, with the entry it made, or marked suppressed if it fell inside the rule's dedupe_window_min. The specification gives the window in minutes and does not say where it starts; in this build it is counted from the moment the condition clears. The occurrence table has no column for the episode, so this build keeps the start time of each episode in ext, as ext.episode_key on the occurrence row. The rule only writes to the log. The alarm system of record stays in SCADA, and the module follows the alarm management principles of ANSI/ISA-18.2 for event rules; the window keeps one condition from flooding the log with copies.

The third definition-of-done test says it plainly: an event rule creates exactly one entry per condition episode. A rule that wrote an entry every minute while a tank stayed high would bury the log, and the next crew would stop reading it. Shelving a rule, with a reason in a comment, stops it without deleting its history.

Who does what

The module adds five roles to the Role and Exposure Matrix and two machine accounts. Row-level security, the rules the database applies to each row for each person, is generated from that matrix, so a right missing from it is a refusal in the lab. NIST's project page on role-based access control ^[3] describes the model.

Each scope must point at a record, so the lessons write two build decisions down. Own area: a person's area is ext.area_id on core_person, holding the core_equipment id of the area, compared with the area_equipment_id of the shift log or standing order. Own shift: a shift's lead is core_crew.lead_person_id, reached through core_shift_instance.crew_id; whoever opens a shift log copies it into shf_shift_log.lead_person_id, and the shift is a person's own when that column, or a handover's outgoing_lead_id, is that person.

A right to write is not a right to read. An insert that hands the new row straight back (RETURNING) counts as a read, so row-level security refuses it unless the role may also read that row. The operator who posts a photo on an entry therefore also reads core_attachment on the area's entries and handovers, or the photo could not be shown on the shift log, and reads their own core_e_signature for an acknowledgement. A notification sent to someone else is a row the sender cannot read, so the route makes its uuid itself and does not ask for it back; that holds for a mention, for the issuer's notices and for the scheduler's.

The phone view matters most to the people on the floor. It keeps the area's open and carried items on the phone, lets the operator read, write and comment with no signal, and sends what was written when the signal returns, once. Acknowledging a standing order needs a fresh password, so it stays online. Every page must stay usable at 360 and 390 pixels wide, with large touch targets ^[4].

Three KPIs, counted by hand first

Count the seed by hand before you trust a dashboard, and make the database views match your count. A view that disagrees with a person who counted slowly is wrong, however good it looks.

Cut over from the old tool

The module specification gives the migration in one line: export the historical logs as CSV and import them as closed entries tagged origin = import. Closed, because history is evidence of what happened; tagged, so reports can tell old from new. Items still open in the old tool and still needed can be loaded as open entries with carry_forward true, so the next crew sees them. Then run old and new side by side for a few shifts, compare handover counts and open carried items, and only then cancel the old subscription, with the saving recorded. Check what your old tool can export on its vendor's own help page, such as j5's ^[2], and see ^[5] for the tools a buyer compares. This element states no prices: take the cost from your own invoice, as in Session 1.

The module is done when

• The snapshot stored at sign-out is byte-identical when re-opened a week later.
• An unsigned handover escalates on schedule.
• An event rule creates exactly one entry per condition episode.

Exercise · Predict an episode count, then replay it20 minutes

You need: Your platform from Sessions 2 to 4, the log administrator's page, and a replay script written by your agent

Use a synthetic tag and made-up values only. Do the prediction before you run anything.

1. 1. Choose one synthetic tag and a condition: a threshold and how many minutes it must hold. Write both down.
2. 2. Choose a dedupe window in minutes, and write a tag stream on paper with three episodes: a long one, a short one that clears and returns inside the window, and a later separate one.
3. 3. Predict, from the rule alone, how many log entries and how many shf_event_occurrence rows the stream makes, and how many are suppressed. Write the numbers down.
4. 4. As the log administrator, create the shf_event_rule with the tag, the condition, a category, a priority and the window. Ask your agent for a script that replays the stream through the events route.
5. 5. Replay it and compare: the entries must have origin event_rule, and the counts must match your prediction. If they do not, find out whether the prediction or the rule was wrong.
6. 6. Replay the same stream again. Nothing new may be added: the same number of shf_event_occurrence rows, suppressed ones included, and the same entries. That needs a unique index (a rule in the database that refuses a second row with the same values) on the rule and the firing time (triggered_at) covering every occurrence, plus a partial unique index (one that applies only to rows meeting a condition) on the rule and the episode key, ext->>'episode_key', for rows that are not suppressed. Because the specification lets suppressed be null, and a null row is outside that index, the evaluator always sets it to true or false. The evaluator inserts the occurrence first with on conflict do nothing (an insert that quietly adds nothing when the row already exists), and makes an entry only when that row was really inserted.
7. 7. Replaying the same stream adds nothing whether the rule is shelved or not, because of those indexes, so test shelving with new times. Shelve the rule (active set to false) with a reason in a comment, then replay a new fourth episode at times not used before and longer than the hold time, such as 15:00 to 15:30 in the seed day. No new entry may be made: still three, and the earlier ones must still be there. Then un-shelve the rule and replay that same fourth episode: exactly one new entry, four in all, with the earlier three still there.

Outcome: A written prediction that matches the counts from a replayed stream, no new rows on a second replay, a shelved rule that makes no entry for a new episode, and one entry for that episode once the rule is un-shelved.

References

1. IETF RFC 5545: Internet Calendaring and Scheduling Core Object Specification (iCalendar). https://www.rfc-editor.org/rfc/rfc5545
2. Hexagon: j5 Shift Operations Management help. https://docs.hexagonppm.com/r/en-US/j5-Shift-Operations-Management-Help/Version-30/1046047
3. NIST: Role-based access control project. https://csrc.nist.gov/projects/role-based-access-control
4. W3C: Web Content Accessibility Guidelines (WCAG) 2.2, 2.5.5 Target Size (Enhanced), the 44 px rule this platform uses. https://www.w3.org/WAI/WCAG22/Understanding/target-size-enhanced.html
5. Fabrico: best shift handover software 2026. https://www.fabrico.io/blog/best-shift-handover-software/

Choose one answer for each question, then submit. You will see the right answer and why for every question.

1. What is the main purpose of Shift Handover?

ATo replace the plant's alarm system with a searchable logBTo keep one big text file that every shift appends toCTo give every area a structured log and a signed handover so critical information is not lost between crewsDTo schedule which crew works which shift

2. Which of these is outside Shift Handover and owned by another module or system?

AWork order execution (M05)BStanding orders with acknowledgementCOutgoing and incoming sign-offDShift tasks and rounds

3. Which standard does the module name for the alarm management principles behind its event rules?

A21 CFR Part 11BAPI RP 1168CRFC 5545DANSI/ISA-18.2 (IEC 62682)

4. Which is a log entry the analytics can count by equipment and category?

AA note that says the same problem as last weekBA maintenance entry, priority high, linked to a named pump, status openCA note that says see the leadDA message in the shift chat group

5. What are the allowed statuses of a log entry?

Aopen, monitoring, closedBdraft, signed_out, accepted, escalatedCdraft, active, expired, withdrawnDqueued, extracting, in_review, approved

6. An entry is open and carry_forward is true when the shift ends. What happens?

AIt is closed so the next crew starts cleanBIt is deleted from the log after the handoverCIt is shown to the next shift among the carried items, with its ageDIt is emailed to every person on site

7. Why is the auto-snapshot stored at sign-out and not recomputed when the handover is viewed?

ARecomputing needs a paid serviceBA recomputed snapshot would drift, so a week later it would not show what the incoming crew sawCThe snapshot is too large to rebuildDThe outgoing lead may then edit it freely

8. Who signs a handover, and in what order?

AThe supervisor alone, at the end of the weekBThe incoming lead first, then the outgoing leadCBoth leads sign at the same moment on one deviceDThe outgoing lead signs out, then the incoming lead signs in

9. A handover is signed out but nobody accepts it within N minutes. What does the module do?

AMarks it accepted so the log is not blockedBDeletes the draftCWaits until the next day, and then asks againDEscalates it once and tells the supervisor; it can still be accepted

10. Six of nine required people acknowledged a standing order before it took effect. What is the acknowledgement compliance?

A6 ÷ 9, about 67%B3 ÷ 9, about 33%C9 ÷ 9, 100%D6 ÷ 6, 100%

11. A rule on a tag fires, clears, and fires again inside its dedupe window. What should the module do?

AWrite two entries, one for each firingBDelete the first entry when the second firesCWrite one entry and record the second firing as suppressedDStop the rule for the rest of the day

12. How is history from the old shift log imported?

AAs open entries, so each one is reviewed againBAs closed entries tagged origin import, so reports can tell old from newCAs signed handovers, so the old record counts as newDIt is not imported; the old tool is kept for ever

Submit answers