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.

A single rule can have multiple conditions, and you can also organize conditions into groups. Once you’ve added your conditions and defined how they relate to each other, the rule applies whenever those conditions are met.
​

Each rule has two parts. The Source field sets the trigger, meaning the condition that causes the change. The Target field sets the result, meaning what should change when the rule applies.
​

For example, you could use a Task rule to change the priority of tasks that have specific skills and belong to a particular team.
​

AND means that a task must meet all of the conditions for the rule to apply. In this example, the rule only applies to tasks that have both the Junior and German skills and are assigned to Team 1. A task with the Junior and German skills that belongs to Team 2, or to no team at all, won’t be affected.

OR makes the rule much broader, because a task only needs to meet one of the conditions. With OR in the same example, the rule would apply to any task that either has the Junior and German skills or belongs to Team 1.

You can also group conditions and set the relationship within each group separately. This lets you build more complex rules from several layers of conditions. 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 various actions to trigger once specific conditions are met. For example, if a Task with a particular 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 that stores information.

Using these operators, you can set up various things within eLogii.

If you’re not sure how a specific entity is named in eLogii, check the API documentation. You can also find the exact names of Task fields directly in eLogii: go to the Tasks section and click Export. A pop-up window will list all task fields with the exact name used for each one.

There’s no limit to the number of conditions you can add to a rule, and rules can also be triggered via the API.

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 source and target fields from a list of Task fields or enter a custom one. The list automatically includes your dimensions and custom fields, as well as Task states and other options.

You can do many things with this feature, and it’s entirely up to you how you want to use it.

Alongside changing the 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 because there aren't enough Drivers on a team to complete them; those Tasks can be transferred to another team that handles these situations.

If a different form should be applied as a POD action when specific Task conditions are met, you can set this up with Task rules.

In the Condition section, add the conditions that must be met for the form override to apply. Once you’ve set up the condition elements and defined how they relate to each other, go to the Target field section and select Form as the target Task field.

In the Task segment section, choose whether the override applies to the pickup or the delivery part of the Task. If Field service mode is enabled or Single segment optimization mode is in use, select Delivery.

In the Which form action section, select 1st form action if the Task uses only one form. If Tasks have multiple forms, which is only possible when multiple actions of the same type are enabled, you need to specify which form the rule should replace. The form action number matches the order in which the forms are listed on the task. For example, if a Task has three forms and you want to replace the second one, select 2nd form action.
​

You can test your rules before enabling them. Once you’ve set up the conditions, click Test condition to open the testing panel. Copy the generated text from the Condition field into the Test data (JSON object) field to check whether the conditions work and whether eLogii can apply the result. The example below shows both a failed and a successful test.

If you’re comfortable with JSON, you can also write your own test data instead of copying the conditions.

If a test fails, go back and adjust the logic in your conditions. In the example above, the test failed because no drivers in Team 2 have the Junior skill.

Task rules aren’t applied all at once. eLogii runs them one at a time, from top to bottom, so the order of your rules matters.

If several rules apply to the same task, make sure they don’t cancel each other out. For example, say rule A sets the priority to 1 for tasks weighing less than 30, and rule B sets the priority to 5 for tasks with certain skills. If rule B runs first, those tasks get priority 5, but rule A then changes it to 1. To keep priority 5 for those tasks, place rule A above rule B.

In other words, when two rules change the same field, the rule that runs last wins. A rule doesn’t consider values set by earlier rules; it simply overwrites them.

To change the order of your rules, drag a rule by its handle above or below other rules.

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 that 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.