The transport record in Vigilo: what is connected and what stays in your systems

One transport operation crosses several systems

An order may arrive through EDI, be clarified by email, receive a time slot through a portal, be created in a TMS and later be completed by a CMR consignment note and an invoice. Each system holds a useful part of the operation. None necessarily contains the full history required to explain the next decision.

The Vigilo record provides that continuity. It does not centralize every piece of content by default: it retains the links, versions and elements required to classify an event, apply an authorized rule, prepare or execute an action and verify the outcome.

What the record connects

What remains in your systems

The TMS remains the chosen business system for orders, resources and the statuses it owns. The inbox retains correspondence. Portals continue to expose their information and functions. Master-data systems remain responsible for their data.

Vigilo does not attempt to rebuild these applications. It consults and uses only the elements authorized for the workflow. When data must be changed, the action takes place in the relevant system; the record retains the audit trail and verified outcome.

A timeline, not a static form

1. 01
   Request received

   The signal is classified and linked to a new or existing record.

2. 02
   Context reconstructed

   Relevant values, their sources and applicable rules are brought together.

3. 03
   Decision prepared

   Vigilo presents the possible action, required checks and points that need approval.

4. 04
   Action executed

   The business system is updated through the method authorized for the workflow.

5. 05
   Outcome verified

   The observed state is compared with the expected result and any discrepancy is flagged.

6. 06
   History enriched

   Amendments, evidence and decisions remain available for later controls, including invoicing.

Example: an order amended less than 24 hours before departure

The initial order is created in the TMS from an EDI message. The customer then brings the time slot forward by email. Vigilo links the message to the record, retains the previous and new slots, and looks up the validated rule for this type of amendment.

If the scope permits the update, Vigilo prepares or executes the TMS action and checks the displayed value. If approval is required, the operator receives the reconstructed record with its sources, rule and proposed action. During invoice control, the amendment remains connected to the performed service and any relevant pricing conditions.

Adapting to the actual technology landscape

Some companies have comprehensive APIs; others rely on screens, portals or file exports. Some organize records around a TMS identifier; others combine a customer reference, trip and document. Vigilo configures sources, identifiers, rules and controls around the way the operation actually works.

This adaptability is built on a shared, versioned foundation. An API integration is preferred when it reliably exposes the required function. Interface interaction can complete the workflow when necessary and validated. In both cases, permissions, screen changes, errors and post-action verification belong in the test scope.

• identify the system of record for each type of information;
• define the keys that link events to the transport record;
• configure rules, roles and authorization levels;
• test actions against the system versions that are actually in use;
• version mappings and suspend a scenario when an unvalidated change occurs.

What the record must not conceal

Information may be unavailable, two sources may conflict or one event may match several transport operations. The record must not create artificial certainty. It identifies the selected sources, ambiguities and reason why processing stopped.

The team then receives an actionable case: what is known, what is missing, the candidate links and the decision required. Continuity remains useful even when no automated action is permitted.

From individual records to operational memory

When records retain their events, decisions and outcomes, the company can observe its own operating patterns: causes of rework, frequent amendments, approval delays or recurring discrepancies. These findings remain explainable because they link back to the records from which they were derived.

Repeated decisions can then surface candidate rules. They are activated only after their meaning and scope have been validated. The record therefore becomes the foundation of governed operational memory rather than a simple accumulation of data.