Microsoft has architected the Dynamics CRM platform to allow administrators to customize the environment to fit business needs, without requiring complex coding skills of a developer. This no-code configuration option is very powerful and allows the CRM environment to be built with a large portion of custom functionality before having to rely on custom scripting or coding practices.
This is the first article (of two) where I am going to detail out the different areas of no-code configurations, to give you an idea of what you can do with this type of customization in Dynamics CRM. Keep in mind that this list is not all-inclusive; I am only covering the larger areas of no-code configurations. I will be covering System and Custom Entities, along with Business Rules in this first part. Part 2 will cover Workflows and Dialogs, Business Process Flows, and Dashboards/Reports.
Configuring System Entities
Dynamics CRM comes with a set of system entities when installed. These entities make up the core of an out-of-the-box install. While you cannot delete a system entity (which is a good thing), you are able to configure them to extend their functionality. Here are some of the things you can do with system entities:
- Create custom fields
- Modify the Display Name of system fields
- Change whether system fields are required/optional
- Change the minimum/maximum range values on fields of certain data types (decimal number, for example)
There are some restrictions when configuring system entities, which are in place to protect and maintain system stability. Here are some of the things you cannot do:
- Delete a system entity
- Delete a non-custom field on a system entity
- Change the data type of a field
- Change the name of a field once it has been created
You can also create custom forms and views to extend how a system entity is displayed in the environment. Custom forms can be created to replace system forms to provide a custom look-and-feel. Custom fields can be added to system forms if a totally new form is not needed. System views can be configured to display additional fields or their filter criteria can be modified to provide custom data results. Custom views can also be created to be used in place of system views if other criteria or entity fields need to be displayed in the system. Please note that the filter criteria you can create are limited to what you can configure in the dialog window.
Figure 1: Example of System Form editor with Custom Fields
Another item to keep in mind is to make sure you publish any changes you make to the system, when you are ready to test them. Dynamics CRM allows you to make changes to the system without actually committing them. This allows you to load/add your changes and make edits before you actually apply them to the system. If you make changes and don’t publish them, they will not work as expected.
Figure 2: Example of Default Solution with Publish All Customizations button
Creating Custom Entities
If the system entities that Dynamics CRM provides is not enough for your requirements, you can also create your own custom entities. This is where CRM shines in terms of no-code customizations – you are able to create fully custom entities in the system without writing a single line of code! This allows you to configure your CRM system to fit almost any complex business requirements you may have.
There are a vast number of configuration possibilities here, but the most common I have seen is where custom entities are created to support the standard entities in the system. Sure, you can use custom entities completely, but why not leverage the functionality that Microsoft provides with Dynamics CRM, and then extend that functionality by creating custom entities that fit your need?
Please note that you are still not able to do certain things in the system, even with custom entities. For example, you are not able to change the data type on a field once it has been created. You are also not able to change the name of a field once it has been created.
Let’s go through an example. Suppose that we want to have our CRM system be able to display and keep track of automobiles owned by contacts. Since CRM doesn’t provide an entity out of the box to record automobiles (ignore the Products entity for this example), I can extend the functionality by creating a custom entity of my own to handle this.
The first thing I want to do is to design my custom entity, so it meets my business requirements. I would like to provide the following:
- Allow a contact in CRM to own one or more automobiles
- An automobile record in CRM has the following properties:
- Make
- Model
- Year
- Mileage
- Owner
- An automobile record in CRM can only be owned by one contact
Once I have these requirements, I can create the custom entity in CRM. This is done by creating an unmanaged solution (in the Settings->Solutions area) – I will call the solution AutomobileTest:
Figure 3: Creating a custom entity
Once you save your new custom entity, the dialog then allows you to create fields for the entity. Dynamics CRM creates some fields by default for you, such as the Name, CreatedBy, CreatedOn and Status.
As you create custom fields on your entity, note that the system prepends a publisher designator (“cncy_” in our example). A publisher is needed in order to create solutions in Dynamics CRM, and they are used to help manage customizations (managed or unmanaged).
Figure 4: Custom AutomobileTest solution with custom Automobile entity
Once the fields for our custom entity are defined, we can define the relationships between AutomobileTest and Contact entities. Since the requirements state one Contact can own multiple automobiles, and that each automobile record can only be owned by one Contact, that defines a N:1 relationship on our custom entity.
Figure 5: N:1 relationship between Automobile and Contact entities
Note that when creating this relationship, you must define the Primary and Related entities, along with a Display name. You can specify other attributes about the relationship, such as if it’s searchable, or the type of behavior (parental or referential).
There are 3 types of relationships available in Dynamics CRM:
- 1:N (One-to-Many) – relates one entity record (the Primary) to one or more different entity records (the Related).
- N:1 (Many-to-One) – the converse of 1:N relationships. This is really the same type of relationship as 1:N, just from the perspective of the related entity.
- N:N (Many-to-Many) – relates many entity records to many different related entity records. Sometimes referred to as an Intersect entity.
Entity relationships are an important part of the Dynamics CRM schema, as they allow you to relate records to each other. This also allows the ability to define the schema to fit your business processes.
Business Rules
We now know how to configure standard or custom entities in Dynamics CRM that function in a standard and consistent manner. What do we do if we want to apply some custom logic on these entities? In the past the answer would have been to write some Javascript code to implement this custom logic. Fortunately, Microsoft has introduced a declarative interface that allows you to create custom logic without writing Javascript. These are called Business Rules and are new (as of CRM 2013).
Business rules provide an easy way to evaluate business logic in Dynamics CRM, without the requirement of using custom code scripts. This can be performed on either the client or the server side. CRM provides a declarative interface that allows creation of these business rules, which can be applied against entity or entity fields. Please be aware that Business Rules in CRM do not replace custom scripting in CRM, as they are not able to perform all the things that custom scripting can perform. They can perform some of the more common things that scripting was providing in the past, as listed here:
- Set field values
- Clear field values
- Set field requirement levels
- Show or hide fields
- Enable or disable fields
- Validate data and show error messages
Also note that Business Rules will only work for Updated Entities or custom entities.
In order to create and configure a Business Rule in CRM, you need either the System Administrator or System Customizer security role. You will also need the Activate Business Rules privilege in order to activate a Business Rule. The rules you create are not applied until you activate them. Conversely, if you wish to edit a rule, you need to deactivate it first.
There are a few different ways you can access Business Rules in Dynamics CRM.
-
Via Solution (Entity level)
-
Via Solution (Entity field level)
-
Form Editor (Entity level)
-
Form Editor (Entity field level)
Business Rules have a scope – this determines the context of where the rule runs in Dynamics CRM. The different scope selections are:
- Entity – runs on all forms and server
- All Forms – runs on all forms
- Specific Form – runs on that specific form
Note that you cannot select a scope of multiple specific forms. If you choose Specific Form, the rule will run on that one form only. This is also the default scope if you create a Business Rule via the form editor. Choosing All Forms means the rule will run on all the Main forms as well as the Quick Create forms, provided all the referenced fields are present on those forms.
Support for If/Else branches and AND/OR logic is supported for Business Rules. You can create logic in your business rules to check for certain conditions and perform specific actions if those conditions are met.
Figure 6: Business Rule with If/Else branch
There are a few limitations to be aware of. First off, nested If/Else statements are not supported. You can only have one level of If/Else statements. Grouping of expressions in a condition is not supported. Expressions can be combined using AND or OR, but not both. You also have a limit of 10 if/else conditions for a single Business Rule.
Conditions and actions are also supported for Business Rules. Conditions are the checks that you create to determine when specific actions are executed. Once a condition is met, the Actions you create will run as part of the rule. If a condition is not met, then the logic of the rule will skip over the action for when that condition is met.
There are a number of actions available:
- Show error message – used to set error message text when a field is not valid
- Set field value – used to set the value of the field. There are 3 types here:
- Field – sets the value of one form field with the value of another field
- Value – sets the value of one form field with an entered value
- Formula – sets the value of one form field with a simple calculated field. Only valid for numeric or date data types
- Set business required – used to change the requirement level for the field. Options are Business Required and Not Business Required
- Set visibility – used to change whether the field is displayed/not displayed on the form. Options are Show Field and Hide Field
- Lock or unlock field – used to change whether the field is enabled/disabled on the form. Options are Lock or Unlock
There are some general limitations when creating business rules:
- Business Rules only run when the form loads or when field values change. They don’t fire on save, with the exception of when the scope is set to entity level
- Business Rules only work with fields. If you wish to perform logic against tabs and sections you have to use custom scripts
- If you set a field via a Business Rule, the system will not fire that field’s OnChange event. This is to protect against circular references
- Business Rules that reference fields not present on a form will not run. No error will be displayed, so use caution if you’re removing fields from a form – always check that they are not being used on a Business Rule
Finally, you should be aware of the order in which logic is applied to Business Rules, in relation to system and custom scripts. First off, any system scripts are applied first. Next, any logic in custom form scripts is then applied. And finally, logic in Business Rules is now applied. If there are multiple Business Rules, they are executed in the order that they were activated.
In conclusion, you can see that using no-code configurations in Dynamics CRM has enormous power and flexibility in tailoring the environment to almost any business need. Part 2 of this series will discuss workflows and dialogs, business process flows, as well as dashboards and reports.