Contact Us Today!

Best Practices for Business Rules in Microsoft Dynamics 365

Best Practices for Business Rules in Microsoft Dynamics 365

What is a Business Rule?

Simply put, a Business Rule is a code-free way to apply rules to a form in Dynamics. You can use a Business Rule to set field values, clear field values, set field requirement levels, show or hide fields, enable or disable fields, validate data and show error messages, or create business recommendations based on business intelligence.

Many of these things were done in the past through JavaScript or custom plugins, which required a developer's assistance. Sorry developers, a lot of your code can be replaced with Business Rules! I've removed all of the JavaScript from some systems and replaced it with a handful of Business Rules. The interface is very user-friendly.

Business Rules consist of Conditions and Actions. You can add up to 9 conditions to a single Business Rule. Each condition has a true/yes branch and a false/no branch. You then add actions to each of these branches as-needed.

System administrators are capable of easily understanding them and making changes when needed.  However, you don't want them to get out of control to the point where they become unmanageable. When using Business Rules, be sure to follow these easy best practices.

It's All in a Name

If you've been following my series, then you know that naming conventions are a common theme. By now you should know to use a standard naming convention for all of your Business Rules. Also, make it meaningful. Let's say I have a Business Rule that makes the State field required when the Country field contains "US". Which name would you use for the Business Rule? "Make field required" or "BTG - Account - State Required when Country = US"? If you have multiple Business Rules created for your Account forms, the obvious choice is the latter.

Not only should your rule have a meaningful name, but the Conditions and Actions display names should also be meaningful. Using the above example, my condition is going to look at the Country field to see if it equals "US". I would name my condition: "Address1 Country = US?". My condition names ask a question that will have a Yes/No answer to which I add my actions to the respective branches accordingly.

I also give my actions a meaningful name. From the yes branch off of my condition, I name my action "REQUIRED: Address1 State". On the opposing, no branch, I name my action "NOT REQUIRED: Address1 State".

You be the judge - which Business Rule logic below is easier to read? This is a pretty simple Business Rule but like I mentioned, you can have up to 9 conditions and each condition can have several actions. I created a Business Rule once with several conditions and over 50 actions for each branch.

business rulebusiness rule

Don't Pull Your Hair Out

When Business Rules don't work, the number one reason why is because you're referencing a field in the rule that isn't on the form. If you're showing and hiding fields based on the value of another field, ALL of the fields in the rule must be somewhere on the form. They can be in the header area, the footer area (remember, in the footer fields are read-only), or somewhere in the form body.

When you're using a Business Rule to show and hide fields, it is also recommended that you hide the field on the form by default. This simply improves performance. Consider that the Business Rule is going to hide the field based on some logic. When the form loads, the field will appear and then be hidden by the Business Rule. Your users will probably never see this happen since everything is so fast nowadays, but it still uses resources and processing time. One field may not make any impact but imagine hiding 50 fields in a Business Rule! That is going to make an impact if you're showing them then hiding them.

What About Tabs, Sections, and Sub-grids?

Unfortunately, at this time, you cannot use a Business Rule to interact with tabs, sections, and/or sub-grids. You may still need developer help on this one to write some JavaScript, with the exception of sections. A future blog will talk about JavaScript best practices, but it's fairly simple with JavaScript to show and hide a tab.

One nice thing about the new UI is that it will suppress your section if all of the fields within the section are hidden. This means that you can technically use a Business Rule to hide a section if the Business Rule hides all of the fields within that section.

For sub-grids, I would recommend adding the sub-grid to a section alone and then using JavaScript to hide the section. If you're familiar with JavaScript, it's much easier to hide a section than it is to hide a sub-grid.

False Actions Matter

As you're creating Business Rules and testing them, you'll learn that you can't have a condition without some sort of action occurring when the condition is true. An action isn't required however, when the condition is false. Keep this in mind as you build your condition, especially when you use the "contains data" and "does not contain data" operators.

Even though you can create a Business Rule with no actions on a false condition, doesn't mean you should. You always have to consider the opposite. Given the example we've been using, without an action to make the State field NOT required, it would have caused issues. Consider that I populated the Country field with US. The State field would be required, which is the expected behavior. What do you think happens if I clear out the Country field, or change it to something else? Without an action on the false side of the condition, nothing will happen. The State field will remain required. I would have to populate some value in order to save the record.

If I close the record and reopen it, then the State field will probably show as not required. The default behavior depends on the field configuration on the entity. Even so, this is not a positive user experience. User adoption will certainly become a factor if they have to go through so many steps to change the Country from US to anything else.

Final Fun Tips

Business Rule scope can be very powerful. By default, the scope is set based on where you are creating the Business Rule from. When you create it from the Entity, the scope is set to All Forms. If you are creating it from a specific form, it will default to that form. When you want the Business Rule to apply to a specific form, then create it from the form and leave the scope as the default. If you want the Business Rule to apply to both the main form(s) and the quick create form, then change the scope to All Forms.

Scope can be powerful in that you can change the scope to Entity and the Business Rule will apply beyond the form - it will run server-side instead of client-side. This means that you can apply Business Rules to imported and/or integrated data. Let's say you have a Business Rule that sets data in a field based on the value of another field. If you integrate with an external system or import data into your Dynamics system, then you'll want that data to be accurate as well. If your Business Rule scope is form based, then the Business Rule will only apply when you are interacting with the data while on the form. However, if your Business Rule scope is set to Entity, the Business Rule will apply whenever data is added to the entity through any means. This is, by far, my favorite feature of Business Rules.

One last tip… If you're familiar with JavaScript then you may be familiar with basing functions on the form type of create, edit, read-only etc. While there is no functionality within Business Rules to use the form type, there is a work around that you can use for form type create. If you want a Business Rule to only trigger on create of a record, you can add a condition where Created On does not contain data. Don't forget to place the Created On field somewhere on the form (body, header, or footer).

This is my 8th blog in my 12 part series on Microsoft Dynamics Best Practices. If you've missed any of my previous blogs, please check them out by clicking here! My previous blogs have covered several of the different component types in Dynamics. Be sure to check them out! They contain lots of great concepts that you can implement right away.

Contact Us!

Don't hesitate! Please contact us today with any questions you may have. We've helped several companies with these tasks by setting them up with best practices to follow that fit their business needs.

Beringer Technology Group, a leading Microsoft Gold Certified Partner specializing in Microsoft Dynamics 365 and CRM for Distribution. We also provide expert Managed IT ServicesBackup and Disaster RecoveryCloud Based Computing and Unified Communication Solutions. Please check out our comprehensive list of the Services and Solutions that we provide.