Workflow Automation and Carrier Connections

This article explains how the Tai TMS lets you automate repetitive work with rules, and what it means for a carrier to be connected to the Tai TMS electronically (by API or EDI) so that dispatch, tracking, and invoicing can happen automatically.

Overview

The Tai TMS reduces manual work in two complementary ways. First, workflow automation lets you set up rules that watch for something to happen on a shipment and then take action on your behalf — for example, sending a message, handing shipment details to another system, or advancing a step when a condition is met — so your team doesn't have to remember to do it by hand. Second, electronic connections to carriers (over an API or EDI link) let the system exchange information directly with a carrier's own systems, which is what makes automated dispatch, automatic tracking updates, and electronic invoicing possible. Together these features move routine load handling from manual phone calls and emails to hands-off, rule-driven processing.

How it works

Workflow automation rules. You build automation rules in the setup area of the Tai TMS. Each rule has the same basic shape:

A trigger / condition to watch for. A rule is tied to something that can happen to a shipment or in your operation — a status change, an alert being added or resolved, a carrier being added, an attachment arriving, a driver-tracking session being canceled, or another event — that the system watches for. Two kinds of trigger work on a clock rather than on a single edit: a scheduled trigger, and a delayed trigger that waits after a shipment activity-log entry is recorded (see below).
Filters that narrow it down. You can scope a rule so it only runs for the shipments you care about — for example, only certain customers, certain lanes or regions, or shipments that match particular criteria — so the automation doesn't fire on loads it shouldn't touch.
One or more actions (steps) to perform. When a shipment matches the trigger and passes the filters, the rule carries out its steps automatically — such as sending an outgoing email, adding or resolving an alert, assigning work to a person, updating a status, advancing a shipment to its next stop, or sending the shipment's details to another system with Send Webhook.
Optional scheduling. Rules can be scoped to run on a schedule or within particular time windows, so automation happens when you want it to.

The full lists of triggers, filters, and actions, and the exact way a rule is evaluated, are in the companion reference article, "Workflow Automation Reference: Triggers, Filters, and Actions."

Scheduled rules. A scheduled rule can run monthly (on a chosen day of the month), weekly (on chosen weekdays at a chosen time of day), or recurring (on chosen weekdays, repeating at an interval inside a daily start-and-end window). Each schedule has its own time zone. A recurring schedule repeats no more often than every 15 minutes. Scheduled rules are checked every 15 minutes, so a rule normally starts within about 15 minutes after its scheduled time.

Delayed rules (the Shipment Action Log trigger). A delayed rule starts when a chosen kind of entry is recorded in a shipment's activity log, but it does not act immediately. It waits for a delay you set — in hours and minutes, with a minimum of 1 minute — and then runs its filters and actions against the shipment as it looks at that later moment. This is useful for follow-ups such as "if nothing has changed an hour after this entry, do X." If the rule has been turned off in the meantime, or the shipment no longer exists, the delayed run does nothing.

Send Webhook. The Send Webhook action posts the shipment's current details — the same shipment-detail content the Tai TMS public API provides — to a web address you enter, so your own system or a partner's system is updated automatically. You can include a username and password or an authorization value if the receiving system requires one. The Tai TMS makes one delivery attempt per run. If the web address is blank, the action is recorded as not completed and the rest of the rule does not run. If an address is present, the step shows as completed once the call has been made, even if the receiving system was unreachable or answered with an error; the outcome of the call is kept in Tai's webhook activity records rather than in the workflow log, so make sure the receiving system is reachable and its address is correct.

Automated carrier tendering. For organizations that use tender waterfall automation, a rule can send the next ranked carrier a tender and move on to the following carrier if the first one does not respond, using steps such as Send Next Tender and Demote Current Tender and filters that check for open tenders, tender timeouts, an exhausted list, and committed volume. A carrier can be given a committed volume — a cap on how many loads per day it can take on a lane (an origin region and a destination region, either of which can be left open to mean "any") — and the tender steps skip a carrier that already has that many loads on the same pickup date. This feature is rolled out separately and may not be enabled for every organization.

You can create, duplicate, and delete rules, and you can test a rule before turning it loose, so you can confirm it behaves the way you expect. A scheduled rule can also be started on demand. Once rules are live, the Tai TMS keeps a running record of what the automation did — which rules fired, what messages went out, and how well your automation is covering your shipments — so you can monitor and tune it over time.

Electronic carrier connections. Separately from automation rules, carriers can be connected to the Tai TMS electronically. There are two connection types:

API connection — a direct, real-time link to the carrier's system. Requests and responses happen right away.
EDI connection — a standardized electronic-document exchange. Documents are exchanged in batches rather than answered live, so it is slower than API.

A carrier's electronic connection is what powers three kinds of automation:

Automated dispatch — the Tai TMS can tender a load to the carrier electronically instead of you calling or emailing, and capture the carrier's acceptance and reference numbers automatically.
Automated tracking — the Tai TMS can pull the current status and milestone dates for a shipment from the carrier and normalize them into the standard Tai statuses.
Electronic invoicing — carriers can send their freight invoices to the Tai TMS electronically, and the system can match and auto-approve those bills when they fall within your tolerances.

Business rules & limits

A rule needs a trigger, and it acts only when its filters match. Automation runs when a shipment matches the rule's trigger and passes any filters you set. A rule with narrow filters will only act on the shipments that meet them, so scoping a rule is how you keep it from firing on the wrong loads.
The run stops at the first step that does not pass or cannot finish. Steps run in order. If a filter does not match, the rule stops there and later steps (including actions) do not run. If an action cannot be completed — for example a Send Webhook with no web address, or a tender that could not be sent — the rule also stops at that step, and the log shows which step it was. A step that fails unexpectedly is recorded as an error.
Rules act as a designated staff account. Each rule runs as a staff account chosen for the rule (or the organization's default automation account), so what the rule can see and do follows that account's access.
Rule authoring and rule monitoring are separate places. You build and edit automation rules in the setup area, and you review what automation actually did (its activity log, coverage, and outgoing messages) in the monitoring area. Both are part of the same feature — one is where you configure it, the other is where you watch it.
Test before you rely on it. Because a live rule acts automatically, the Tai TMS provides a way to test a rule first. Use it to confirm the rule matches the right shipments and takes the right action before enabling it.
Scheduled and on-demand runs look at up to 500 shipments. Each scheduled or on-demand run considers the shipments that match the rule's filters, newest first, up to 500 shipments per run. An on-demand run cannot be started again within 30 minutes of the previous on-demand run.
Delayed rules wait at least one minute. The delay on a Shipment Action Log rule can be set in hours and minutes, but the total must be at least 1 minute.
Rules cannot loop forever. A rule that is already running for a shipment is not started a second time by the changes it makes, a chain of rules that trigger one another is cut off after a few levels, and an Add Assignment step in a rule that starts from an assignment being added is not carried out.
Some newer triggers and steps are switched on gradually. The delayed Shipment Action Log trigger, the Driver Tracking Canceled trigger, 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, so they may not appear in every environment until they are enabled.
Automation and electronic connections are independent. Workflow automation rules work regardless of carrier connection type, and electronic dispatch/tracking/invoicing work whether or not you have automation rules set up. They complement each other but are configured separately.
EDI is slower than API (a real limitation). An API-connected carrier typically responds within seconds. An EDI-connected carrier exchanges documents in queued batches, so a dispatch acceptance or an incoming update over EDI can take from several minutes up to a few hours. Plan follow-up accordingly.
Automation only covers connected carriers for dispatch/tracking/invoicing. If a carrier has no electronic connection, the Tai TMS cannot dispatch to it, pull tracking from it, or receive electronic invoices from it automatically; those loads are handled manually. This is expected, not an error.
Electronic invoices are auto-approved only within tolerance. When a carrier's invoice arrives electronically, the Tai TMS compares it to the expected charges and auto-approves the bill only if the difference is within your configured overpay/underpay tolerance; otherwise it is flagged as a variance for a person to review rather than paid automatically.

Frequently asked questions

What is workflow automation in the Tai TMS?

In the Tai TMS, workflow automation is a set of rules you configure that watch for a condition or event on a shipment, optionally narrow down which shipments they apply to with filters, and then automatically perform one or more actions (such as sending a message or advancing work). It lets your team offload repetitive steps so they happen consistently without someone doing them by hand.

How do I make sure an automation rule only runs for the right shipments?

In the Tai TMS you scope a rule with filters — for example limiting it to certain customers, regions/lanes, or shipments that match specific criteria — and you can also schedule when it runs. Only shipments that match the rule's trigger and pass its filters will be acted on, so filtering is how you keep automation from firing on loads it shouldn't touch. You can test the rule first to confirm it behaves as expected.

Where do I see what my automation actually did?

In the Tai TMS, rule authoring and rule monitoring are in separate areas. You build and edit rules in the setup area, and you review what automation did — which rules fired, what outgoing messages were sent, and how well your automation is covering shipments — in the monitoring area. Checking the monitoring side is how you confirm automation is working and tune it.

Can a Tai TMS workflow rule send shipment information to my own system?

Yes. The Send Webhook action in Tai TMS workflow automation posts the shipment's current details to a web address you provide, using the same shipment-detail content as the public API. You can supply a username and password or an authorization value if the receiving system needs one. If the web address is blank, the action is logged as not completed and the remaining steps in that rule do not run. If an address is present, the Tai TMS makes a single delivery attempt and 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 attempt is kept in Tai's webhook activity records, not in the workflow log.

Can a workflow rule wait before it acts?

Yes. A Tai TMS rule that uses the Shipment Action Log trigger starts when a chosen kind of entry is recorded on a shipment's activity log, waits for a delay you set (hours and minutes, at least 1 minute), and then checks its filters and runs its actions against the shipment as it is at that later time. If the rule is turned off or the shipment is gone by then, nothing happens.

How often can a scheduled workflow rule run, and when does it start?

In the Tai TMS a scheduled rule can run monthly, weekly, or on a recurring interval inside a daily window, in the time zone you choose for the schedule. A recurring schedule repeats no more often than every 15 minutes. The scheduler checks every 15 minutes, so a rule normally starts within about 15 minutes of its scheduled time. Each run considers up to 500 matching shipments, newest first.

Can I run a scheduled workflow rule right now instead of waiting?

Yes. In the Tai TMS a scheduled rule can be started on demand from its schedule list. To protect your system from accidental repeats, an on-demand run is refused if the rule was already started on demand in the last 30 minutes.

What does it mean for a carrier to be "connected" to the Tai TMS?

In the Tai TMS, a connected carrier has an electronic link to the system, either an API connection (real-time) or an EDI connection (standardized document exchange). That connection is what lets the Tai TMS tender loads to the carrier electronically, pull tracking status from the carrier, and receive the carrier's invoices electronically — all without manual phone calls or emails.

What can an electronic carrier connection automate?

In the Tai TMS an electronic carrier connection powers three things: automated dispatch (tendering a load and capturing the carrier's acceptance and reference numbers), automated tracking (pulling the shipment's status and milestone dates from the carrier), and electronic invoicing (receiving the carrier's freight invoice electronically so the bill can be matched and, within tolerance, auto-approved).

What is the difference between an API connection and an EDI connection?

In the Tai TMS, an API connection is a direct real-time link to the carrier, so exchanges happen within seconds. An EDI connection is a standardized electronic-document exchange handled in queued batches, so it is slower — updates can take from several minutes up to a few hours. Both accomplish the same electronic exchange; API is near-instant while EDI is not.

Do I need automation rules to use electronic dispatch or tracking?

No. In the Tai TMS, electronic dispatch, tracking, and invoicing depend on a carrier's electronic connection, not on workflow automation rules, and they work on their own. Workflow automation rules are a separate feature you can layer on top to automate additional steps. You can use either feature without the other.

Will automation act on a carrier that isn't electronically connected?

Workflow automation rules can still run their configured actions (such as sending messages) regardless of a carrier's connection, but the specific automations that require talking to the carrier — electronic dispatch, tracking pulls, and receiving electronic invoices — only work for carriers that have an electronic (API or EDI) connection. Loads on unconnected carriers are dispatched, tracked, and billed manually.