How it works...

We start by giving a name to our automated actions and setting the Model it works with. For the type of action, we choose On Update, but the On Creation, On Creation & Update, On Deletion, and Based On Form Modification options are also possible.

Next, we should define the filters to determine when our action should be triggered. The On Update actions allow us to define two filters: one to check before and the other after the changes are made to the record. This can be used to express transitions: detect when a record changes from state A to state B. In our example, we want to trigger the action when a not-done task changes to the Done stage. The On Update action is the only one that allows for these two filters; the other action types only allow for one filter.

It is important to note that our example condition will only work correctly for English language users. This is so because the Stage Name is a translatable field that can have different values for different languages. So, filters on the translatable fields should be avoided or used with care.

Finally, we create and add one (or more) server actions with whatever we want to be done when the automated action is triggered. In this case, we chose to demonstrate how to implement custom validation, making use of a Python code server action that uses the Warning exception to block the user changes.