Rules Interaction with Other Automation

In the previous step, we looked at how to use if-then-else conditions, applying conditions to new rules, using dependencies to action rules and implementing calculation fields. This will help us understand how the rules we have created will interact with other automations.

When building business rules, you need to take into consideration other automation (including Workflows, Microsoft Flows, and developer logic) that might exist or might need to be built.

Each type of automation that the Power platform offers implements some forms of protections or features that try to minimise the ability for one automation to impact another. For example, business rules won’t trigger another business rule as a result of a change. This prevents rules from looping. Some of the responsibility falls on the implementers to ensure what they build is compatible.

Rules Don’t Always Trigger Other Rules

Take an example where Rule 1 updates the value of the Credit Limit field to 50K and Rule 2 requires a justification if the credit limit is over 25K.

Rule 1 – Default to 50K for Preferred Customers

Rule 2 – Require justification if over 25K:

When Rule 1 sets the value, Rule 2 won’t run. Now sometimes this can be a desirable behaviour because maybe the actual requirement is preferred customer is the justification. But more often these rules were built by two consultants not realising that the second rule wouldn’t run. One way to work around this if you did want justification you would include the setting of it to be required as an additional action of Rule 1. Another option would be to consider consolidating both into a single rule handling all the processing in a single rule.

Rules that are configured with an execution scope of Entity can trigger other Entity scoped business rules as well as other automation that run on the server-side.

Rules and Developer Scripting

A similar scenario can occur when you have some of your rules are created as business rules and other rules are implemented by developers using client-side scripting. Business rule actions don’t trigger the events listened on by the developer script logic causing the latter not to execute. This unpredictable behaviour often forces teams to try to implement all rules using one technique or the other to ensure the actions are consistently executed.

Execution Order

When you have multiple Business Rules and/or developer script registered for events on a form, the system processes them in the following order:

• Any System Form Scripts
• Any Custom Form Scripts created by developers
• Business Rules run in the order activated, oldest to newest

It’s important to remember any Entity scoped business rules also execute on the server once the record is saved. These rules execute after any synchronous plug-ins created by developers that are configured to run on create or update on the same entity.

The primary concerns you need to keep in mind when mixing different types of automation are:

• Making sure everything triggers when it is supposed to run, and in the expected order.
• Automations don’t cause infinite loops by automations triggering each other.
• Automations do not have unpredictable side effects causing other automations not to run, especially data validation rules.

These are typically handled with good coordination across the project team and architecting how you implement automations to work well together.