Microsoft Dynamics CRM 2013: PBL

PMT

Product Management Team

10/31/2013


The Microsoft Dynamics CRM 2013 release has been happening throughout October first with CRM Online and today with the on-premise version. This release includes a significantly reworked user interface as well as a number of other new features. Many of the new features are intended to reduce the amount of JavaScript and code that must be written to customize CRM.

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 asTriglycerides >= 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.; The Microsoft Dynamics CRM 2013 release has been happening throughout October first with CRM Online and today with the on-premise version. This release includes a significantly reworked user interface as well as a number of other new features. Many of the new features are intended to reduce the amount of JavaScript and code that must be written to customize CRM.

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 asTriglycerides >= 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.

InRule for JavaScript | inrule said: "[…] couple of weeks ago we announced availability of InRule® for JavaScript through an early adopter program. To our knowledge this is […]".
Dynamic Surveys in Dynamics CRM Part II: Managing Dependencies | inrule said: "[…] this post makes extensive references to my preceding post, Surveys in Dynamics CRM Part I: Don’t Be a Monkey With Your Survey. If you are the type of person who likes to get the full story, you should go back and read the […]".
Josh Elster said: "In the time since this post was published, I've added (via a PR) full Windows Containers example code, DOCKERFILEs and scripts. They share common ancestry with the GH Gists I posted earlier, but are more up-to-date and tested. Here's a direct link to that sub-folder: https://github.com/InRule/Samples/tree/master/Developer%20Samples/WindowsContainers Now that our Samples repository is public, feel free to file Issues if you have problems or features you'd like to see implemented. If you have something you'd like to contribute, then by all means do so! The contributor guidelines and process are listed in the root of the repository. Enjoy! I'll update the body of the post as well with this link.".