Order Journeys

Define order lifecycles with milestones and thresholds

An order journey is a way of defining the life cycle of an order. A journey consists of a set of milestones that are key points in the order's journey, for example, when the order is placed, when the shipment is delayed, or when it has been delivered.

7 Jan10:28
Order ReceivedCervera has received the order
Order Sent
Order Delivered

Each milestone is defined by thresholds that must be met for the milestone to be considered reached. These thresholds can be based not only on events from the transporter but also on events from other systems, time constraints, and more. This approach makes the journey a very powerful and flexible tool for keeping track of what happens to the order.

Each shipment of the order will be described by its own journey, which allows you to keep track of multi-shipment orders as well. A single shipment can also have multiple journeys, which allows you to define one journey that is presented for the end-customer, one for triggering notifications, and one for statistical purposes, etc.

To learn more about how to use order journeys using our API, please refer to our order journey API documentation.

Milestones

A milestone represents a key point in the order journey. Some examples of milestones are:

  • Order received - The warehouse received notification about the order.
  • Order delayed - The transporter notified us with a delay event or more than X days passed without it being picked up.
  • Delivery after promised delivery time - It has been delivered but it was after the promised delivery time.
  • Shipment is going to Norway - Norway is the destination country.

It's worth noting that a milestone can belong to multiple journeys, allowing you to easily reuse the same key point to mean different things in different contexts.

Milestones that represent successful delivery can be marked Counts as delivered in the journey editor. Completing one of these milestones supplies the delivery time used by delivery predictions. The default journey marks both Delivered and Ready for pickup this way.

Milestone completion

Once a milestone is completed, it stays completed — even if the thresholds that triggered it later become false.

For example, if a time-based threshold as part of a milestone is met (e.g. "3 days since latest event"), both the threshold and the milestone are considered reached when it has been 3 days since the latest event. But if a new event comes in after that and resets the clock, that specific threshold is no longer met and is therefore marked as such. That doesn't affect the milestone's status — it remains marked as completed.

Conditions and thresholds

Milestones are reached based on defined thresholds, such as transporter events, time constraints, or order and shipment properties like the destination country. To learn more about configuring events for transporters or other systems, please refer to our events documentation.

Thresholds are grouped into conditions, which determine milestone completion. A simple milestone might have one condition with one threshold, while a complex one could include multiple conditions and thresholds. For example, an "order delayed" milestone might check for a delay event and whether X days have passed without pickup.

You can specify whether all or any thresholds in a condition must be met, and whether all or any conditions must be satisfied for the milestone to be considered reached.

Threshold Types

Skrym supports several types of thresholds to enable flexible milestone definitions:

  • Event-based thresholds - Triggered when specific tracking events occur (e.g., delivery, delay, pickup events)
  • Time-based thresholds - Triggered based on time constraints (e.g., "3 days since latest event")
  • Property-based thresholds - Triggered based on order or shipment properties (e.g., destination country, transport method, shipment or parcel counts)
  • Milestone-based thresholds - Triggered when another milestone is reached

Event, categorical-property, and milestone thresholds can each select more than one value. This avoids duplicating otherwise identical thresholds when, for example, either of several carrier events should complete a milestone.

ThresholdAvailable multi-value comparisons
EventAny or all selected events exist; any or all selected events do not exist. “Any do not exist” is true until every selected event has occurred.
Categorical propertyThe current value is any of, or none of, the selected values.
MilestoneAny, all, or none of the selected milestones are completed.

Numerical property thresholds remain scalar comparisons. As with every threshold, a milestone that has already completed remains completed even if a later event or property update makes its threshold false.

Numerical property thresholds are particularly useful for orders with multiple shipments or parcels. For example, you might want to mark an order as "Partially Delivered" when at least 2 shipments have been delivered, or "Ready for Pickup" when all parcels are available.

Numerical properties support the following comparisons:

  • Equal to a specific count
  • Not equal to a specific count
  • Greater than a specific count
  • Less than a specific count
  • Greater than or equal to a specific count
  • Less than or equal to a specific count

The numerical property can be based on either:

  • Number of tracked shipments in the order
  • Number of tracked parcels in the order
Count Threshold Considerations
  • Handling for count thresholds: Before enabling count-based thresholds (especially parcel counts), verify parcel handling for each transporter you use. We have occasionally seen duplicate parcels caused by mismatched incoming references, which can skew counts.
  • Order-level count behavior in milestones: For order-level count thresholds, the threshold state can change as counts change, but milestone state does not revert once completed. Example: shipment count <= 1 can become unmet after a second shipment is added, while the milestone stays completed.

Triggers

When a milestone in a journey is reached, you can trigger some action. These allow you to react to what happens to your orders and can help you notify your customers or update your internal systems. To learn more about setting up triggers, please refer to our triggers documentation.

Default journey

To get started, Skrym provides a set of predefined milestones that can be used to define the journey of an order:

MilestoneDescription
Order ReceivedWarehouse received notification about the order.
Order SentWarehouse handed over the package to the carrier.
Order DelayedThe transporter notified us with a delay event.
Order DeliveredPackage delivered to the final location.

These milestones are assigned to you by default during onboarding and Skrym creates a default journey. This means you can start using them right away without any additional setup. You can simply track an order and assign the predefined journey to it.

The editor's milestone cards show condition and threshold counts. When simulating a journey, they show met/total counts, respecting each condition's all/any logic. Select the summary to open the full condition editor.

Time relative to a selected milestone

Time thresholds can use When a selected milestone was reached instead of the latest milestone of any type. Choose another milestone in the same journey; only its completion in that shipment's journey starts the timer.

For example, configure a milestone for three hours after the “Received at warehouse” milestone. Positive offsets, before/after comparisons, and working-day holiday handling apply. Until the selected milestone completes, the time threshold is unmet—even with a “Before” comparison.

The selected milestone cannot be the milestone containing the threshold, and must remain in the journey. Existing shipment snapshots retain their selected milestone when the journey definition is edited.

Selected-milestone timers cannot subtract time from completion. A “Before” rule requires a positive added duration, meaning “within that duration after completion.” A zero-duration or unadjusted “Before” rule is rejected because its window would already be closed when the milestone completes.