Who Owns the Error? Documenting Exception Handling Before You Connect Jobsite Systems

This is general editorial guidance. Every recommendation below is conditional on your organization's workflows, system configuration, and staffing. Read this as a starting checklist, not a universal prescription.

Why Exception Documentation Belongs Before Go-Live

When two systems exchange data automatically, the integration looks clean in a demo. Records flow from the field into project controls. Equipment hours land in the cost ledger. RFIs update the document log. What the demo rarely shows is what happens when the sync stalls at 2:00 a.m., when a foreman edits a record offline and then reconnects, or when both systems hold a different version of the same cost code.

Those moments are not edge cases. They are recurring operational events on most connected jobsites. If nobody documented who owns each failure type before go-live, the team discovers ownership by accident, usually under schedule pressure. The purpose of exception documentation is to make the next action visible to whoever finds the problem, regardless of which shift they are on.

Four Categories of Exceptions Worth Mapping

Most jobsite integration failures fall into four groups. Documenting each group separately keeps the register usable.

1. Stalled or failed syncs

A sync stalls when the integration layer stops exchanging records without producing a visible error in either application. Data appears current in both systems but neither system has exchanged new records for hours or days. This is the failure mode most likely to be invisible.

2. Stale records

A stale record is one that reflects a state the jobsite no longer holds. A quantity that was updated in the field app has not reached the ERP. A purchase order that closed in the ERP still shows open in the subcontractor portal. Staleness differs from a stalled sync because the integration may still be running; the record simply was not flagged as needing an update.

3. Conflicting records

A conflict occurs when both systems hold a value for the same field and the values disagree. This is common after offline work periods. A superintendent updates production units while disconnected. The office updates the same line in the cost system during the same window. When the field device reconnects, the integration has no rule for which value wins.

4. Retry accumulation

Most integration platforms retry failed transactions automatically. If the underlying cause is not resolved, retries accumulate. A large retry queue can delay all subsequent legitimate transfers, create duplicate records if the original transaction eventually succeeds alongside a retry, or cause downstream systems to apply the same update multiple times.

A Simple Ownership Register

Before connecting systems, document a one-page register that maps each exception category to three things: the responsible role, the detection method, and the expected next action. The following are illustrative examples. Adjust roles and tools to match your actual staffing.

Illustrative example A: Stalled sync - Responsible role: Integration administrator or the IT contact designated for that platform - Detection method: Automated alert when no records have transferred within a defined threshold (for example, four hours during a production day) - Next action: Confirm the integration service is running, check authentication tokens, log the stall event with a timestamp, and notify the project controls lead if the gap exceeds a second threshold

Illustrative example B: Stale record - Responsible role: The system-of-record owner for that data type (for example, the cost engineer owns cost code records; the field supervisor owns production quantities) - Detection method: Periodic reconciliation report comparing key fields across both systems, run on a defined schedule - Next action: The system-of-record owner corrects the record in the authoritative system and documents why the record went stale, so the pattern can inform a configuration change

Illustrative example C: Conflicting record after offline field work - Responsible role: The field supervisor who owns the offline device, escalating to the project controls lead if the conflict involves a cost impact - Detection method: Conflict flag surfaced by the integration platform at reconnection, or a reconciliation query run after each planned offline period - Next action: A defined tie-breaking rule applied before reconnection, not after. If your workflow includes planned offline periods, document which system wins by default and under what conditions a manual review overrides the default.

Illustrative example D: Retry accumulation - Responsible role: Integration administrator - Detection method: Retry queue depth monitored by the integration platform, with an alert threshold set before go-live - Next action: Pause retries, resolve the root cause, clear duplicates if any posted, then resume. Document the event in a shared incident log accessible to both IT and project controls.

Who Should Produce This Documentation

Exception ownership documentation is not purely an IT artifact and it is not purely a field operations artifact. If IT writes it alone, the field roles and system-of-record distinctions will be wrong. If project controls writes it alone, the technical detection methods will be vague. The most useful version is produced by a working session that includes at minimum: the integration administrator or platform contact, one representative from project controls, one field superintendent or foreman who will use the connected system daily, and the person who owns the ERP or cost system on the office side.

If your organization uses a general contractor and multiple specialty subcontractors on the same platform, each subcontractor's data scope and exception ownership may differ. Document those boundaries explicitly rather than assuming the GC IT team owns all exceptions across all firms.

Making the Register Findable Under Pressure

A register that exists in a shared drive folder nobody opens during an incident is not operational. Consider attaching the exception register to the same location where integration credentials and runbooks live. If your organization uses a ticketing system for IT incidents, create ticket templates for each exception category before go-live so that whoever finds the problem can open a structured ticket without having to construct the description from scratch.

Review the register at the first scheduled integration check-in after go-live, and again after any offline period that generates a conflict. The register is a living document. If a stall occurs that your current detection method missed, update the detection method before the next production cycle.

A Note on Scope

This guidance does not address the upstream question of which system holds the authoritative version of each data type across your full technology stack. That mapping is a prerequisite worth completing before exception documentation begins. It also does not address access rights or identity management, which this publication has covered separately. Exception handling documentation assumes the integration is already configured and the data model is already defined. Its purpose is narrower: to make failure visible and to make the next action clear before the failure happens, not after.

If your integration is still in design, treat the four exception categories above as requirements. Ask your integration vendor or implementation partner how each category is surfaced, logged, and retried in their platform before you sign off on the technical design.