Rule Type Sales Service
Trackers
  • Customer reward points
  • Sales Revenue by Account/Salesperson
  • Excess Discount
  • Satisfaction Level by Account/Service Rep
  • Number of Escalations by Account/Service Rep
Escalation
  • Task escalation
  • Case Escalation
Object Creation
  • Lead - auto create from incoming e-mail
  • Case – auto create from incoming e-mail
Alerts
  • Opportunity Size
  • Lead Assigned
  • Case Opened
  • Case Assigned
  • Service Scheduled
Time based Reminders
  • Tasks Approaching Escalation
  • Birthday Reminders for Contacts
  • Opportunity Aging
  • Cases Approaching Escalation
  • SLAs Approaching Renewal
  • Case Aging
Audit Trail
  • Changes to Opportunity Estimated Close Date
 

Setting a Tracker

A tracker is simply a number-based attribute on an entity that captures important information related to that entity. Trackers can be useful for tracking key number-based targets that are important to your business. After the trackers are defined, they can be compared to certain values in order to trigger a predefined business logic or to generate alerts. You can use existing attributes on an entity as trackers or you can create custom attributes to do that based on specific needs.

Example: Reward Point Balance for Account

A certain organization using Microsoft CRM 3.0 would like to reward their customers for large purchases and repeat purchases. One way to reward these customers is to accumulate all the purchases made by a certain customer as reward points. After the reward points exceed a certain threshold value, the customers can be sent a gift card equivalent to a certain dollar amount. The organization would also like to reduce the reward point balance by the same threshold value to compensate for the reward. The system would continue to monitor reward point balances. When the threshold value is exceeded again, the same process is repeated.

To set up the above scenario, you can do the following:

  1. Create a custom attribute of type int on the Account entity, and call this attribute, for example, Reward Balance. Add this custom attribute to the main form under the Details tab and publish the customizations. Open an existing account record to ensure that the field shows up in the UI.
  2. Open Workflow Manager and create a workflow rule on the Invoice entity with a trigger on a Change Status event. This trigger adds to the reward balance on a related account by total invoice amount each time the invoice status changes to paid. Save the workflow rule you created. The rule definition in Workflow Manager would look similar to the following:
  3. Define one more workflow rule on the Account entity with a trigger on a Manual event such that it waits for the reward balance to exceed 10,000 points and creates a task to send the customer a gift card for $100 dollars. This rule waits for the task to get completed. After the task is completed, the rule reduces the reward point balance by 10,000 points. The rule definition in Workflow Manager would look similar to the following:
  4. Open the rule again, and add a subprocess action at the end that calls the same rule again. This makes the rule recursive so that it never stops waiting for reward points to exceed the target. The rule definition in Workflow Manager would look similar to the following:
  5. Define one more workflow rule on the Account entity with a trigger on a Create event such that it calls the “Evaluate Reward Balance” rule defined in step 4. This ensures that each account, at its creation and throughout its life cycle, has the reward balance tracking enabled.
Notes:
  • Note the use of dynamic text fields in step 4.
  • You can add escalation rules on the task created under step 3 so that, if the task is not completed within a specified time, for example, by the due date, an escalation mail is sent to the owner’s manager.
  • Similar trackers can be created on other entities within Microsoft CRM 3.0, including custom entities, based on business needs. An example would be to track the cumulative revenue won by a salesperson and reward him whenever the salesperson’s revenue exceeds a reference value, while updating the reference value upwards by a fixed amount in order to create perpetual tracking for each salesperson.

Setting up Escalations

Escalation is a way to enable pre-defined action if certain things are not completed within a pre-defined time. 

Example: Case Escalation 

A certain organization using Microsoft CRM 3.0 would like to ensure that all cases logged into the system are processed in a time bound manner. Each time a new case gets created, it gets assigned to a specific owner (using a workflow rule). The owner is expected to complete a set of actions. The owner is expected to update the status of the case to reflect level of completion. Case moves through multiple status codes till it is completed. The organization wants to enable a rule where if a case remains in the same status for more than 1day then it should be assigned to do a different person. The organization would further like to ensure that if case remains in the same status for more than 2 days than it should be re-assigned to a different person again (say Person Y). 

To set up the above scenario, you can do the following: 

  1. Create a .NET assembly (workflowtestassembly.dll) with following echo function:
    public int EchoPicklist( int value )

      {

            return value;

      }

  1. Add the following entry to workflow config file: 

<method name="Echo Picklist"

            assembly="workflowtestassembly.dll"

            typename="workflowtestassembly.Test"

            methodname="EchoPicklist"

            group=" Utilities">

           <parameter name="Status Reason" datatype="picklist" entityname="incident" attribute="statuscode"/>

           <result datatype="picklist" entityname="incident" attribute="statuscode"/>

            </method>

  1. Open Workflow Manager and create a workflow rule on the Case entity on a Manual event. Create a condition to check if the case is already “closed”. In that case, no further processing is required. If the case is not closed then define an echo function (using “Call Assembly” action under “Insert Action” drop down) called “Pre-Update Status Reason” and set it equal to the “Status Reason” attribute on Case entity. This will capture the current value under status field. This value is saved in a temporary field allowing us to compare it with value in status field at a later point in time. The rule definition in Workflow Manager would look similar to the following:
     
  2. Continue editing the rule. Add a wait condition for 1 day and compare the value in echo function with the current value in Status Reason. If value is same, that means that case status has not changed within last 1 day. Assign the case to person X.
     
  3. Continue editing the rule and add another wait condition for 1 day and once again compare the value in echo function with the current value in Status Reason. If value is same, that means the status of the case has not changed within last 2 days. Assign the case to person Y. Save the rule.
  4. Open the rule again, and add a subprocess action at the end that calls the same rule again. This makes the rule recursive. The value of echo function gets compared to the current value in Status Reason attribute of Case entity on a daily basis. The value in echo function gets replaced daily if the value has changed else it changes after 2 days.
  5. Define one more workflow rule on Case entity with a trigger on a Create event such that it calls the “Escalation Rule” defined in step 6. This ensures that each case, at its creation and throughout its life cycle, has it’s status checked on periodic basis and is escalation to the right person, as and when required.
     

Notes:

  • The escalation interval enabled via this process is bucketed. That means that if the value changes within the wait interval the system does not count that time. If you need to be more precise about the wait interval, then the trick would be to define multiple wait conditions with smaller time intervals.
  • If you need guidance on creation of .NET assemblies, refer to SDK documentation.