One of my favorite new features as an IT consultant of Microsoft Dynamics CRM 2013 is referred to as Business Rules. Basically, business rules let you create a dynamic user experience…

One of my favorite new features in Dynamics CRM 2013 is referred to as Business Rules. Basically, business rules let you create a dynamic user experience in the context of forms, such as:

• When a certain field value is selected, change the requirement setting for another field.
• Calculate the value of a field based on the values of other fields.
• Determine whether a field is visible from the value of another field.

These examples all involve forms changing dynamically, based on something a user does. In previous versions of Dynamics CRM the typical customization technique was to use Jscript code. In the new version you’ll still encounter plenty of requirements that will steer you to Jscript. For many, however, the business rules approach will accomplish the identical result, but with several advantages:

• less work
• easier to support
• no code required

Create a Business Rule to Calculate a Field Value

The easiest way to get started is with an example, so let’s apply the business rule treatment to a classic dynamic form requirement: using the Est. Revenue and Probability field values on an opportunity to calculate a “probability-weighted” revenue value. I’ve already created a custom Currency field and named it Weighted Revenue, so let’s pick up the action in the opportunity entity’s form designer.

1. Click the new Business Rules button on the ribbon. The Business Rules Explorer appears on the right.

2. Click New Business Rule to open the business rule designer.

3. Enter the name of the rule in the space indicated, and then click the “+” in the Condition section to add your first condition.

4. Select Est. Revenue in Field (first column) and then select Contains Data in the Operator list, like this:

5. Then click the green check-box to lock it in, and click the + icon again to add another condition. We can only calculated weighted revenue if both estimated revenue and probability are provided, so the second condition should be that the Probability field also contains data. At this point, here’s what you want to see:

6. Next, click + in the Action section, and select Set Field Value from the list of actions:

7. Select Weighted Revenue in the field list, and then in the Type column select Formula:

8. When you select Formula a second row appears where you can click a few things and build your formula. At first it looks like this, with Actual Revenue appearing by default in the alpha-sorted field list:

Basically, what you do here is use the second row to define what value should go into the field selected on the first row. You have two options:

1. Select Field in the Type drop-down, to involve two fields in the formula
2. Select Value for the Type, which we’ll see an example of in a minute.

 

9. For the current example, select Est. Revenue in the first Field list, then select * in the Operator drop-down, then Field as the Type and Probability in the second field list:

10. At this point we have Weighted Revenue calculated, but we should divide the result by 100 to get it into the right units. So add one more action, like this:

11. Click the check-box to lock that in, and then we really are done, apart from an optional description. Here’s what my rule looks like at this point:

After you create one you can save it, and then you can activate it. When activated, the rule changes to read-only in the designer (just like a workflow or dialog process), and you can close the business rule form and then go see how it works.

Now let’s take a look at the user experience. In CRM 2013, fields placed on the form header are editable, so I added the Est. Revenue and Probability fields there, as well as on the form. As soon as you change them, the Weighted Revenue field is calculated and displayed just the way it should be.

Business rules function similarly to Jscript functions within form libraries.

Maintaining Business Rules

Now that we’ve seen how to create a new business rule, what does it look like after they’re created? What if you need to make changes? Where do they live? Continuing with the previous example, suppose you’re on the opportunity form designer and you select the Est. Revenue field and open the Field Properties dialog. There’s now a Business Rules tab where you can inspect any of the business rules the field is part of:

 

Field Properties for Est. Revenue Field

You can edit the business rule right from this dialog, as an alternative to opening the Business Rules Explorer on the form. Notice that the Est. Revenue field is identified as Primary in the Type column. To understand what that means, let’s take a look at the corresponding information for the Weighted Revenue field. (Remember, this is the field that gets calculated in our business rule.)

 

Field Properties for Weighted Revenue Field

The key difference is that the calculated field is only Participating in the business rule rather than being a Primary. I don’t get a ton of intuition from the terminology, so I guess I’ll just have to remember it: in a calculated field rule, a Participating field type is the one that’s being calculated; a Primary field type is contributing its values to the calculated field.  

Limitations of Business Rules

What’s that? The product’s not even released yet and these consultants are already coming up with limitations? I know, right?

Actually, I only wanted to point out a few of the things business rules apparently aren’t designed for, so you can plan your development efforts accordingly. So, based on what I’ve read and been able to figure out so far, here are a few limitations you should take into account.

No conditional branching in the designer

As far as I can tell, you can only have a single set of conditions and a single set of actions. Heuristically, you can do this:

• If <<these conditions are met>>
  • Then, <<do this>>

But you cannot do this:

• If <<these conditions are met>>
  • Then, <<do this>>
• Otherwise, If <<these different conditions are met>>
  • Then, <<do something different>>
• Finally, If <<all else fails>>
  • Then, <<do some default thing>>

So if you needed a business rule to set the Customer Rating field to A if an account’s credit rating is AAA, set it to B if it’s AA, and to C for anything else, that would require three separate business rules.  So depending on your skill-set, it might be more efficient to handle conditional branching requirements with Jscript functions.

Single Entity Only

The only fields you can access in the business rules designer are fields from the entity the rule’s written for. This lets you do plenty of useful things, but here are two kinds of rules you cannot create with this limitation:

• Cannot set a value on a child record based on a field value on its parent. Example: you want to require approval for large opportunities associated with accounts with a low customer rating. You can do this with a workflow process since they have access to parent records. But business rules do not.
• Cannot set a value on a parent record based on a field value on its children. Example: you want to calculate a “Total Revenue” field on an account record any time an opportunity associated with it is closed as won. There’s no way to specify a rule like this, since the designer only provides access to the field values on the current record, and there are no aggregate functions to let you do things like sum across records. So for calculating aggregates, your best options are still probably to use goals or plug-ins.

Business Rules in Context

I think Business rules will quickly become an important part of our expanding kit of Dynamics CRM customization tools. Based on my initial experience, they provide a rock-solid, no-code alternative to build functionality that traditionally required Jscript. A business user can build them with a point and click experience, and the system takes care of the plumbing. As I mentioned, they can’t do everything Jscript can do, but I’d recommend starting to use them for the subset of things they can do. 

In a larger sense, how do they fit into the overall CRM customization toolkit? This is an important question, and one that gets more complicated with every new product upgrade – and especially so with the upcoming Dynamics CRM 2013 release. In addition to business rules, other important new customization tools include business process flows and real-time workflows. Look for articles on those and related topics in the near term, and remind yourself that having lots of choices is a good thing!