Microsoft Dynamics CRM 2013 Business Rules – Customisation or Configuration?

Colin Maitland, 18 December 2013

In Microsoft Dynamics CRM 2013 new functionality to enable the addition of Business Logic to entity specific forms using Business Rules has been added.

In this blog I will consider whether Business Rules should be regarded as a customisation or as a configuration task.

The use Business Rules is a way to implement entity specific Business Logic on forms without the need to write any JavaScript programming. Business Rules provide a means for non-programmers to create Business Logic. Business Rules may be used to:

  •  Show error message
  •  Set field value
  •  Set business required
  •  Set visibility
  •  Lock or unlock field

Business Rules are specific to an Entity and may be specific to either a selected Form or to All Forms for the Entity.

Q1. What Privileges are required to Create Business Rules?
Users do not need to be a System Administrator or a System Customiser in order to create Business Rules. They do however need the following privileges:

  •  In order to create a Business Rule from a Form:
  •  Customisations: Read and Write
  •  Publisher: Read:
  •  
Solution: Read



In order to create a Business Rule from a Solution:

  •  Customisations: Read
  •  Solution: Read


Q2. Do Business Rules need to be Published?
Business Rules do not need to be Published; they only need to be Activated. This is similar to activating Workflow Processes, Dialog Processes and Business Process Flows.

Q3. What Privileges are required to Activate Business Rules?
A new Activate Business Rules privilege has been added to the Customisations tab on Security Roles. This privilege is enabled on the System Customiser Security Role.

Q4. Can Business Rules be transported in a Solutions from one Microsoft Dynamics CRM Organisation to another Microsoft Dynamics CRM Organisation such as from a Development environment to a Test environment and then to a Production environment independently from other types of solution components such as Entities, Forms, Views, Charts, Fields etc.?

No. Business Rules cannot be added to a Solution independently of the entity to which they are associated. To transport Business Rules from one Organisation to another the associated Entity (and its related Properties, Fields, Forms, Views, Charts, Fields, Relationships and Messages) have to be included.

Q5. What is the impact on existing Business Rules for an entity when additional Business Rules are imported for the same entity from another Organisation?

  •  Existing Business Rules with either the same or a different Name are:
  •  
Retained if they are not the same Business Rule, identified by their GUID, as that being imported from the Solution. Their state, either Active or Inactive is also retained.
  •  
Replaced if they are the same Business Rule, identified by their GUID, as that being imported from the Solution. Their state, either Active or Inactive is updated to match the state of the Business Rule imported from the Solution.

Q6. Does Microsoft regard the creation and use of Business Rules as a Customisation or Configuration task?

  •  Microsoft regards the creation and use of Business Rules as a Customisation task. For instance, they include the section on configuring Business Rules in the Microsoft Dynamics CRM 2013 What’s New for Customisation documentation. They also provide the Activate Business Rules privilege Customisation tab of Security Roles and have enabled this privilege only on the System Customiser Security Role.

In conclusion:
The task of creating and activating Business Rules is a customisation rather than a configuration task.

However, the implementation of the types of simple entity specific form based Business Logic that can be performed using Business Rules instead of JavaScript is now simpler for people who are not Microsoft Dynamics CRM developers.

Best practices for analysis, design, creation, testing and deployment should still be followed when implementing Business Rules.