Scope

In the previous step, we looked at Recomendations, which is an automated data entry based on the available information and business requirements. This will help us to correctly setup Business Rules.

For each business rule you create you should consider the proper setting of the rule execution scope.

Scope determines when and where the rule executes. Rules can be set to execute on a single form, all forms or entities. Scope of Entity causes the rule to execute both on all forms and on the server when Common Data Service (CDS) processes record create or update requests.

Single and multiple forms only apply to PowerApps model-driven forms and do not apply to PowerApps Canvas apps. Rules that are scoped to forms are best suited for rules that control the user experience doing actions like hiding and showing fields. Running these types of rules would have no additional impact if enabled for entity scope. Rules that enforce data validation should be evaluated to determine if the rule only applies when a user is using a model-driven form to input the data or if it would apply to all possible data modifications, even those made by other automations or developers using the API. Using either of the form options still requires that all fields required by the rule are present on the form for it to execute. If any of the referenced fields are not present, the rule will silently not run even if properly scoped to the specific form or all forms.

Choosing between single and multiple forms also needs to be evaluated. Generally, using all forms is a more scalable approach and ensures that any form created runs that rule. While a rule cannot specifically target Quick Create form, targeting all forms allows the rule to run on Quick Create forms as well.

These rules are also executed on Editable grids when a record is modified as long as all the fields needed for the rule are present in the view used by the grid. Single form rules do give you the flexibility of targeting a rule for a specific form. For example, a manager form may not have the same rule as the staff form, and access to the manager form could be limited by assigning security roles to the form.

Often single form scope is used by accident, causing issues later in the app lifecycle when someone creates an additional form. A new form would not have the rule applied because originally it had a single form scope only.

Choosing a scope of entity is powerful because it ensures the rule runs for all possible data modifications. Execution occurs in all places that All Forms scope would execute as well as on the server when the record is created or updated. For example, a rule setting credit limit on account to $5,000 if it didn’t contain a value, would run even if a developer created the record via the API or the records were imported using CSV file.

Similarly, data validation rules that must be strictly enforced should also use entity scope to ensure they are consistently enforced across all ways a record can be created or updated. Care should be taken however where rules use the Show Error Message action. When this action is processed on the server it will fail the request in progress with that message.

Take an example where historical data is being imported and didn’t contain credit limit, however, an entity scoped business rule was created to show an error if credit limit did not contain data. The import would fail, and the data could not be imported until the rule was turned off or the scope changed to a single or all forms.

Scope can be modified at any time as long as the rule is not active. It’s a good idea, as your project nears completion, to review all the rules you created and ensure they are properly scoped.