CRM Rules! Technical

Once you use CRM Rules! and see the power that it has, you’ll never go back!

We used CRM Rules! to build CRM Rules!

CRM Rules! is a complicated software program. As we built the internal engine, we were able to use CRM Rules! to build and expand itself.

Looks just like CRM 2011

How does it work?

Want to customize a demo for a client fast? Need to add a ton of JavaScript rules? CRM Rules! can help.

CRM Rules! is installed as a managed solution in the CRM Organization you will be customizing.  (Our license key uses this Org name to ensure you have a valid license to produce rules for this CRM tenant.)  Our solution consists of over 20 custom CRM entities that store the rule information, custom JavaScript that makes our CRM forms come alive and makes entering rules easy, and plug-ins that produce your Script code.

When you run the initial setup task, CRM Rules! plug-ins gather all of the entities in your CRM system, system and custom, and stores them in our Rule Entity table.  We do similar steps to capture all of your metadata into our  other ‘shadow’ tables each time you click the Create/Update Entity button.  These Rule tables are used to drive filtered lookups on our CRM Rules! forms, and allow you to select your values from your field names when building conditions. In fact, our setup program goes as far to create conditions for you (all of the possible values from an option set, e.g. Each value creates one condition: Status = “Active”, and Status = “Inactive” can be pre-built).

CRM Rules now offers 9 Rule Types.  Each Rule Type collects different information from you in order to carry out your request.  The most frequently used Rule Type is the “IF/THEN/ELSE Standard” Rule Type.  This rule type has three main components:  conditions, actions, and events. In the simplest case, a rule can have no conditions, and one action, as in a form load function. Conditions ensure that the actions only happen after all of those criteria have been satisfied.  The Actions affect your CRM forms and data.  Events let CRM Rules! know when this function should fire.

Conditions can be selected form those already built, or created from scratch, using your fields and your field values, as condition parameters.  You only have to create a condition once in CRM Rules!, then you can just select it from the list. You can build intricate conditions by using our combination of 8 “AND” and “OR (” operators and parenthesis combinations.  New in version 4.0, you can now compare field values between two fields, and can also use functions in conditions. You can also run rules as an action, allowing you to build rules of infinite depth.  Our code takes your input and creates the code that enables us to capture that value, and compare it to the criteria you have specified.  The engine then processes Actions.

Actions are the heart of the CRM Rules! “IF/THEN/ELSE” Rule Type.  We currently have over 60 CRM Rules! Action Types (or CATs) available, such as “Hide Tab”, or “Set Value”.  If you don’t see something you need, please ask, as our customers will drive our priorities.  We will keep building out our CRMRules! Action Type until we have covered all of the possibilities available in the SDK, and will keep pace with new types (like Follow).

In addition, if Microsoft changes their rule syntax again, it’ll be our problem, not yours.  We’ll change our output to match their requirements. If you’ve estimated the cost of moving 4.0 rules into the 2011 environment, you’ll appreciate the value and peace of mind that CRM Rules! brings, lowering your long-term cost of ownership in your critical CRM system.

Each action, or CAT, is coded as a separate C# class, so we can add new ones without affecting the old.  Some, like Show Field, are short.  Other classes that deal with setting field values based on a value from a field in a different entity, are quite complex, and have hundreds of lines of C# code that generate dozens of lines of JavaScript code, including the ODATA call required to capture data from another entity.

The Rule Event section of each rule identifies the CRM Event Handlers to create.  In English, here is where you specify when this rule fires.  We’ve made it easy in the CRM Rules! interface through ‘auto deploy’: for example, you can select “All Forms”, and “All Fields (specified in the conditions)”.  When you click Validate, we will inspect the conditions and identify the fields used, and create onChange events for each of those fields.  It will also generate an onLoad event handler for the form.

When you click the Validate button on the CRM Rules! ribbon, our code (a) does some preliminary checks to make sure you have specified everything we need to build the rule, (b) generates the JavaScript function, encapsulating your conditions and actions, and (c) prepares the Rule Event Deployment records that are used by the Deploy process to insert this rule into the specified CRM form, and into the event handler specified.

When you click the Deploy button, CRM Rules! really goes to work… First, CRM Rules! always deploys by entity.  So when you click that button, all Rules that are in “Deployed” or “Ready to be Deployed” status in that entity will be added to CRM.  First, we remove the existing CRM Rules! web resource file, if one already exists.  This means we rebuild all of our code and event handlers for that entity each time you click the Deploy button.  Secondly, the JavaScript for all rules in this entity is concatenated into one web resource file, and, using standard SDK C# commands, uploaded to CRM.  Then, each Rule Event Handler is processed, using the SDK to create event handlers in CRM.  Finally, we publish all customizations.

The result:  all of the ‘ready’ rules in that entity have been loaded onto the form, and are ready for your testing.  The beauty of this is that you can see the event handlers in your normal CRM Form Properties window.  You can see and read the web resource file, in CRM.  You can use F12 and standard IE debugging to see what the JavaScript is doing. So, the only thing you have to learn is a few things about how to build effective sets of rules that work together well (basically, you still need to plan what you want to do), and everything else you need to do is: in CRM!

One final note: after building your rules, you will have a searchable CRM system that catalogs your every JScript customization.  You can use standard CRM tools search as wildcard search to find that code you need to change.  You can create views to organize your rules by entity or any other criteria on our forms.  You can click on a field value, and see if it is used in any conditions. We can create reports, showing what functions are firing on which events.  In short, you have built a fully documented business rules database, in your CRM database.  Oh, and at the same time, saved a bundle of time NOT writing JScript code (or a bundle of money for somebody else to write it).

Supported Rule Action Types in CRM 2011

We are constantly adding new CRMRule Action Types. In version 4.0, we nearly doubled the Action Types available. To date, we support:

• Collapse Tab
• Expand Tab
• Hide Section
• Hide Tab
• Hide Field
• Show Field
• Show Tab
• Set Section Focus
• Set Section Label
• Set Tab Focus
• Set Tab Label
• Show Section
• Show Tab
• Disable All Fields
• Enable Field
• Hide Field
• Show Field
• Required Fields
• Set Field Label
• Format Phone number
• Refresh SubGrid
• Hide IFRAME
• Hide NAV Item Label
• Hide Subgrid
• Set Focus to Web Resource Control
• Set IFRAME Label
• Set IFRAME Source
• Set Nav Item Label
• Set Subgrid Label
• Set Web Resource Control Label
• Show IFRAME
• Show Nav Item Label
• Show Subgrid
• Show Web Resource Control
• Custom JScript
• Field Evaluation
• Invoke Process Dialog
• Run Rule
• Run Workflow
• Set Focus
• Set Option
• Set List
• Always Submit Field
• Copy Fields From Lookup Entity
• Fire OnChange
• Set Field to Derived String Concatenation Value
• Set Field to Mathematical Formula
• Set Field to Now
• Set Field to Other Field Value
• Set Field to Value From Other Entity
• Set Field to Value (to a constant)
• Set to Null (blank out a field)
• Return a value
• Set Field to Function Return Value

What Can You do with CRM Rules!?

Quite a bit, actually…  for example:

• Conditionally set a field to be required.  If the Contact Type = “Customer”, require an email address.
• Format a phone number immediately after you enter the phone number.
• Derive the Name of the entity from the value of several fields on the form.  Very useful for creating a standard naming convention: see all Hot Opportunities by just looking at the name.
• Perform mathematical calculations, conditionally, when fields change.  If you use custom entities and want to calculate price times quantity, not a problem…
• You can now even Count Children!   Automatically update and display in your Account header the number of Contacts and Opportunities linked to this Account.
• And, if you use the Count Children feature, you could then solve the “Not” problem, and find all Accounts with no Opportunities!
• Another rule type lets you “Sum Fields Across Child Entities”!   You can now calculate the total expected value of all opportunities tied to each account.
• Conditionally set one of several fields to be required.  If the Email is blank and the Main Phone is blank, disallow the save and display an error message.
• Make only certain option set values appear, again based on any conditions.  If the Account Status is ‘Suspect’, do not allow the user to select ‘Hot’ from the priority field.
• You can implement “hierarchical picklists”: make the State / Region list dependent on the Country that is selected.
• You can copy many fields from one entity to another, to show the Product Master custom field values on the Order Product form, to help your users know more about their products with less clicking.
• Taking this further, when they choose the product, you can change the look of the entire form: hiding tabs, showing one section out of many in one tab, etc.
• You can show fields or hide them.  If the contact is a ‘prospect’ then hide the Account Manager field.
• Combine actions in your rules to then show that field AND make it required if the contact is a ‘customer’!
• Conditionally run workflow, so you only run the workflow when it has something to do!  This makes that workflow left nav bar item a useful history of automation applied to this record, instead of a cluttered mess.
• Conditionally Invoke a Process Dialog, based on data!  OOB, you can only invoke a process dialog when a user clicks a button.  Now, you can run it based on the change event of any field on your form.  This could enable you to create an incredibly extended form that guides the user down a problem-solving path, without cluttering your main form.
• Compare one field value to another, or to a constant, or to a function return value!
• Compare the value of a field to what it was when the form was opened, and take action.  For example, invoke a process dialog to get reasons why an opportunity is being changed from hot to cold, right when the user is making that change.
• Hide a left nav bar item on the form until the status reaches a certain point, or for users who don’t have a certain role.
• Create a filtered lookup based on many criteria, using advanced find queries to specify the fields that display for selection of the lookup field and the filter criteria.