Order Move

Order moves provide an ordered, domain-neutral routing plan within an order. An order owns moves, and each move owns ordered legs. Vertical details such as container, chassis, appointment, and leg type belong in customValues.

OrderMove

Property	Type	Required	Description
OrderMoveId	int	Yes	Primary key
OrganizationId	int	Yes	Tenant scope
OrderId	int	Yes	Parent order
Sequence	int	Yes	1-based position within the order
Name	string?	No	Display label
AssignedDriverContactId	int?	No	Assigned driver or resource
OrderMoveStatusId	int?	No	Current move status
StartDate	DateTime?	No	Move start
EndDate	DateTime?	No	Move end
OrderMoveLegs	OrderMoveLeg[]	No	Legs ordered by sequence
DispatchRouteStops	DispatchRouteStop[]	No	Trip stops executing this move, ordered by route and planned sequence
TrackingEvents	TrackingEvent[]	No	Move-level milestones
CustomValues	Dictionary	No	Vertical-specific data

OrderMoveLeg

Property	Type	Required	Description
OrderMoveLegId	int	Yes	Primary key
OrderMoveId	int	Yes	Parent move
Sequence	int	Yes	1-based position within the move
Name	string?	No	Leg label
OrderMoveLegStatusId	int?	No	Current leg status
StartDate	DateTime?	No	Actual arrival/start
EndDate	DateTime?	No	Actual departure/end
TrackingEvents	TrackingEvent[]	No	Leg-level milestones
CustomValues	Dictionary	No	Location, appointment, and vertical data

OrderMoveStatus and OrderMoveLegStatus are organization-defined dictionaries. Both contain statusName, statusDescription, statusStage (Pending, InProgress, or Completed), priority, color, and customValues.

Behavior

• Creating an order can include orderMoves. The order ID is supplied by the new aggregate, and each move defaults its sequence to its array position unless an explicit sequence is provided. Nested legs are created with 1-based array-order sequences.
• Order/Import@1 accepts orderMoves with nested orderMoveLegs. Existing records match by ID first, then configured orderMoveMatchByFields or orderMoveLegMatchByFields (including dotted customValues paths), and finally by sequence/array position. Unmatched records are appended; records omitted from an import are left untouched.
• Creating a move accepts nested legs and assigns their sequence from array order.
• Dynamic updates are sparse. When orderMoveLegs is supplied, existing legs with IDs are updated, new legs are added, omitted or explicitly isDeleted legs are soft-deleted, and only active legs consume sequence positions. New legs already marked deleted are ignored.
• Supplying orderMoves through a dynamic order update applies the same reconciliation to the whole move collection. Existing moves are sparse-updated, new moves inherit the order and organization, omitted or explicitly deleted moves are soft-deleted, and active moves are resequenced from 1. The update command loads nested moves and legs so the aggregate can cascade these changes.
• Move and leg status lifecycle logic keys on statusStage, not the organization-defined status name.
• Tracking events may be linked to a move or leg for customer-visible milestones.
• A move exposes its executing trip stops through DispatchRouteStops. This is the inverse of DispatchRouteStop.OrderMoveId; one move may span stops on multiple dispatch routes.
• Workflow tasks are OrderMove/Create@1, OrderMove/Update@1, and OrderMove/Delete@1.