Task rules allow users to set up parameters and rules that will prompt the system to make desired changes to Tasks once they are in the system, provided that they contain elements that adhere to the preset rules.

There are two types of rules:

Task rules are used to define sets of Task-related rules that dictate how the system will behave in case specified Task fields are populated with defined values. This feature can be found in Configuration ⇒ Task rules

Users can choose when they want the rule to trigger - once the Task that meets the criteria is created (the rule can trigger only once for that Task), once it's been updated (the rule can trigger multiple times, depending on the conditions set), or in both cases.

It is possible to set multiple conditions for a singular rule, as well as groups of conditions.

This means that you can add multiple conditions, and define their relationships, then once the conditions are met, they influence the outcome of the rule. The triggers are set in the source field, while the result is specified in the target field. The Source field refers to the trigger of a specific change you want to occur, and Target is where you would like to apply that change.

A simple example of using Task rules would be changing the priority of selected Tasks if the Tasks have specific skills associated with them and belong to a particular team.
​

The AND defines the relationship of the conditions, meaning that the Task needs to have both of these specific triggers for the rule to apply. This means that only Tasks with skills Junior and German, that are assigned to Team 1 are the ones the rules apply to. In case there's a Task that has Junior and German as associated skills, but belongs to no team, or belongs to Team 2, the rule would not be applied to it.

If we were to set OR as the relationship definer for the same example, then the scope of application would be much wider, as the rule would be applied in case the Task has German and Junior as associated skills, or if it belongs to Team 1. which means that only one of the conditions needs to be met for the rule to apply.

You can also add another layer to the condition relationships by grouping certain conditions within groups and then defining the relationships of those conditions within the group. Here is an example of that;

You can use any of the allowed logical operators to define how eLogii constructs the rule. For example, if you would like to include all values that contain specific information, you would use =, and if you want to include all, except for a specific value, you would use !=. The following operators are used to establish the relationships and actions between various task elements:

It's also possible to add multiple target fields within a single rule. This means that you can add multiple actions to trigger once specific conditions are met. For example, if a Task with a specific reference is imported to the system, you can set a specific tag to apply, assign the Task to a Team, and set the priority of the Task all within a single rule.

There are many target fields to choose from, and they depend on the target Task field stores information.

Using these operators you can set up various things within eLogii. For example, you can set specific Tasks to appear in a different color on the map by using the = operator. If you predefine a skill for these Tasks, you can use that condition as a rule which will tell eLogii that the color rules apply only to Tasks that contain that specific skill.

In practice, the setup for this example would look something like this:

The result should be something like this. As seen in the example, the Tasks with the corresponding tag are marked with the color that corresponds to the defined Hex Code:

You can choose from a preselection of source/target Task fields (or a custom entry), dynamically including dimensions and custom fields, as well as Task states and others.

There are many options that you can do with this feature and it’s entirely up to you how you want to utilize it. Alongside changing Task priority and changing the Task Display color on the map, you can also choose whether to send certain notifications (for example, if you want to exclude some notifications in specific cases for some customers). Additionally, if you use Teams in your operations, you can set a rule for when Tasks are unviable due to not enough Drivers on one team who can complete the Tasks, those Tasks can be transferred over to another team which deals with handing these kinds of situations.

Feel free to make use of the API documentation for reference in case you’re not sure how a specific entity is listed within eLogii. Another way to access exact Task element names is by switching to the Task section in eLogii and selecting Export. A pop-up window will appear listing everything Task-related and the exact name used for each entity.

There is no limit to the number of conditions you wish to set for a rule, and you can also trigger the rules via API.

Before enabling the rules, eLogii allows you to test them. After setting the conditions, click the Test condition button, which will prompt a testing panel to appear. Copy the generated text from the Condition field onto the Test data (JSON object) field to check if the conditions are applicable and if the end result could be executed by eLogii. The example below shows what happens when a test fails and when it passes. Alternatively, if you're more technical, you can write your own tests without the need to copy/paste the conditions.
​

In case the test fails you can backtrack and correct the login set in the conditions. In this example above, the test failed because there are no Drivers assigned to Team 2, who have skill Junior associated with them.

Task rules are not executed simultaneously, but rather one by one. eLogii will process and apply the rules from top to bottom, so you will need to be mindful of the rule order.

In case you have a set of rules that apply to the same Task, we need to make sure that they don't negate each other because of their order. For example, if we have a rule A that sets the priority to 1 if the weight of the task is <30, and we have rule B which sets the priority of some Tasks to 5, depending on the associated skills. If rule B goes before rule A, the priority of these Tasks will be set to 5, but then set to 1 once rule A is applied after rule B. Because of this, rule A needs to go first, and then rule B can run without being overridden. In short, Task rules aren’t overridden based on source fields, rather they are overridden based on the field value. This is because the Task rules functionality does not aggregate the initial field value set by another Task rule.

You can change the order of the created rules by picking them up by the handle and dragging them above or under other rules, depending on the order in which the rule needs to be executed.

Creating exclusions within the follow-up rules can help combat overriding newly set data. For example, if you don't want the rule to apply to some cases, you can add parameters such as AND [property of choice] != (not equal to) [value you want to exclude] in all following rules.

It is also important to note that any changes made to the rules will not be applied retroactively. If you edit an existing rule and apply changes, those changes will not apply to Tasks that are already in the system, instead, they will only apply to Tasks added after the changes have been made, or to Tasks that have been updated after the changes were applied.

Postcode rules allow users to define which postcodes should be attributed based on a specific Driver, Team, Depot, or Skill. After specifying and saving these rules, all the Tasks uploaded after that will be matched with the specified Drivers, Teams, and/or Depots based on their Postcode. You can find them in Configuration ⇒ Task Postcode rules.

It's also possible to enable the Partial match toggle, which allows users to make postcode matches that do not include all elements in the original postcode.

The match can be either the start of the postcode, the middle, or something else. Partial matching helps save time with inputting postcode variations which would otherwise apply to the same rule. Depending on how you choose partial matching to behave, the rule will act accordingly and match the criteria.

To better illustrate, if we have a postcode SW3 1ES and if partial matching is not switched on, the rule with postcode SW3 will not match this Task, as it’s not identical. But with Partial matching set to match the start of the postcode, SW3 will be included in the rule, because SW3 1ES contains SW3.
​

If you have some specific preferences regarding how you want Postcode rules to behave, you can resort to regular expressions. You can write the desired expression in the Match Postcode field and set which fields the rule will affect before saving. If you're not sure how to write a regular expression, feel free to contact our support team, and they will assist you.