Eleos - How to Create and Use Workflows : ASR Solutions

Overview

Eleos workflow is created so that drivers can progress through their loads using workflow actions within the application. This document will provide information and instructions on how to configure workflows in Drive Axle, and a high-level overview of how workflow statuses are set within the database.

Workflow Editor in Drive Axle

In the Eleos App Manager in Drive Axle, you can configure the actions that appear in the driver’s application at each load and stop status. The Workflow editor can be found by logging into Drive Axle, ensuring the appropriate environment is selected from the drop-down menu at the top of the page. Toggle to the Eleos App Manager, then select App Configuration and Workflows:

To create a new workflow, select “Add a Workflow”. To make changes to an existing workflow, select the name of the workflow you would like to edit.

Each workflow has a title and code. The WORKFLOW-CODE can be referenced in scripting to further configure how workflows are used by drivers.

In the Workflows editor, when viewing a workflow there are arrows that show the sequence of workflow statuses as well as floating statuses that appear like they are not connected to workflow. It is important to understand that the arrows are used when the driver’s device is offline and indicate the next workflow status that is presented to the driver after they complete the actions on their current workflow status. If the driver is attempting to continue Workflow during an offline period, any messages they send will be saved to their device and sent when the driver is back online. When workflow is completed online, however, it is possible for the driver to reach the floating workflow statuses through workflow scripting. More information about this can be found in the Workflows section of Drive Axle - Drive Axle Walkthrough.

Below is a screenshot example of the CURRENT workflow in ASR’s Sandbox environment. The load statuses are in blue under the Load section, and stop statuses are in an off-white color under the Stops section.

Create New Load or Stop Status

Create a new load status by clicking the “+ Load Status” button in the top left. Similarly, a stop status can be created by clicking the “+ Stop Status” button. Each status has a title and a code. The title is how the status is labeled within the Platfrom Workflow Editor, and the code in parentheses is what is used to refer to that status within scripting.

Adding an Action to Workflow

Before adding actions to the workflow, ensure that the workflow action is created in Drive Axle, has the Action Type as New Message, and the Workflow Action checkbox checked. Workflow actions are typically tied to forms, and once submitted it comes through as a message with its own message handle. For info on how to create actions in Drive Axle, please see our Drive Axle - Drive Axle Walkthrough which has instructions on how to create Forms and Actions, including how to link a form to an action, so that the driver can fill out the Form after pressing the Action button. If you are looking to edit a workflow rather than create a new one, Drive Axle - Adding a Load Level Button to Workflow has instructions on how to determine which workflow to add the button to by determining which workflow is being used by drivers.

Multiple actions can be added to a Load or Stop status. Drive Axle - Adding a Load Level Button to Workflow has instructions on how to add an action to workflow at the load level, but the instructions to add an action to the stop level of workflow are very similar. First determine the stop status that the button needs to be added to. Then click on the stop status and select the action that was already created from the drop-down next to “+ Action”. Below is an example of adding the Google Street View action to the Pickup stop status. In the drop-down to add an action, the action code “STREET-VIEW” is shown in parenthesis next to the action name.

Once the action is added to the stop status, you can use the dots next to the action and drag it up or down to re-order it if needed. Be sure to click “Save” to save the changes so that they are reflected in the application.

How to Configure Offline Workflow

If you want a load/stop to move to a different status after a specific action is performed during offline workflow, then on the load or stop status with the action, you can specify that after the action is performed offline, the status should move to the new status. For example, on the Planned load status, shown below, there is an action to Acknowledge Trip. If you want the load status to move to “Dispatched” after the action is completed on the Planned Load, then you can specify on the planned load status, “once that action is performed offline… Change load status to DISPATCHED”, as shown below. Then after the action is completed, its status will be “Dispatched”. In this example, the DISPATCHED status would already have to be created before making this change.

The same can be done for stop status as well. By changing the load status after an action is performed offline, it will add the arrow between those statuses on the workflow editor page.

Workflow Statuses in the Database

Workflow Statuses are also defined within the code, in addition to Drive Axle. Load statuses are defined within the ELEOS.udf_TripStatus function. When ELEOS.udf_TripStatus is executed, it returns a status for the load, which should match to a status code defined within the Workflow editor in Drive Axle and show the actions defined on that status. The application will then display whatever actions are defined under that status. For more information, please see our article, Drive Axle - Adding a Load Level Button to Workflow, which has a section on Statuses in Workflow.

Every client's Trip Status (workflow code) and Stop Status scripting will be different based on their customized workflow and driver experience. Users who would like to customize their scripting should first review either the existing implementation or the documentation within the Custom Templates. If there is uncertainty in those how to make your desired updates, we strongly encourage you to reach out to our ASR Support where a team member could further explain or assist with your specific implementation. Please note that making any changes to any part of the aforementioned scripting could break workflow for all drivers without proper understanding and testing.

How to Make Changes to Trip Status and Workflow Codes

It is possible to have multiple workflows within Drive Axle, so it is common for some loads to use a specific workflow while other loads will use a different workflow even if they have the same driver. Since many clients use multiple workflows, there are cases where drivers may have a different workflow depending on their load status, for example some clients may have it set up to where one workflow code is used for Active loads and a different workflow code is used for loads that are not Active (such as Completed, Planned, etc. Our guide Drive Axle - Adding a Load Level Button to Workflow has more information on how multiple workflows can be used. A workflow code can also be assigned to a certain driver if needed, for example, if a test driver needs to use a specific workflow that was created for testing.

The steps to make changes to Trip Statuses and workflow are different for each client based on the client’s own custom scripting. How to make changes to trip statuses and workflow codes depends on the specific setup for a company, including the version of code that the integration is running on. This is because the location and steps to make these changes are different after SQL contracts are implemented with the deployment of Winter ‘24 enhancements, and it could also be different based on the TMS that is being used. The following sections will provide some guidance on where to make these changes, depending on whether SQL contracts are implemented or not, as well as the TMS being used.

Before SQL Contracts were Implemented

TMW

Depending on the version of the integration being used and how new the client is, some clients may have the procedural version while others may have the function-based version.

Eleos.udf_TripStatus (Function) - This function executes on a per load basis, calculating the Trip Status and workflow codes returned to Eleos based on conditional factors within the scripting itself. To use as a reference, below is a screenshot example of the default scripting where the trip status is determined within Eleos.udf_TripStatus.
Eleos.usp_GetLoads_TripStatus (Procedure) - This procedure executes as set based operations. Instead of taking individual load information, this takes a table of loads (Trips) and calculates the workflow code on each, at the same time, as a set of operations. To use as a reference, below is a screenshot example of the default scripting where the trip status is determined within Eleos.usp_GetLoads_TripStatus.

TL2000

The Eleos.usp_GetLoads_Data procedure executes as a set based operation, determining the workflow code of each load (Trip) based on the load's sequence within AS400. To use as a reference, below is a screenshot example of the default scripting to show where stop status is computed within the procedure.

LoadMaster

The Eleos.udf_TripStatus function executes on a per load basis, calculating the Trip Status and workflow codes returned to Eleos based on conditional factors within the scripting itself. To use as a reference, below is a screenshot example of the default scripting to show where stop status is computed within the function.

With SQL Contracts Implemented

TMW and LoadMaster

With SQL Contracts in place, client customizations and additional changes are now made within a custom template, ELEOS.usp_GetLoads_TripsStatus_Custom_Template, which is executed from within ELEOS.usp_GetLoads_TripsStatus. This procedure executes as set based operations. Instead of taking individual load information, this takes a table of loads (Trips) and calculates the workflow code on each, at the same time, as a set of operations. After the default scripting executes, a client will have access to all of the Trip related information within a documented temp table. Performing scripting updates within this custom template, directly modifying the data table will result in those updates altering the returned response to Eleos based on your specific implementation. Below is a screenshot of the ELEOS.usp_GetLoads_TripsStatus_Custom_Template for reference:

TL2000

There is no difference following SQL Contracts integration deployment.

How to Make Changes to Stop Statuses

How to make changes to stop statuses in the code depends on the specific setup for a company, including the version of code that the integration is running on. This is because the location and steps to make these changes are different after SQL contracts are implemented with the deployment of Winter ‘24 enhancements, and it could also be different based on the TMS that is being used.