Your company has decided to take the plunge into Dynamics CRM. Good news! You now have a very popular, very customizable and user-friendly platform. Bad news. As you start sinking your teeth into it, you may have realized there are still some questions around its business rules capabilities, Portable Business Logic (PBL). How do you use it? When do you use it? Should you use it? Does it provide the level of flexibility your CRM system needs? When should you consider using a business rule management system instead?
It might seem a bit overwhelming, but the choices you make now are critical to the success of the adoption and usage of Dynamics CRM, so let’s shed some light on what I think are three of the more important factors for consideration.
1. Rule Complexity
Simple rules? Use PBL. Complex rules? Use InRule. Easy enough.
PBL is fine for logic that applies to a single CRM entity like data validations, set field values, calculations, or show/hide fields. Straight-and-to-the-point logic shouldn’t require a third party solution. Microsoft did a nice job of providing the proper level of customization for these scenarios, so use it. The key point to remember is that it can only be applied to a single CRM entity.
If there is a possibility that your rules will require logic that spans across related entities or you need to embed If/Then statements or group expressions, i.e. mixing “and” and “or”, then the complexity level rises. When you cross that line, there’s a strong argument for maintaining business logic in InRule’s irAuthor application. These are truly complex decision points that require creative and flexible ways to build the logic to support it, like built-in functions, decision tables, natural language rules and even vocabulary to help make sense of it all.
2. Testing
It is not possible to test PBL directly in Dynamics CRM, unless you have a separate CRM test environment. Even then, rules are changed, published to the system and then the user needs to re-create the scenario in CRM to initiate the call to the business rules and then verify the results. Any errors or faulty logic found during this process will require repeating the same steps until you achieve the desired results.
InRule’s testing application, irVerify, allows you, as the rule author, to test the rules as you write them without having to do the back-and-forth in Dynamics CRM. Using the existing CRM Organization Service, which can be configured to point to multiple CRM environments, you can pull data directly from CRM and load it into irVerify. You can apply the rules, verify outputs and view all logging information captured during the process, including execution times, state changes and end-to-end rule tracing.
3. Integration
When a Dynamics CRM business process requires user interaction, considerations should be made for triggering rule execution off of built-in form events (tab, field change), plugin events (create or update) or some combination of the two. Form events require configuration of a CRM entity form using the built-in form designer in coordination with PBL. Rule execution is done client-side.
Plugin events are typically used for more complex rule scenarios that cannot be accommodated via PBL. However, plugins are built on code and therefore require developer resources to create, implement, deploy, and maintain. The rules are also “hidden” in code and cannot be viewed by non-technical personnel. Rule execution is done server-side.
With InRule, integration can be accomplished in several ways. While these options may have a more technical aspect, the key differentiator is that all business rules are maintained in irAuthor and are not implemented in the code, so integration is typically a one-time, up-front resource allocation.
Check out InRule and Microsoft Dynamics CRM: Nine Considerations for Managing Business Rules for more information on PBL and the InRule business rule management system.
