Logistics automation: how a TMS should handle statuses and exceptions

A transport system may show “checked” without making it clear whether cargo can be released. Was the carrier checked, or the driver? Does the result concern the current assignment or a previous trip? Does no response mean rejection or a delayed external service? These questions affect dispatch work more than the number of connected integrations.

FreightWaves reported the integration of E3 driver screening into Transfix TMS. Transfix confirms the capability: assigning a driver triggers screening, and its state is visible in shipment data. The vendor also describes new APIs and webhooks for data exchange. This is information about a specific product, not a guarantee of fraud prevention. Transfix updates.

For another TMS, examining the design is more useful than copying the interface. Screening should participate in workflow rules and retain a clear meaning when data exchange fails.

Use three states instead of one flag

Consider a hypothetical shipment of construction materials. A dispatcher assigns a driver, identity screening starts, but the external service does not answer. The shipment is still planned. Screening awaits a result. The request transfer has timed out. These are three distinct states.

Combining them in one “error” field leaves the employee unsure what to do: repeat the request, change the driver or cancel the shipment? Showing “in progress” can make a missing result look like a successful check to management.

The proposed model stores shipment stage, screening state and exchange state separately, with allowed transitions for each. The business decides when the next action is permitted, who can grant an exception and what evidence must be retained. An API does not automatically define those rules.

Link each event to the specific assignment

The driver may change after the first successful response. The old result must not silently approve the new assignment. Link the response to the shipment, driver and assignment version. A late answer belongs to the version for which the request was sent.

This is a design recommendation for the hypothetical system, not a claim about Transfix's implementation. Before building it, verify the chosen service's capabilities: returned identifiers, duplicate-event information and the ability to request current state.

Change history distinguishes a correction from a new operation. Correcting a phone number, repeating a check for the same person and replacing a driver may require different actions. The dispatcher should see the currently valid result and why the previous one no longer applies.

Receipt time is not event time

Messages can arrive after the events they describe. If a system treats the last received record as the newest fact, a delayed update can move the shipment back to an earlier stage.

GS1 EPCIS distinguishes eventTime from repository recordTime. Its model also provides for declaring an error in an earlier event. This is a useful formal history model, although not every TMS needs EPCIS. GS1 event model.

For your own exchange, agree which timestamp describes the fact, who sets it and how corrections work. Simply overwriting a field destroys the basis for the previous decision. Sometimes a change log is enough; sometimes partners need a shared event format. The choice depends on actual participants and reconciliation requirements.

Put exceptions in the working interface

In the proposed workflow, dispatchers see a queue of screenings with no result. Each has a reason, last-attempt time and owner. Temporary unavailability permits retries under agreed rules. Conflicting data needs human review. These cases should not cycle indefinitely in one technical queue.

Manual approval requires authority and an explanation. A “skip” button without history makes control a formality. Equally, a dispatcher should not have to read technical logs for every trip. The interface should explain the shipment impact while leaving request details to support.

Before launch, test a lost response, duplicate message, late event and driver replacement. These are acceptance scenarios for the proposed integration. They should show whether the team can continue work and restore exchange without losing history.

Define the first stage

Begin with one transition, such as allowing an assigned driver to proceed to the next action. Describe the data, approval basis and exception path. Establish which system owns the current assignment and who handles unprocessed responses.

Measure confirmation waiting time, exception age and manual reconciliation work. Set targets after observing the existing process. Another company's feature announcement does not justify promises of savings or lower losses.

Exchange rules can be developed through API integration, with the exception queue connected to an internal working system. Prepare a diagram of one shipment and anonymised examples of conflicting statuses for discussion.

Make a data movement explainable

The archived Google Sheets inventory project describes receipts, consumption, stock balances and replenishment alerts. It preserves requirements and a design; final launch, current operation and measured results are not confirmed. This is not a TMS deployment, but it illustrates why a status label needs a specific movement and a responsible record owner. Otherwise one employee records a fact while another interprets it as a plan.

My guide to moving from spreadsheets to a system suggests tracing one order through its exceptions. For transport, examine the carrier event, status change, next operator and correction of conflicting information. That map helps turn the status discussion into integration requirements.

Sources

• FreightWaves: E3 driver screening integrated into Transfix, 6 October 2026. Source used to discover the topic.
• Transfix: Q3 2026 TMS product updates. Primary feature description.
• GS1: EPCIS ObjectEvent model. Formal description of event fields.

Sources checked on 7 October 2026. The proposed exception-handling framework is analysis; compatibility with specific APIs requires a separate check.