In Chaine Autopilot, conditions are optional filters you add to a rule to control whether it should actually do anything once the trigger fires.
Think of it like this:
“At this time (trigger) → only if these conditions are met → do the action.”
Conditions let you scope your rules to match specific freight, customers, scenarios, or issues. You can filter by:
Load attributes (e.g. trailer type, dispatcher name, origin city)
Appointment windows (e.g. ETA Receiver is today)
Tracking or POD status (e.g. tracking is off, POD not received)
And more
What conditions do vs. what they don’t
Conditions don’t determine when a rule runs. That’s the job of the trigger.
They only filter whether the rule actually proceeds. If the conditions are false, nothing happens.
Common use cases
Only send a reminder if tracking is off
Only ask for POD if delivery has happened
Only request ETA if the receiver appointment is today
Only trigger this rule for customer X or carrier Y
Combine multiple conditions
You can add more than one condition to a rule. By default, they’re treated as AND logic, all must be true for the action to fire.
Example:
ETA Receiver is today
AND Tracking is off
→ then send message
Field types & logic options
Depending on which field you choose (e.g. “Destination City” vs. “Tracking status”), the condition will show different logic operators.
For example:
Text fields (e.g. city, customer name) → is, is not, contains, etc.
Dates → is today, is before, is after, is within X days
Booleans → is true / is false
Statuses / dropdowns → equals, not equals
Numbers → greater than, less than, equal to
We’ll walk through examples of each below.
Text Fields
Examples: Customer Name, City, Warehouse Name, Sales Rep
Text fields allow you to match or filter against any free-text value. These are useful when your logic depends on a specific word, phrase, or partial match.
Available condition options:
is: Exact match (e.g. Customer Name is “Walmart”)
is not: Exact mismatch
contains: Checks if the field includes a specific string (e.g. City contains “Angeles”)
does not contain: Checks if the field does not contain a specific string
is empty: Field is blank
is not empty: Field has any value
Use cases:
“Only trigger for customer ABC.” → Customer name is ABC Freight
“Ignore loads where city isn’t assigned yet.” → Origin City is not empty
“Target loads by city pattern (e.g. anything in ‘New York’).” → Destination City contains New York
Date Fields
Examples: Destination Arrival, ETA Receiver, Origin Departure, Appointment Time
You can use date-based conditions to narrow a rule down to specific shipment timing. These are useful when you want a rule to run only if a shipment is scheduled for tomorrow, is overdue, or falls within a certain window.
Operators supported:
is
is before
is after
is on or before
is on or after
is not
Value options depend on the operator selected. You can choose from:
Today / Tomorrow / Yesterday
One week/month ago or from now
Number of days ago / from now (e.g. “3 days from now”)
Exact date (e.g. June 25, 2025)
Exact date and time
Custom date field (compare two shipment fields, like "ETA Receiver" vs. "Delivery Appointment")
Relative range, such as:
“is within the past number of days”
“is within the next number of days”
“is within the past week / month / year”
“is within the next week / month / year”
Important: How “today” works
Date conditions like "is today" may not behave the way you expect, especially if you're using them alongside time-based triggers. The reason why, is because the conditions evaluate any time a change happens to the load. So, your rule might never get scheduled, because the conditions will not match until the day of.
How to avoid this:
Use time-based triggers tied directly to the field you're filtering on.
Example: “At time of Origin Appointment” → avoids ambiguity entirely.
Avoid using is today with offset-based triggers.
It's too easy for evaluation timing to mismatch the field.
Use negative filters instead.
Origin Appointment is *not* tomorrow or is not today can be more reliable for excluding edge cases, though they still rely on accurate timing.
Use ranges instead.
Conditions like is within the next 1 day are generally more forgiving and reduce misfires from timing differences.
Boolean fields
Examples: Tracking Status, POD Received, Mobile App Settings
Boolean conditions check whether something is true or false — meaning it either is or isn't active, on, or set.
You’ll typically see options like:
Is: e.g. Is Tracking
Is Not: e.g. Is Not Tracking
Use cases:
“Trigger only if driver is not tracking.” → Tracking Status is Not Tracking
“Send a reminder when POD hasn’t been marked as received.” → POD Received is Not True
“Start workflow when mobile app is disabled.” → Mobile App Settings are Not Enabled
Tip: Boolean conditions are best paired with event-based triggers like “When all conditions match” — since they’ll immediately respond to a change in state (e.g. when tracking stops).
Status Fields
Examples: Shipment Status, Origin Stop Status, Destination Stop Status
Status fields allow you to match against one or more predefined values. These are useful for building rules around load lifecycle, stop progression, or milestone handling.
Available condition options:
is: Field matches exactly one status (e.g. is Needs Carrier)
is not: Field does not match the selected status
is any of: Match if the field equals any of the selected values (multi-select)
is none of: Match only if the field matches none of the selected values
is empty: Field is blank or not yet set
is not empty: Field has any value
Use cases:
“Only trigger if the shipment still needs coverage.” → Shipment status is Needs Carrie
“Ignore loads already in transit or delivered.” → Shipment status is none of In Transit, Delivered
“Target stops that haven’t been updated yet.” → Origin Stop Status is empty
“Trigger follow-up when a stop is completed.” → Destination Stop Status is Delivered
Number Fields
Examples: Distance Value, Load Weight
Use number fields to create rules based on numeric thresholds, great for logic tied to mileage, quantity, or any measurable figure on the load.
Available condition options:
equals: Exact match (e.g. Distance equals 500)
does not equal: Not equal to the specified number
is greater than
is greater than or equal to
is less than
is less than or equal to
is empty: Field has no value
is not empty: Field contains any numeric value
Use cases:
“Only trigger for long-haul shipments.” → Distance is greater than 500
“Exclude shipments under 150 miles.” → Distance is greater than or equal to 150
Wrapping Up Conditions
Conditions let you filter when a rule should proceed, they don’t decide when it runs (that’s the trigger’s job) or what it does (that’s the action). Use them to layer in logic that narrows your automation to the right context: customer, timing, location, status, or other shipment traits.
A good rule is: Triggers handle when, Conditions handle if, and Actions handle what.
Next, we’ll walk through Actions, the final part of your rule. This is where automation actually takes effect: sending a message, updating a status, logging a check call, or triggering a webhook.