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.
π― 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.

π 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.