In this guide, you will understand how Tai integrates with Chain. Whether you are using Chain's Booking, Autopilot, or Tracking features, the integration is the same. The integration is a two-way sync between Tai and Chain. This means that any updates made in Tai will reflect in Chain and vice versa. Once the integration is in place, your Chain Implementation Specialist will work with you to enable the features you signed up for.

If you're looking for how to integrate Tai with Chain, please refer to the Chain Integration Guide.

​
​

Let's look at some more details on how Tai integrates with Chain.

​

Chain has a "standard" mapping of the fields of a load in Tai to fields in Chain. This means that in most cases, the integration is already built and ready to go.

However, not all companies are the same as they have different set of customers and freight types with differing requirements. So the standard mapping is customizable for every customer, and during the implementation process led by your Chain Implementation Specialist, they will work with you to identify any special requirements or scenarios to make sure the correct fields are mapped.

See Carrier Details below for an example

If your team is separated into different offices, groups, pods or agencies, Chain can also map these fields to the correct groups in Chain, so that these separate "sub-organizations" will have their own workspace inside of Chain. We will work with you during implementation to identify these sub-organizations and map them correctly to workspaces inside of Chain.

For example, if you have an agency in Dallas but have several Pods working out of your New York office, Chain can map these to the correct groups in Chain so that these separate "sub-organizations" will have their own workspace inside of Chain.

In the example above, let's say the Dallas agency is completely isolated from the rest of the organization, and there is no user overlap. In this case, the Dallas agency can have its own workspace in Chain, and the users in the Dallas agency can only see their own loads and not the loads from the rest of the organization.

The individual Pods in New York can also have their own workspace in Chain, and the users in the Pods can only see their own loads, not the loads from the rest of the organization or the Dallas agency.

But let's say a user in one of the New York Pods, i.e., Pod A, needs to see the loads from a different pod, Pod B. You can either add that user to both workspaces (one for Pod A and the other for Pod B) inside of Chain, or if the user is added on loads that are from both Pods, then Chain will automatically add that user to both workspaces.

​
​

Loads that are "available" for carriers to book or view on the Carrier Hub in Chain can be identified by their specific status in Tai. Since the integration between Tai and Chain is very robust, your Implementation Specialist will work with you to identify the correct status that will trigger the load to be available for booking in Chain.

This can be done for loads in "Committed" status or "Quoted", or any other logic pertaining to specific fields on each load. Your Chain Implementation Specialist will work with you during the implementation process to nail this down.

Loads will automatically be marked covered in Chain when they are assigned a carrier in Tai. And if a carrier falls off and moves back to Committed status (or whatever logic we decide during the implementation), the load will be marked as "available" in Chain again.

​
​

When the driver updates stop statuses with date and time from the Chain driver app or the dispatcher updates them from the Chain web app, all updates will reflect to Tai. Current statuses supported by Tai are "actual pickup arrival", "actual pickup departure", and "eta to delivery".

Only the status updates for 'Arrived Pick', 'Departed Pick', 'Arrived Drop', and 'Departed Drop' will appear on the Revenova dashboard. Note, though most customers keep these on, these are completely configurable and can be turned off or on if needed.

Here is an example of where the Actual Arrival Date, Actual Arrival (Time), Actual Departure Date, and Actual Departure (Time) gets updated automatically.

​

The driver and dispatcher fields are typically mapped from under the "Shipment References" section in Tai. If you don't have the fields below, or they are named differently, your Chain Implementation Specialist will make sure these are properly mapped. Important information typically includes:

If you don't have Dispatcher reference fields, we recommend creating them as shown below. This enables more powerful integrations with Chain around key features of automated check calls, booking opportunities, and POD collection, to name a few.

​
​

When there are exceptions that trigger based on any Chain Autopilot rules you have set up, this can also be fed into the "Alerts" section in Tai as a "Load Track Exception".

​

With the Chain integration, Chain will populate the locations on the tracking map inside of Chain, which is accessed by clicking the "Location History" on a load in Tai.