How it works...

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

Next, we 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—to 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 because the Stage Name is a translatable field that can have different values for different languages. So, the 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 used the Warning exception to block the user's changes.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset