Skip to content
English
Customer portal
Go to Tai Software
  • There are no suggestions because the search field is empty.

Workflow Automation: Triggers, Filters, Actions

Reference for building a Tai TMS workflow from one trigger, optional filters, and one or more actions, and how the system decides to run it.

This is a reference for how a workflow in the Tai TMS is built from one trigger plus optional filters plus one or more actions, and how the Tai TMS decides whether a workflow's actions should run.

Overview

In the Tai TMS, a workflow (also called a workflow automation rule) is a saved rule that watches for one thing to happen and then does something on your behalf. Every workflow is made of three kinds of pieces:

  • One trigger — the event that starts the workflow, such as a shipment's status changing or an alert being added.
  • Zero or more filters — conditions that decide whether this particular shipment is one the workflow should act on, such as a specific customer, lane, status, or alert.
  • One or more actions — the work the Tai TMS performs when the trigger fires and the filters match, such as sending an email, adding or resolving an alert, sending shipment details to another system, or updating the status.

When the trigger's event happens on a shipment, the Tai TMS runs the workflow's steps in order. If every filter matches, the actions run. If a filter does not match, the workflow stops and the actions do not run. Filters are how you keep a workflow from firing on shipments it should not touch, and the Tai TMS records what every run did so you can review and tune your automation.

How it works

The three building blocks

Triggers (the starting event). A workflow is tied to exactly one trigger. The trigger names available in the Tai TMS include:

  • Shipment Created
  • Shipment Updated
  • Shipment Status Updated
  • Shipment Alert Added
  • Shipment Alert Resolved
  • Shipment Carrier Added or Updated
  • Shipment Carrier Removed
  • Spot Quote Added
  • Attachment Added
  • Assignment Added
  • Shipment Scheduler (runs on a monthly, weekly, or recurring schedule rather than in response to a single edit)
  • Carrier Check Call Response
  • Shipment Stop Alert Added
  • Shipment Stop Alert Resolved
  • Shipment Action Log (a time-delay trigger: after a chosen kind of shipment activity-log entry is recorded, it waits for a delay you set — at least 1 minute — and then runs)
  • Driver Tracking Canceled (runs when a shipment's driver-tracking session is canceled)

Note that there is no separate "alert removed" trigger. Removing an alert is handled as Shipment Alert Resolved (or Shipment Stop Alert Resolved for a stop-level alert).

Filters (the conditions to match). Filters narrow a workflow to the right shipments. The Tai TMS offers a broad set of filters, including:

  • Customer, Organization, LSP Staff, Carrier (LSP), Carrier Label
  • Status, Original Status, Transit Status
  • Alert, Original Alert, Resolved Alert, Active Alert Expiration, Alert Created Comparison, Stop Alert, Resolved Stop Alert
  • Origin, Destination, Stop Type, Shipment Stop Count, Last Location Update
  • Pickup Date, Delivery Date
  • Buy Rate, Sell Rate, Margin Percentage, Open Credit Limit, Committed Volume
  • Shipment Type, Shipment Equipment Type, Shipment Source, Shipment Reference Number, Attachment Type, Current Temperature, Compare Shipment Data
  • Pickup Audit Missing, Delivery Audit Missing
  • Accessorial
  • Has Open Tenders, Dynamic Tender Timeout, Waterfall Exhausted (used with tender waterfall automation)

Different filters offer different comparison options. Text-style filters commonly offer Equals, Not Equals, Starts With, Contains, and Does Not Contain. Number-style filters offer Equals, Not Equals, Between, Greater Than, and Less Than comparisons. Date-style filters offer a large set of ranges such as Today, Yesterday, This Week, Last 7 Days, Next 30 Days, This Month, This Quarter, Year To Date, and many others. The alert-style filters offer two options: Contains (the alert is present) and Does Not Contain (the alert is not present).

Actions (the work to perform). When the trigger fires and the filters match, the workflow performs its actions. Available actions include:

  • Send Email
  • Update Status
  • Add Alert, Resolve Alert
  • Add Shipment Stop Alert, Resolve Shipment Stop Alert
  • Add Assignment, Add Assignment with Message, Resolve Assignment, Resolve All Assignments
  • Carrier Check Call, Assign Carrier Check Call Activity
  • Add Shipment Reference Number, Remove Shipment Reference Number
  • Add Carrier, Remove Carrier, Add Carrier Label
  • Update Fuel Buy Rate, Update Fuel Sell Rate
  • Advance To Next Stop
  • Send Secure Rate Confirmation
  • Send Webhook
  • Call AI Agent
  • Send Next Tender, Demote Current Tender (used with tender waterfall automation)

The Send Webhook action

Send Webhook posts the shipment's current details to a web address you enter in the step. The content is the same shipment-detail content the Tai TMS public API returns for a shipment. If the receiving system requires sign-in, the step can carry a username and password or an authorization value. The Tai TMS makes a single delivery attempt per run. If no web address is entered, the step is logged as not completed with the reason, and the workflow stops at that step. If an address is entered, the step shows as completed once the call has been made — even when the receiving system was unreachable or answered with an error — because the outcome of the call is kept in Tai's webhook activity records rather than in the workflow log.

Tender waterfall steps and the Committed Volume filter

Tender waterfall automation offers a shipment's ranked carriers one at a time. The steps below are used for it, and the Send Next Tender, Demote Current Tender and Committed Volume steps only work when tender waterfall is enabled; otherwise they report that they are disabled and the workflow stops there.

  • Send Next Tender emails a tender to the next ranked carrier (or the next group of carriers ranked together) that has not yet been offered the load. A carrier that is over its committed volume cap for the pickup date is skipped. If every remaining carrier is over its cap, no tender is sent and the queue is left as it was. The step can optionally widen to a generic fallback carrier list once the ranked list is used up, and can optionally schedule a follow-up check when the tender window ends.
  • Demote Current Tender takes the outstanding tender off the carrier. By default the carrier's offer stays on the shipment as a standing offer that can still be booked; the step can instead be set to expire the offer.
  • Has Open Tenders passes when the shipment has an outstanding tender or a standing offer.
  • Dynamic Tender Timeout passes when there is no outstanding tender, or when the current tender has been out longer than its window. The window is the time left until pickup minus a buffer (30 minutes by default), never less than 15 minutes and never more than a ceiling (180 minutes by default), so it gets shorter as pickup approaches.
  • Waterfall Exhausted passes when the shipment has a waterfall, no carrier has been selected, no tender or standing offer is outstanding, and no untried carrier remains.
  • Committed Volume passes when at least one queued carrier is still within its committed volume cap. It fails when all queued carriers are over their caps for the pickup date or when there are no queued carriers, and its log message names any carriers that were passed over.

A committed volume cap is a limit on loads per day (at least 1) for one carrier on a lane, defined by an origin region and a destination region (either can be left open to mean "any"). A carrier counts as over its cap for a shipment when it already has at least that many other shipments on the same pickup date, for the same organization, on a matching lane.

How a workflow is evaluated when its trigger fires

When the trigger's event happens on a shipment, the Tai TMS runs that workflow's steps in the order you arranged them:

  1. It works through the steps one at a time, in sequence.
  2. At each filter step, it checks whether the shipment matches. If it matches, evaluation continues to the next step. If it does not match, the workflow stops right there and no later step runs.
  3. At each action step, it performs the action, then continues to the next step. If the action cannot be completed (for example a Send Webhook with no web address), the workflow stops at that step.
  4. The workflow finishes when it reaches the end (all steps done) or stops early because a filter did not match or an action could not be completed.

Because the steps run in order and a failed filter stops everything after it, the normal way to author a workflow is to put your filters first and your actions after them. That produces the expected behavior: the trigger fires, all the filters must match, and only then do the actions run. A filter placed after an action will not gate that earlier action.

Every run is recorded. The Tai TMS writes a log for each workflow run showing which steps passed, which filter (if any) stopped the run, and which actions completed. You review these in the automation monitoring area, which is separate from where you build the rules.

A workflow that starts from a delay or a schedule evaluates its filters when it runs, against the shipment as it is at that moment, not as it was when the delay started. Scheduled and on-demand runs consider up to 500 matching shipments per run, newest first.

The Original Alert filter (precise behavior)

The Original Alert filter is easy to confuse with the plain Alert filter, and the difference is the whole point of it.

  • The plain Alert filter looks at the shipment's alerts as they stand right now — the current, live set of active alerts at the moment the workflow is running.
  • The Original Alert filter looks at the shipment's alerts as they were just before the change that started the workflow — a snapshot of the alert set captured at the beginning of the run, before the triggering edit was applied.

Both filters work the same way otherwise. You choose one or more alerts and a mode:

  • Contains — the step passes if at least one of the chosen alerts was present in that alert set.
  • Does Not Contain — the step passes if none of the chosen alerts were present.

Only unresolved (active) alerts count; a resolved alert is treated as not present.

Why the "original" snapshot matters: when an alert is added or resolved, the current set and the pre-change set differ by exactly that alert.

  • On a Shipment Alert Resolved trigger, the alert that was just resolved is already gone from the current set, but it is still present in the original snapshot. So if you want a workflow to act based on "this alert was on the shipment right before it got resolved," you must use the Original Alert filter — the plain Alert filter would no longer see it.
  • On a Shipment Alert Added trigger, the newly added alert is in the current set but not in the original snapshot, so the Original Alert filter lets you check what the shipment already had before the new alert arrived.

Correction to a common misconception: the Original Alert filter does not simply check whether an alert is present "at the moment the trigger fires." That describes the plain Alert filter (current state). The Original Alert filter checks the alert set as it was immediately before the triggering change (the original snapshot), and it supports both "was present" (Contains) and "was not present" (Does Not Contain) — it is not limited to requiring an alert to be present.

Business rules & limits

  • A workflow has exactly one trigger. It only runs in response to that trigger's event. If you need the same actions for two different events, you build two workflows.
  • Filters must match for actions to run, and order matters. Steps run in sequence; the first filter that does not match stops the run, so any action after that point does not happen. Author filters before actions.
  • An action that cannot finish also stops the run. If an action reports that it could not be completed (for example a missing web address, a tender that could not be sent, or a feature that is not enabled), the run stops at that step and the log shows why. A step that fails unexpectedly is recorded as an error rather than a normal stop.
  • Workflows are automatically scoped to the owning organization. Unless a workflow already includes an Organization filter (or the owner is set up for organization-level invoicing), the Tai TMS adds an organization scope automatically so a rule does not act on another organization's shipments. This is expected behavior, not an error.
  • The alert filters offer only two modes. The Alert, Original Alert, Resolved Alert, Stop Alert, and Resolved Stop Alert filters use Contains and Does Not Contain only, and they consider only unresolved (active) alerts.
  • The Original Alert filter is meant for alert-triggered workflows. The pre-change alert snapshot it reads is captured only when an alert is added or resolved. It is meaningful on the Shipment Alert Added and Shipment Alert Resolved triggers (and their stop-level equivalents), where that snapshot exists. On any other trigger — including scheduled and delayed runs — there is no snapshot, so the step cannot be evaluated and the run is logged as an error.
  • Shipment-level and stop-level alerts are separate. The plain Alert filter looks only at shipment-level alerts and ignores alerts attached to a specific stop. Stop-level alerts have their own triggers (Shipment Stop Alert Added / Resolved) and their own filters (Stop Alert, Resolved Stop Alert).
  • Loop-safety rules apply. A workflow started by the Assignment Added trigger does not carry out an Add Assignment step; the run stops at that step, so an automation cannot trigger itself through assignments. More generally, a workflow that is already running for a shipment is not started again by changes it makes to that same shipment, and a chain of workflows that trigger one another stops after a few levels.
  • Delayed workflows wait at least 1 minute. The delay on the Shipment Action Log trigger is set in hours and minutes, and the total must be at least 1 minute. A delayed run does nothing if the workflow has been turned off or the shipment no longer exists.
  • Scheduled runs are time-zone aware and not more frequent than every 15 minutes. A schedule can be monthly, weekly, or recurring inside a daily start-and-end window, in the time zone chosen for that schedule. The scheduler checks every 15 minutes, and a recurring schedule repeats no more often than every 15 minutes.
  • On-demand runs are throttled. A scheduled workflow can be started on demand, but not again within 30 minutes of the previous on-demand run.
  • Workflows run as a designated staff account. Each workflow runs as the staff account chosen for it (or the organization's default automation account), so what it can see and do follows that account's access.
  • Some triggers, filters, and actions are switched on gradually. The Shipment Action Log and Driver Tracking Canceled triggers, the Last Location Update, Shipment Stop Count, Active Alert Expiration, and Alert Created Comparison filters, and the tender waterfall steps are introduced behind feature switches and may not be available in every environment until enabled.
  • Building rules and monitoring rules are different areas. You author and edit workflows in one place and review what they actually did (the run log and coverage) in the automation monitoring area. Both are part of the same feature.

Frequently asked questions

What are the three parts of a workflow in the Tai TMS?

A workflow is built from one trigger, zero or more filters, and one or more actions. The trigger is the event that starts the workflow (such as a status change or an alert being added). Filters decide whether a given shipment qualifies (such as a specific customer, lane, or alert). Actions are what the Tai TMS does when the trigger fires and the filters match (such as sending an email or updating the status).

What triggers can start a workflow?

In the Tai TMS the available triggers include Shipment Created, Shipment Updated, Shipment Status Updated, Shipment Alert Added, Shipment Alert Resolved, Shipment Carrier Added or Updated, Shipment Carrier Removed, Spot Quote Added, Attachment Added, Assignment Added, Shipment Scheduler, Carrier Check Call Response, Shipment Stop Alert Added, Shipment Stop Alert Resolved, Shipment Action Log (after a delay of at least 1 minute), and Driver Tracking Canceled. Each workflow uses one of these.

What does the Original Alert filter actually do?

The Original Alert filter checks the shipment's alerts as they were immediately before the change that started the workflow — a snapshot taken at the beginning of the run — rather than the current, live set of alerts. You pick one or more alerts and choose Contains (passes if one of them was present in that earlier snapshot) or Does Not Contain (passes if none were). Only active, unresolved alerts count. This is what lets a workflow react to an alert that has just been resolved: that alert is already gone from the current set but is still in the original snapshot.

How is the Original Alert filter different from the plain Alert filter?

The plain Alert filter looks at the shipment's alerts as they stand right now (the current state). The Original Alert filter looks at the alerts as they were just before the triggering change (the pre-change snapshot). Otherwise they behave the same, offering Contains and Does Not Contain and counting only unresolved alerts. Use the plain Alert filter to test the current alerts; use the Original Alert filter to test what was there before the change — for example, on a Shipment Alert Resolved trigger, to confirm a specific alert had been present right before it was resolved.

What actions can a workflow perform?

Actions in the Tai TMS include Send Email, Update Status, Add Alert, Resolve Alert, Add and Resolve Shipment Stop Alert, several assignment actions (Add Assignment, Add Assignment with Message, Resolve Assignment, Resolve All Assignments), Carrier Check Call, Add and Remove Shipment Reference Number, Add Carrier, Remove Carrier, Add Carrier Label, Update Fuel Buy Rate, Update Fuel Sell Rate, Advance To Next Stop, Send Secure Rate Confirmation, Send Webhook, Call AI Agent, and the tender waterfall actions Send Next Tender and Demote Current Tender.

What does the Send Webhook action send, and what happens if it fails?

In the Tai TMS, Send Webhook posts the shipment's current details — the same content the public API provides for a shipment — to the web address entered in the step, optionally with a username and password or an authorization value. It makes a single delivery attempt per run. If the web address is blank, the step is logged as not completed with the reason, and the workflow stops at that step so later steps do not run. If an address is entered, the step shows as completed once the call has been made, even if the receiving system was unreachable or returned an error; the outcome of the call is kept in Tai's webhook activity records rather than in the workflow log, so confirm the address and the receiving system independently.

What is the Committed Volume filter?

In the Tai TMS, the Committed Volume filter is used with tender waterfall automation. It passes when at least one queued carrier on the shipment is still within its committed volume cap — a limit on loads per day for a carrier on a lane — and fails when every queued carrier is already at or over its cap for the pickup date, or when there are no queued carriers. The filter only works when tender waterfall is enabled. When the Send Next Tender action runs, it skips any carrier that is over its cap and, if all remaining carriers are over their caps, sends no tender and leaves the queue unchanged.

Can a workflow wait before it acts?

Yes. A workflow that uses the Shipment Action Log trigger starts when a chosen kind of entry is recorded in the shipment's activity log, waits for the delay you set (at least 1 minute), and then evaluates its filters and actions against the shipment as it is at that time. If the workflow has been turned off or the shipment no longer exists, the delayed run does nothing.

How does the Tai TMS decide whether a workflow's actions run?

When the workflow's trigger event happens on a shipment, the Tai TMS runs the workflow's steps in the order you set. At each filter it checks whether the shipment matches; if it does, it continues, and if it does not, the workflow stops there and no later step runs. Actions perform their work and then continue; an action that cannot be completed also stops the workflow. So the actions run only when the trigger fires and every filter ahead of them matches. Because a filter stops everything after it, you should place filters before actions.

Does the order of filters and actions matter?

Yes. Steps run top to bottom in the order you arrange them, and the first filter that does not match stops the run, so anything after it — including actions — does not happen. The reliable pattern is to put all of your filters first and your actions after them, so the workflow reads as "when this trigger fires and all of these conditions match, do these things." A filter placed after an action cannot prevent that earlier action from running.

Will one workflow act on another organization's shipments?

No. Unless a workflow already includes an Organization filter, the Tai TMS automatically scopes the workflow to the organization that owns it, so it only acts on that organization's shipments. This automatic scoping is expected and helps prevent a rule from reaching shipments it should not touch.

Can a workflow trigger itself or other workflows in an endless loop?

No. The Tai TMS has loop protection: a workflow that is already running for a shipment is not started again by the changes it makes to that shipment, a chain of workflows that trigger one another is cut off after a few levels, and an Add Assignment step in a workflow that starts from the Assignment Added trigger is not carried out.

Can I tell what my workflows did after they ran?

Yes. The Tai TMS records a log for every workflow run showing which steps passed, which filter (if any) stopped the run, and which actions completed. You review these in the automation monitoring area, which is separate from the area where you build and edit the rules. Checking the log is how you confirm a workflow is behaving as intended and tune it over time.