A single threshold across your entire operation is too blunt. A parcel sitting uncollected at a pickup point for three days needs a message today β€” a parcel quiet in customs for three days is completely normal. Transit times vary just as much, by carrier, warehouse, and destination.
Shipment transit delay and Shipment stalled are now rule-based:
you decide which shipments each rule covers, and how many days should pass before an event is sent.
image
🎯 Rules for the lanes that need them
Each event opens the conditions that actually affect it:
  • Shipment transit delay
    β€” Carrier, Location, and Destination (countries, plus provinces and states)
  • Shipment stalled
    β€” Carrier and shipment status, down to individual sub-statuses
Your rule list starts with one baseline rule covering everything, so the event works the moment you turn it on. Add a rule only where part of your shipping needs different timing β€” the baseline becomes Other conditions and catches the rest, including carriers added later.
Rules never overlap
, so every shipment matches exactly one, and you never have to work out which rule wins.
image
image
πŸ“ˆ Escalating alerts from a single rule
A rule can hold several thresholds. Set an uncollected-pickup rule to 3, 8, and 14 days and each sends its own event: a friendly nudge, then a reminder naming the collection deadline, then a final notice before the carrier returns the parcel. Each threshold fires once per shipment.
πŸ”— Rule ID in every event
Every rule carries a short Rule ID, included in each event it sends. Filter on that one value in your automation tool instead of rebuilding a long list of conditions there β€” and the ID stays the same when you change what the rule covers, so your automations keep running untouched. Pair it with transit_time or residence_time to send a different message at each threshold of the same rule.
Full setup guide with configuration examples: CWILL Tracking Events and Triggers Overview
Thank you for being a part of the CWILL Tracking journey.