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, 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 schedule rather than in response to a single edit)
  • Carrier Check Call Response
  • Shipment Stop Alert Added
  • Shipment Stop Alert Resolved
  • Shipment Action Log (runs after a configurable delay once a shipment activity-log entry is recorded)
  • Driver Tracking 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)

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.
  4. The workflow finishes when it reaches the end (all steps done) or stops early because a filter did not match.

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.

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.
  • 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 when an alert is added or resolved. It is most meaningful on the Shipment Alert Added and Shipment Alert Resolved triggers (and their stop-level equivalents), where that snapshot exists. On triggers that are not about alerts, there is no original-alert snapshot to compare against, so the filter has nothing meaningful to match.
  • Shipment-level and stop-level alerts are separate. When stop-level alerts are enabled, 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).
  • A loop-safety rule applies to assignments. A workflow started by the Assignment Added trigger will skip an Add Assignment action, so an automation cannot trigger itself in an endless loop.
  • If a step errors, the run stops and is recorded as an error. If a step cannot finish (for example, a misconfigured action), the Tai TMS stops that run and logs it as an error rather than partially completing in an unpredictable way.
  • 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 configurable delay), 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.

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