Business rules are a helpful tool when you want to help users navigate your apps. I’m going to go through a series of different tools that can be used as part of navigating, automating and generally helping your users interact with your model-driven apps as much as possible.

What are business rules?

Business rules can be seen as a way of controlling your data input and navigation in your apps. They work in a distinct way that separates them from either workflows/processes or power automate workflows. The most important part is that they run while the user is interacting with the application in real time where a process or a cloud flow will require the user to save changes in data first.

This allows business rules to help the user fix any issues in their data input or notify them of any additional required fields, even before they try to save the record.

Typical uses for Business Rules

The most basic functions of business rules are:

1. Showing/hiding fields
2. Verifying input
3. Setting default values, or updating fields, based on user input
4. Locking/unlocking fields
5. Setting fields as required/not required based on user input
6. Setting recommendations for fields

Lets start from the top.

When creating Business Rules, its going to look very similar for anyone that has worked with any type of “If – Then” statements. Business rules are in essence a very simple, or a collection of very long “If – Then” statements. They can be continued and combined in a myriad of ways. Each condition can also consist of a combination of different statements, with the limitation that all conditions must be a combined by “And” or “Or”. So for example, if the single condition looks at whether the value of two decimal fields are above 0. They can be chained by the “And” statement, meaning that they both need to be above 0 at the same time for the condition to be true, or they can be chained by the “Or” statement, meaning that only one of the conditions needs to be true in order for the condition to run.

Now, lets add our first business rule. From the maker portal, we go to the table where we want to add our business rule, select “Business Rules” and then select “+ New Business Rule”

Showing/Hiding fields.

Lets say I am going on a trip, so I populated my Trip table with some different fields that I can fill in.

For example, I have a Yes/No field designated for whether I’m travelling alone or with companions. If I set the field to “No”. It might be relevant to fill out some more fields, like adding a co-captain to my overview, so I have someone to share the responsibility.

So under Properties. I select the field “Solo Trip”, which is a yes/no field, and select that the condition is activated if the field is set to “No”

I then select “+New” and “Add set visibility”

Now I can see two additional boxes appear, one is directly to the right of the condition, and one is below the condition. This means that my “Visibility” Action is being placed depending on whether the condition is true or false. True is to the right of the condition, and false is below the condition. Marked by the check mark and the X.

I want my condition to run when the condition is true, so when I select “No” to the trip being a solo trip. When this condition is met. I therefore add the visibility action to the right of my condition and then under “Properties” for the condition I select that it is the “Co-captain” field I want to make visible by setting this condition to “Yes”

To make sure the field is hidden when the condition is not met. I can select the Visibility action, then select “Copy” in the Ribbon.

Then I select “Paste” and choose the box below the condition to paste my visibility action there. I then make sure to change the visibility to “No” in the Properties and then select “Apply” to make sure the property change is saved.

I should also change the name of the Business rule, this is done by expanding the general properties of the Business Rule by clicking on the chevron icon next to the name, then changing the name, and selecting “Save” in the ribbon.

Next I will also make sure to include a correct name for the condition and actions in the Business Rule. Now I’ve ended up with a rule looking something like this:

Lastly we need to select “Activate”, and confirm the activation. After this the Business rule will run on all forms that have both fields available.

Verifying input

Business rules are also good at verifying whether data is correct, or within bounds that you expect. The conditions can be used to check things such as number fields that should either not exceed or go below a certain number. Verifying if two fields are similar or unique from each other, or if a text field contains data, begins or ends with a certain phrase, etc.

The options are quite extensive and I recommend you play around with them.

Setting default values, or updating fields, based on user input

It is also possible to set certain default values for fields, or change the values of one field, based on input from the user in another field. This type of logic could also be chained to involve multiple fields.

Locking/unlocking fields

It can be beneficial to limit a user’s ability to change the data in certain fields at specific points in time of a record’s lifetime. This can be handled by locking and unlocking fields through business rules. One example could be my first case of adding the co-captain to a trip. If I have filled out a co-captain, I could lock the “Solo Trip” field so that I can no longer remove this as an option, seeing as I have already filled out data in the field.

Setting fields as required/not required based on user input

In addition to the previous example, when setting the “Solo Trip” field to “No” I could also set the co-captain field as a required field, to ensure I add data to this field while I am working on the record.

Setting recommendations for fields

I could also give my users helpful recommendations or steer them in specific directions when filling out a field, based on user input in other fields.

One example could be that I had a combination of fields. One field being the Yes/No Solo Trip field, another being a field for selecting which country/area I am travelling to, and the last field being the co-captain field.

I could then make recommendations for the co-captain based on the area I want to travel to, if I already know that each possible co-captain has their own area that they are better at navigating.

Limitations and known issues when working with Business Rules

The limit for conditions and number of actions is quite large. Each Business rule has a maximum of ten conditions.

Business rules need the field used in the rule to be available on the form/view that the user is seeing.

Business rules run sequentially, so if a form contains multiple business rules, and they even interact with some of the same fields, they run in a sequence, waiting for the other rule to finish before starting. The sequence is determined by when the rule was last activated. Where older rules run first.

Questions I ask when deciding if I should use a business rule or a flow/process

1. Is it necessary for the application to interact with the user, while the user is still making edits on the record, before they save? Or, said in another way, would it hinder the user, or guide the user?
2. Is my requirement for the process/business rule critical to run before the user saves the data. Can the user return later and see the result of what I am trying to achieve.
3. Am I trying to automate something, and if so, do I need to do it right away or does waiting not actually hinder the user experience.