CRM Customization for Developers: Where to Put Business Logic?

As we recently discussed, the n-tier principle of Separation of Concerns is an important, and very useful, guideline to follow when designing a complex application. This principle calls for separating the components of an application (user interface, business logic, and data access) into distinct layers in order to simplify development, debugging, and code maintenance. For example, a user interface component, such as a web form, should only be responsible for displaying a business object to the user. If the web form contains any business logic, such as enforcing a string field’s maximum length, the principle has been broken. If this requirement were to change later, the developer would have to hunt down the code to change. If another UI component uses the same business object, he may neglect to duplicate that field’s maximum length rule. Very quickly we have a buggy, hard to maintain application.

Unfortunately, when it comes to CRM development, the Separation of Concerns principle can be easily dismissed because of time or other project constraints. Business logic can be injected into CRM in many ways, including entity design, form java script, and plug-ins. If something unexpectedly happens in CRM, or if a use case changes, a developer can find himself searching in many directions.

Required Fields in CRM Business Logic

Let’s examine one particular type of business logic requirement and how it is handled by CRM: required fields. A field’s requirement level is defined when configuring the field and stored at the metadata level. Regardless of what is requesting a record create or update (the UI, import, workflow, or plug-in), eventually the request is handled by the CRM web service, and the CRM web service utilizes metadata to enforce field requirements. Just what we want: a single place to define this type of business rule, and it is enforced regardless of the input method. Separation of Concerns is satisfied.

Now, let’s complicate things just a little. What if we have a conditional required field? For example, if the pick-list field Customer Type has a value of “Other,” then the text field Define Other is required. It’s a very common requirement in any application, which CRM has no native way of handling. A conditional requirement cannot be defined at the metadata level.

Traditionally, CRM developers enforce this type of requirement by java script in the CRM form. It’s easy to do, and the user gets immediate feedback before the record is saved. It’s also a clear violation of Separation of Concerns: business logic in the UI. Additionally, this rule is only enforced by the UI. If a record is imported or manipulated by a workflow, the CRM web service has no knowledge of the rule and will let it slide.

CRM Plug-Ins

What a developer should do is enforce this requirement using a plug-in. CRM plug-ins are just about the closest thing we have to a business logic tier in the CRM world. A plug-in can intercept a CRM web service call, check for special business rules, and throw an exception if necessary to prevent the operation. If the user was saving a record through the CRM UI, he will see a dialog with the exception message. Users might complain about getting this message after the save attempt, but the developer is happy because Separation of Concerns is satisfied.

Separation of Concerns can be easily forgotten while developing CRM customizations. Habits, time, project constraints and a better user experience might influence you to place special business logic in the UI. However, a better place is a plug-in since plug-ins can act as a business logic tier.

In my next post I will discuss implementing a simple lookup control for custom CRM pages. Tribridge consultants are available and willing to offer help on CRM customizations. Contact us so we can help you get the most out of your CRM application.

Next Post