Common Patterns and Techniques

In the previous step, we examined formulas and now we will learn about common patterns and techniques. Business rules have a number of common patterns and techniques that can be useful in creating efficient implementations and avoiding common mistakes.

Don’t Forget Else

Business rules do not have a default or implied action. If you perform any action that affects user experience based on a condition, this action is not automatically reversed when conditions are not met.

For example, the following business rule sets the Credit Limit field as Business Required if the account’s Annual Revenue is less than $100,000.

If during the data entry user enters $20,000 as Annual Revenue instead of $200,000 and moves to the next field, the business rule will set the Credit Limit field as Business Required, as expected. If the user comes back to the Annual Revenue field and enters the correct value of $200,000 the Credit Limit field will stay as required, potentially preventing the user from saving the form.

To resolve this inconsistent behaviour, add ELSE condition that sets Credit Limit to Not Business Required. That way the requirement level will change dynamically as users enter a different value in the Annual Revenue field.

Always consider that the business rule may be evaluated multiple times throughout the data entry process and, if appropriate, add counter actions for the situations when conditions are not met.

Using Conditions

New Records

Business rules run regardless of whether the record is just being created or an existing record is being edited. Sometimes it is useful to differentiate these two situations. Conditions on system fields like Created By can be used to branch the business rule based on whether the record is new.

Note that the field you base your condition on must be present in the form body or the header for the rule to work. Alternatively, if you have a default business process flow for the entity, the field can be included as a step at the first stage of the process flow, for the business rule to work.

Execute on Change

To ensure consistent action execution when a field changes, that field needs to be included as part of the condition even though the condition may always evaluate to true, for example.

Run Always

Conditions on business rules are mandatory. Sometimes it’s desirable to run the sequence of actions unconditionally when the form is opened. Combining opposite conditions on the same field using an OR operator will result in the condition being always met.

Note that this rule will execute when the form is opened and will continue to be executed every time the account name changes.

Dependencies

When actions change a field value, this change is not processed by other business rules or client-side scripts. In other words, business rules won’t trigger another business rule or a client-side script as a result of a change. This prevents rules from looping. Interactions between business rules and other automation are discussed in detail in the next topic.

When multiple business rules are registered on the same entity they run in the order activated, oldest to newest. It is recommended to design and build business rules so that the order of execution does not matter. However, if you need to change the order, deactivating and reactivating a business rule will push it to the bottom of the execution order, i.e. will make it to run last.

Using Calculated Fields

Consider the limitations when using formulas in business rules. Date and time fields are limited to adding/removing days and numeric fields allow only arithmetic operations. This allows for simple actions, for example, increment the follow-up date by 30 days if certain conditions are met, or set credit limit to be 10% of annual revenue.

For more complex actions use business rules in combination with calculated fields. Consider breaking up complex formulas into a series of smaller steps and check if any of the steps can use calculated fields. That approach often allows overcoming some of the limitations. For example, there is no concept of today in business rules, however, it’s possible to set the calculated field that always evaluated to today’s date and then uses that field in a business rule formula.

Note: calculated fields are not dynamic and evaluated only when a record is retrieved. When using calculated fields in business rules make sure that the rules depend only on the values of the fields as retrieved.

Localisation

If you have more than one language provisioned for your organization, you will want to localise any error messages that you have set. Each time you set a message, a label is generated by the system. If you export the translations in your organisation, you can add localised versions of your messages and then import those labels back into the system, so that people using languages other than your base language can view the translated messages.

Working Efficiently

To take a snapshot of everything in the Business Rule window, click Snapshot on the action bar. This is useful, for example, if you want to share and get comments on the business rule from a team member.

Use the mini-map to navigate quickly to different parts of the process. This is useful when you have a complicated process that scrolls off the screen.

As you add conditions, actions, and business recommendations to your business rule, the code for the business rule is built and appears at the bottom of the designer window. This code is ready only and is useful as a concise textual representation of a complex business rule.

Tracking Rules to Requirements

When designing and creating business rules as part of a project, use built-in features to document the rules and reference the requirements.

• Business rule name defaults to Enter Rule Name and is not required to be changed.
• Description defaults to Click to add description.

Neither the name nor description are exposed to the users – make sure that they are descriptive. Both properties of a business rule offer a good opportunity to tie the rule back to the business requirements.

One Rule vs Multiple Rules

If business requirements are complex and span multiple fields, you need to evaluate creating a single but complex rule vs creating multiple rules. Consider the following when making the decision:

• Individual rules provide greater flexibility when used with Editable Grids.
• Multiple rules can sometimes be less complex and easier to maintain.
• Multiple rules have more chances of not triggering due to the dependencies. Consider duplicating some actions in multiple rules to accommodate for lack of triggering by other rules.