Possible reasons and solutions:
1. In the trigger code, there is no request to the "changeSet" object to launch an event-driven trigger after a necessary order or customer card change
Diagnostics:
We analyse the filter and trigger condition for the presence of a code for order history access, which is performed using the changeSet [Set of changes] object. It may look different, but the code will always contain the word changeSet, for example:
changeSet.hasChangedField("status") and changeSet.newValue("status").code == "did-not-get-through"Or like this:
changeSet | contains ( c =>c.fieldName == 'order_product.status' and c.newValue.code == 'otklonen' and c.oldValue.code == 'new')In the absence of this code, it becomes obvious that the trigger did not have a specific condition after the required change and was executed every time the order or customer card was changed, while observing the conditions specified in the trigger code.
It is important to understand the difference between checks:
changeSet.hasChangedField("delivery_type") and changeSet.newValue("delivery_type").code == "royal-mail"from
order.deliveryType.сode == "royal-mail"In the first case, the trigger will be executed only when the delivery type is changed to "Royal Mail". In the second case, the trigger will be executed when the delivery type is changed to "Royal Mail" and with each subsequent change of the order until a delivery type other than "Royal Mail" is selected.
Decision:
Generate and add a code for accessing the set of changes (changeSet) with checks for changes in the required field.
2. The condition on which the trigger is executed is fulfilled when changing the order or customer card several times
If, for some reason, in your business process, moments of repeated changes in the order are permissible for those changes that are executed by the trigger, then it is possible to deliberately limit the trigger executions by using additional functions.
Diagnostics:
Analyse the trigger code, knowing about the change of which field it is executed. This can be done by parsing the expression for accessing the set of changes, for example: changeSet.hasChangedField("status") and changeSet.newValue("status").code == "did-not-get-through" - this code is executed on the change of the field with the "status" code, which indicates a change in the order status. This information can be found in the reference book of objects by searching for the found field code.
Let's go to the order card, on which the trigger was executed twice, and analyse the history of changes to the order for the presence of several order status changes to the status specified in the trigger condition.
Solution:
Add the last_run() function to the trigger condition, which checks the last launch of the trigger against the parameters passed to the function. As the first parameter of the function can be passed, the time interval for which the check must be carried out in the format: "1 day", "3 month", "5 years", etc. The second parameter of the function can be used to transfer the symbolic code of the trigger, which must be checked, in the format: "some-code". As the third parameter of the function can be passed one of two available entities: "order" - order and "customer" - customer.
The generated function that needs to be added to the trigger will look like this: not last_run("5 days"), respectively, the final trigger code with restriction of the repeated execution, if the order status to which the trigger reacts within 5 days from the moment of the first change in the order status - did not change again, it will like this:
changeSet.hasChangedField("status") and changeSet.newValue("status").code == "did-not-get-through" and not last_run("5 days")