Business Rules Overview

In this module, we’re going to be looking at business rules. When we think about business rules, business rules can be used to automate and enforce common requirements. This can be as simple as hiding a field, setting a default value, or any other simple requirement that comes along like that. You’ll learn as we talk about conditions and actions that you can perform with the business rule engine. Rules are created always in the context of an entity. So for example, I might create one or two rules on the account entity or on the contact entity to enforce the requirements. Rules can execute both on the client and the server, depending on the configuration.

I’ll drill down on that in a little bit to make clear what I mean by the client and the server, and how that delineates where a rule runs. Now think about rules as an alternative to having developer code-based rules implemented. But at the same time, as we get in and discuss some of the scenarios, you may find that there are still some scenarios where developer code-based rules are the preferred way of implementing them. And we’ll help you understand how to make that decision. Let’s look at the anatomy of a business rule and what makes it up. We’re going to start in the context of the entity. And I’m going to use account in the example I’m going to go through.

We’re going to create a business rule. I’ll call it business rule one. You could call it check for default credit limit. And we’re going to check to see whether we need to apply a default credit limit. Now the first thing I’m going to do is I’m going to have a condition. The condition is going to do something like, for example, check if the credit limit value has some data. Now the way it does that is it has rules. You can have rules one, two, three, four. You can have many different rules associated with that condition.

They all have to either be all true or one of them has to be true, depending on how you configure the condition and the rules to work together. We’ll talk more about that as we dive in and talk about conditions later in this module. Now if the conditions turns out to be true– in other words, in my example that the credit limit field did not contain data– then we’re going to run one or more actions when the condition is true. We can also run actions when the condition is false. So in other words, in my example, when the credit limit field did not have data, we could do something else.

Now here’s a look at it in the actual visual designer. Now the visual designer is how you’ll build the business rule. Now it starts by picking an entity, determining the scope. And we’ll talk all about that as we drill deeper into the module and discuss topics in a little more detail. But the first thing you’re going to do is add components to the Canvas and build out the rule. You’ll notice I have a condition, and I have one action. The green one is an action. I’m going to add those by dragging them from the components over on the right hand side onto the Canvas. So in this case, I drag the condition. I drag a default action.

And I configure that action for the values I wanted to have in there. Now, as I build this out, the business rule might get more complex and be bigger than what would fit on my screen all at once. I can use the map view to navigate around the business rule, and show portions of it that makes sense to me. I can also look at a text view of the business rule rather than looking at it graphically. I can use the text view to quickly ascertain what the business rule is doing. Looking at this one, I can see if credit limit contains data. Then go ahead and set the default credit limit to 50,000.

Well, I could probably determine that in my particular example, I wanted that to say, if it does not contain data. And that might give me another way to visually check to be able to go back and make that change. Up at the top, the command bar is there to help me out with adding components to the visual design surface, just like I did with the components dragging and dropping them. The add button just provides another way of doing that. The cut, copy, paste allow me to replicate or move some of the actions and components around on the Canvas.

It’s a quick way, like for example, if I want to copy the action on the true side to the false side and then configure it for the false condition. Oftentimes, that’s a fast way to build business rules. Now you want to make sure when you’re using these commands in the command bar that you’re always starting with the proper selected action or component on the Canvas because it is context sensitive. You don’t want to be deleting the wrong item from the Canvas. Now before we end this discussion, let’s talk a little bit more about the client and server side that I mentioned when we started out. The client and server side is a delineation between where the rule will run.

Rules can be configured to run both client and server side or just client side, depending how you configure the rule scope for that particular business rule. When you configure a rule to run only on the forms, it will run on load of the form as well as on change of any of the fields involved in the business rules. When you configure it to run on the server side, on save of the client changes– so in other words, the user in the client application makes a change, hits the save, or the automated save happens– that triggers an on save, which transfers the work to the server side where the actual rule will process again on the server side.

We’ll get into this a little bit more as we get into looking at the scope, and how you should make the decision what the scope should be configured. That’s enough of an overview for now. Let’s dive in and discuss more of the topics on business rules so you can understand how all this works together.