Business Rules: Everything you need to know
In a previous article we appreciated the benefits you can gain by introducing Dataverse as a Datasource for your application.
If you missed that article I recommend you take a look at it here.
Prominent among the many advantages is the ability to extend the platform.
This means that you can introduce custom logic to the data model or specific validation rules.
Several solutions can be used to do this.
You can develop a plugin or workflow by writing custom code in C#.
Or you can use the WEB API to work with client-side tables and data.
However, having knowledge of conding is not a strict requirement.
You can extend your solutions even without the need for specific development knowledge.
To do this, you only need to work with the Business Rules.
In this article we will fully attack Business Rules, understand how to use them to validate data, perform calculations, and manipulate fields on dataverse forms.
Olte the benefits I will bring you a list of limitations I have encountered and some tips for more informed development.
Before we begin, let’s try to define a scope for Business Rules.
There may be many occasions when you need to apply rules, even those of negligible impact, to the forms in your dataverse table.
For example, you want to hide a field in case some certain conditions are not met.
As I told you initially, you could use Web APIs to interact with the data, but this would require minimal development confidence.
Business Rules were created to address this need, namely to allow you to manipulate forms and fields without the need for development skills.
The client-side logic is straightforward because the rules are executed when the user opens or updates a form, unlike the server-side logic that applies when the user, or any process, saves a record.
Before getting into the specifics, it is necessary to introduce an additional building block, the Scope.
The Scope defines the execution context of your Business Rules.
Specifically, by taking advantage of the option called Scope in the upper right-hand corner, you can define under what circumstance a Business Rule is applied.
You have at your disposal three options:
- An individual named form
- All forms
- An Entity
You can then select a constituent for a single form or for all of them.
This is because a table, or Dataverse entity, can have more than a single form with different access permissions.
By choosing a specific form you can make a particular rule apply only to that particular form.
But does it apply to all forms ?
NO, you cannot apply the same principle if you are working with Quick Forms.
In that case you will have to define one of the other two scopes.
For example, if you choose Entity as Scope for your Business Rules this will be valid for both Main Forms and Quick Forms and will be applied when on Dataverse the record is created or updated.
Before we get down to brass tacks there is one last thing I want to tell you, I promise we will shortly see how to create a Business Rule.
What I want to tell you is that Business Rules are “started” in an automatic manner after the end of the loading of a form or the editing part of an entity is finished.
The order of execution partly respects the order in which they were activated.
Therefore it is not possible to manually execute a Business Rule.
Okay, enough premise let’s see what we can do with Business Rules.
A Business Rule consists of conditions and actions.
In the figure above you can see the conditions and actions you can add to your drawing area.
As you can see, Business Rules can perform a limited set of actions.
The various actions can be combined by taking advantage of the if-else control, which will allow you to define branches that meet your needs.
To use an ‘action all you need to do is drag and drop in the drawing area.
Below is a simple example.
In this case a check is made by Country.
If the Country of that record in the Dataverse table matches “IT” then the visibility of the code field will be set to TRUE.
Conversely, the field will be hidden.
To set the value and condition you will have to act from the properties tab of the action or control you added to the canvas.
Once you have added all the actions needed for your rule you can validate, via the button next to Scope, what you have written.
If the validation step is successful you can save your rule and later activate it.
Remember to activate it because otherwise your Business Rules will not be executed.
But how do Business Rules behave with a Power App Canvas ?
Some considerations must be made in this case.
If you chose All Forms or Individual Forms as your Scope, your rule will not be applied to any of your Canvas applications.
Conversely, if you choose Entity as the scope of your Business Rule, when a record creation or update event occurs, it will also be executed in your Canvas app.
Clearly in your Canvas app you will have to use Dataverse as your Datasource and in particular you will have to work directly with the entity where you have defined the Business Rules.
However, not all of the actions you have available to you can be executed in the Canvas app.
You will not be able to perform the following actions :
- Set Business Required
- Set Visibility
But you will be able to perform:
- Set Field Value
- Set Default Value
- Show Error Message
So if you are working with a Power Apps Canvas and you want to control visibility, either render a mandatory field or make that field read-only, you will have to add formulas to do so.
Are these the only limitations?
There are several limitations to take into account.
One must not overlook the fact that :
- A Business Rule is only executed when a form is loaded or when the value of the referenced field is changed.
- If a Business Rule references a field that is not present in a form it will not be applied.
- You do not have an error message informing you when the rule has not been applied.
- You cannot have more than 10 if-else in a rule.
- You cannot graft if-else.
- You cannot group expressions in a condition.
- You can use AND or OR logic to create your conditions but you cannot use them together.
So there are limitations in their use but….
By adopting them, you can gain several advantages by taking a few observations into account when creating them.
To conclude this article I want to share with you some development tips:
- Use Business Rules to manipulate a limited set of fields.
- Respect the KISS (Keep It Simple Stupid) principle, keep it simple and don’t put everything into a Business Rule.
- If you need to hide a field, make sure there is an opposite branch to show it.