Actions

In the previous step, we looked at conditions in order to express the criteria that must be met to perform the actions associated with the condition. We learnt how to configure rules and how to use multiple rules. In this step, we are going to look at Actions.

Actions are the steps that are executed once the rules of the conditions are evaluated.

Actions are executed in order. Using actions, you can update values, show /hide fields as well as make recommendations. In this topic, we explore the different actions.

Client-Side Only Actions

This group of actions only apply to model-driven forms. You can configure them for scope entity but they have no server-side effect. This group includes Lock/Unlock, Set Visibility and Recommendation.

The Set Visibility action allows you to hide/unhide a field on a form. Generally, it is recommended if you are going to hide and show fields through automation that you start with the field hidden. Otherwise, it is likely that the user might briefly see the field before it is hidden by the rule execution when the form loads. Set Visibility only works on fields, if you need to hide or show other controls developers have additional capabilities including hiding all the contents of tabs and sections.

The Lock/Unlock action can be used to enable or disable interaction with a field. Often enabling or disabling a field is used as an alternative to show/hide so the user isn’t confused trying to find a field. In some scenarios, this is used to discourage changing a value based on another field value. It’s important to remember that hiding or disabling fields does not secure them from modification by the other means including canvas apps.

The Recommendation action allows prompting the user with a suggestion and then if accepted applying one more action that implement the recommendation. We will be covering this separately in the next topic.

Other Actions

This group of actions can run both on the client and the server depending on how the rule scope is configured. It’s important to remember on these actions that they might impact developers and other integrations server-side that might not have the ability to meet the same data input requirements an interactive user can.

The Set Value action is used to set the value of a field to either a static value or to the value of another field. You also have the ability to do basic calculations using formulas that we cover in more detail in a separate topic. The Set Value action runs for both new and existing records based on the condition rules.

The Set Value action can also be used to remove a value from a field. Care should be taken when using this as you will be permanently discarding existing data in the field. To remove a value from a field set the Type of the Set Value action to Clear as you can see in the following example.

The Set Default action is used to set an initial value of a field. This action only applies to new records being created. Set Default action should be used instead of Set Value when the action should only occur on new records.

The Set Business Required action is used to modify the required state of a field. It can be set to Business Required or Not Required. You do not have the ability to set a field to Business Recommended, for this you could default the field to that value or a developer would need to use client script. For fields that are always required or not required it is better to set this on the field definition and not using a rule. Rules should be used when the criteria for required/not required is more dynamic.

The Show Error Message action is used to block a user from saving the current record and visually inform them with a text message why the save is blocked. This is a very powerful action because it not only blocks the save from the web client if configured for entity scope it also blocks any app or API calls to modify the record.