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.
How does it work?
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.
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.
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.