A number of commentators have mentioned that on first review many people miss one of these new features called portable business logic (PBL) — also known as Business Rules. Since we provide technology to organizations that manage business rules in their Dynamics CRM systems I took some time to explore this feature to understand it better. Specifically, I wanted to know when a customer should use it and when they should not.
Different Business Rules, Different Capabilities
Business rule technologies have different capabilities to support different types of business rules:
- Calculations and validations
- User interface rules
- Processes flow control
- Business decisions
PBL is intended for basic calculations, validations and user interface rules (hiding and showing fields, auto-filling values, etc.). And the workflow editor is great for controlling process flows. But when it comes to automating business decisions, an enterprise-grade Business Rule Management System (BRMS) is required.
Why Can’t I Use PBL for Automating Complex Decisions?
Great question. The main reason is that PBL was not intended for it. You can tell because if it was there would be if-then-else rules, decision tables, “or” statements, vocabulary, hundreds of functions, etc. Further you would have the ability to organize rules into related groups, versioning of rules and the ability to have one rule call other rules so you can create layers of logic. Finally you would have a way to safely test rules before publishing them.
Let’s walk through an example of how these functionality points assist with automating complex decisions…
Front-office and Customer-facing Applications
The front-office and customer-facing systems typically implemented on top of Dynamics CRM automate many business decisions. In the banking and financial industry, it could be eligibility for a mortgage; in the public sector, it could be benefits eligibility.
For a timely example, take health insurance sales. Sales are generated by salespeople in a call center using Microsoft Dynamics CRM as well as a self-service website backed by CRM. In both cases, the goal is to collect information about a customer to determine eligibility and the prices for various products.
To get an idea of the complexity involved, here is a real-world example…
If four or more of the following, then disqualify:
High Cholesterol, High Triglyceride, High Hyperlipidemia, Hypertension, Sleep Apnea, Smoker, BMI is over 30
Of course, “high” is a subjective term, which means there is another layer of vocabulary rules such as Triglycerides >= 200.
To go further, what if this is a family policy? You might want to run rules that determine eligibility for each family member (in a one-to-many relationship). If any one family member fails to qualify then the application is declined with a message explaining which family member caused disqualification and why. If all the members pass, then perhaps you would want to rate them individually and use a sum function to tabulate the total policy premium
Keeping up with Change
Based on data analysis, business conditions and experience, analysts constantly want to change these kinds of rules. With business language authoring, centralized storage and management and built-in testing tools, a BRMS allows the changes to be made directly by the analyst in hours or days. Without a BRMS, code changes often take months to implement through old-fashioned hard-coding. Enterprise-grade BRMS tools like InRule empower an organization’s key people to make more of an impact on its business by keeping up with change.
For more information, you can download InRule Technology’s whitepaper, Business Rules with Microsoft Dynamics CRM Online and Windows Azure. Also feel free to connect with InRule via LinkedIn if you would like to talk further.
The InRule Technology team is networking this week at the eXtremeCRM Show in Anaheim. Check out the post we put up on the eXtremeCRM Blog Page to continue the conversation.