Dashboard Extensions are versatile automations and actions that can be executed internally within eLogii, as well as actions that transmit specific data elements from eLogii to external systems.
Extensions can be found in Configuration ⇒ Extensions.
How to Create an Extension
Extensions can be created by navigating to Configuration ⇒ Extensions and clicking the +Add button to create a new extension.
The following fields can be populated to determine how the extension should behave:
Label - Determines the name of the extension, and it can be anything that the user wants. We recommend using the label field to note what the extension is meant to do (e.g., Move Tasks to Monday and Set Tag).
Enabled - Toggle that determines whether the extension is activated or not. Extensions can be enabled or disabled at any point in time.
Icon - A specific icon from the eLogii library can be set to appear near the extension action button. Our team can provide you with the exact icon code on request.
Condition - An expression that determines the extension display condition, i.e., whether the extension should appear always, or only when specific conditions are met. For example, a condition can state that the extension will appear only for Tasks in a failed state.
Scope - The scope determines how the extension will appear: Global (actions will apply to the entire workspace), for a specific Entity (actions will apply only to one entity of the selected type), or for Multiple Entities (actions will apply to multiple entities of the selected type).
Entity - Once the Scope is selected, one of the following entities can be chosen: Task, Driver, Vehicle, Route, or Customer. If a specific entity is selected, the extension will appear in all cases for that entity. If a specific condition is defined, then the extension will appear only for that entity, but only when the specific confition is met.
Type - Link or Request can be chosen here. The link option enables opening segments in another tab, which is especially good if users wish to open Tasks in their external systems.
Url - This field is only visible if the Link type is selected for the Extension. It defines the destination URL users will be redirected to when the extension is triggered.
For example, if users want to open a specific Task in an external system, this is where they would configure the exact page URL that should open. The Url can contain an expression that contains matching identifiers between systems (for example, the reference field in eLogii matches with the ID field in the external system).
Fields - This field is only visible if the Request type is selected for the Extension. It can contain any entity-related eLogii parameter (see our API documentation for more information on entity element names).
Creating Requests
Extension Requests can be created only on the condition that the field type Request is selected. Users can add as many request actions as they want. To create a new request, click the Add button, and a new request template will appear where parameters can be defined.
The fields that can be populated are the following:
Label - This indicates the request name and appears in the request execution result message (for example, "Task copy" (if that was set as the request label) was successful). We would recommend that you use this field to define what the request is meant to do.
Url - Defines where the request will be sent.
Method - Defines the request method. Users can choose GET, POST, PUT, or DELETE, depending on what the request is meant to do.
Headers - If the selected action requires interaction with an external system, the corresponding API key needs to be stored in this field. The API key is used to authorize secure access to the external system when a specific action in eLogii needs to trigger a desired outcome in the connected system.
Payload - Expression that states what needs to happen. For example, if the state of a Task needs to change when a specific action happens.
Response - This will override what the display message will show when the request is made. This is useful when users want to know what happened once the extension was triggered. For example, a message can state which Task was updated by listing its UID or reference (as seen in the example below).
Timeout - Defines the maximum amount of time the server should wait for a request to be processed before returning a response. If left empty, the default timeout of 60,000 ms (1 minute) will be applied.
Labels
Labels allow users to rename default action buttons. The selected label determines how the button appears when triggering an Extension action. Users can select a default button name from the provided list and rename it to whatever they want.
For example, the label for the global actions button can be called Sync data, the button for multiple Task actions can be called Sync all orders, etc.
After defining the button name, click Save to apply changes.
How to Activate Extensions Once Set Up
This depends on their scope, or rather, whether the extensions are Global or tied Entities. Extensions must be enabled; otherwise, they will not appear. The extension action button will always be highlighted as yellow in the menu, regardless of the assigned button label name. The same set of defined extension actions will appear, regardless of where you access them from.
When display conditions are defined for an Extension, the system evaluates them before rendering the action. If the conditions are not met, the extension action will not be available.
Global Extensions
Global extensions will appear in the top-right corner of the screen when selecting the dropdown next to the Sync data button in the screenshot below (depending on how the Label name has been defined on your account, that button may have a different name).
Single-Entity Extensions
The action button for these will appear when right-clicking the respective entity either in its designated section or on the Planning Screen (both daily and weekly planning). For example, to activate a single-Task extension action, right-click on the desired Task either from the planning screen or the Task section.
Multiple-Entity Extensions
These actions will only appear in the Actions menu when multiple entities of the same type are selected. For example, if users need to perform extension actions for specific (or all) Tasks, they need to select all the Tasks they need (either from the Planning Screen or the Task section) and click the Actions button, where they can find the extension actions.
Extension Actions
There are several things users can do when they have multiple extensions created.
Move up - Moves the item up the list.
Move down - Moves the item down the list
Copy - Copies the item and its contents. This is perfect for cases where users need multiple variations of the same extension.
Remove - Deletes the extension.
Extensions are also marked with labels for easier navigation. If the action is global, it will have the global tag next to it, but if it's an entity or a multiple-entity action, there will also be a tag relating to the entity that was selected for the extension.
Use Cases and Examples
As mentioned, Extensions have a wide range of use cases and are highly customizable. The following examples cover some of the most common uses. If you need additional support on writing expressions for payloads or conditions, reach out to the eLogii technical team, and we will provide the necessary support.
Opening Links/Pages
This is an example of a Global action that redirects users to another page when they select the corresponding option from the Global Extensions menu. The example here will redirect users to the Task page in eLogii, but the URL can even be of an external page that you would like your users to access directly from eLogii.
Opening Tasks as a Specific eLogii Role
Specific Extension actions can be restricted based on user roles. This means that users can set up extensions that allow only users who hold a specific role in eLogii (for example, Operator) to perform a specific action.
In this example, we have the same action, the above one is restriced to Operators (which only operators can see, and nobody else, not even Admin users), and the other one is restricted to Admin users. This is where we can see how conditions dictate the action displayed.
Complete Task and Trigger Notification
This example does several things - it limits the action to only Admin users, it sends a request to the server (indicated by the Request field type and the following action) each time Tasks are marked as completed (defined in the payload), and a notification pops up which states that the Task with the specified UID has been successfully updated (defined within the Response field).
For this specific case, the Header contains the eLogii API key, as this is an eLogii action. For any other actions that need to be connected to an external system, you would use that system's API key.
Please note that in eLogii, Task states are represented by numeric values (for example, 60 indicates the Completed state).
If you would like to implement a similar action for a different Task state, please refer to the API documentation, where all available Task states and their corresponding numeric values are listed.
Send Routes to External System
This example shows how to configure sending routes to an external system of your choice. For this particular example, it is important that the scope is set as Multiple and that the Entity is set as Route.
Additionally, the Request has been set up so that it uses the POST method and the URL stores an n8n webhook URL that sends the defined data points from eLogii to the desired system. This means that the parameters need to be defined through n8n first before configuring the Extension. The timeout is optional, but in this example, it was set to 180000ms.
Move Tasks to Another Day and Set Tag
This example allows users to move Tasks to any future specified day of the week and set a tag once the action is complete. This extension is also only visible to Admin users (as defined in the Condition field).
This example also has two accompanying request actions - one moves the Tasks to the specified day, and the other one sets a tag.
The payload field contains the exact instructions for eLogii on what needs to be done with each request.
If you would like to make a variation of this payload or test how the configuration works, you can copy it:
Moving the Tasks to next Monday:
{"taskIds":${JSON.stringify(items.map(e=>e._id))},"newDate":${parseInt(dayjs().add(1,"week").day(1).format("YYYYMMDD"))}}
Adding a tag:
{"items": <%=JSON.stringify(items.map((task)=>({_id: task._id, $addToSet: { tags: "moved" }}))) %> }
Both request actions will trigger a custom notification, as defined in the Response message.
If you have a specific action in mind you would like to set up through extensions, and are not sure how to write the right expression, reach out to the eLogii team either by messaging your Success Manager or emailing support@elogi.com.