Xgrid rebuilt a construction field operations platform — covering crew clock-in/clock-out, daily work reporting, and document signing — on Temporal's durable execution model. The post details nine concrete engineering decisions: one Temporal Workflow per shift with a deterministic ID for idempotency, BLE beacons replacing GPS for underground location accuracy, Signal-With-Start for offline resilience, an in-workflow request queue for ordering and deduplication, Update validators for compliance-as-code, classified retry policies for transient vs. permanent failures, device-captured timestamps as the legal record, AES-256-GCM client-side encryption for data sovereignty on Temporal Cloud, and a pull-based worker model handling morning clock-in spikes with just 5 Kubernetes nodes. Outcomes include payroll accuracy rising from ~80–85% to above 99%, tool losses dropping to near zero from $50K+ per site, audit prep going from weeks to on-demand export, and time-to-diagnosis on field issues shrinking from hours to minutes.
Table of contents
Solving distributed state: surviving the 7:02 AM network drop #Beyond the tech-glamorous use cases #Architecture: one durable Workflow per shift #How Temporal solved the hard problems #The daily work report: cron without the cron problems #The Control Tower: real-time visibility from Workflow History #What we actually got #Reliability as a strategy #Questions this post answers
How do I prevent duplicate workflow runs in Temporal when a mobile client retries the same request multiple times?
Use a deterministic workflow ID derived from a stable business key (e.g., schedule ID) and set workflowIdConflictPolicy to USE_EXISTING. When the mobile client fires the same 'start shift' request three times, Temporal resolves all three to the existing run rather than creating duplicates. This makes idempotency a property of the workflow's identity rather than defensive code scattered across call sites. Teams shipping mobile-to-backend workflows track patterns like this on daily.dev before they hit production.
How can I handle offline mobile events in Temporal so actions taken without connectivity are still recorded correctly?
Use Temporal's Signal-With-Start pattern: the client issues a signal that tells Temporal to deliver it to a workflow, starting that workflow first if it isn't already running. The mobile app buffers events locally in their original order and replays them on reconnect. Even if the initial 'start shift' event was lost, the first 'Task Complete' signal retroactively initializes the workflow and records the action with the device-captured timestamp. Developers building offline-first field apps find real-world Temporal patterns like this on daily.dev.
How do I keep sensitive PII out of Temporal Cloud while still using it as a managed orchestration layer?
Implement a Custom Data Converter that encrypts all workflow payloads client-side with AES-256-GCM before they leave your network. Temporal Cloud stores and routes the encrypted blobs without ever seeing plaintext PII. Decryption happens locally on the execution plane. This lets you use Temporal Cloud's managed availability and cluster-free operations while satisfying data-sovereignty requirements in regulated industries. Engineers navigating compliance constraints in regulated industries share approaches like this on daily.dev.