Written by Phil Weinmeister | Jul 01, 2014
The Entitlement Management feature is a bit of an outsider in the world of Salesforce.com configuration and development. While it’s likely that most of you familiar with the power of the Force.com platform have heard of Entitlements and Milestones, it’s probably a safer bet that you have not yet touched them from an administrative perspective yourself. Unless you are fortunate enough to have spare time to research different areas of Salesforce.com at your leisure, you’ll want to know that this topic is relevant to you and can bring potential value when building future solutions.
Here’s a quick test to see if that’s the case for you:
- Do you work with Salesforce.com Cases?
- Do you use Workflow Rules and corresponding actions in your solutions?
- Does your clientele or your organization require precise timing of automated system behavior?
You may be asking why there’s no mention of Service Contracts above, since Entitlements and Milestones are commonly associated with Service Contracts and, occasionally, Contract Line Items. There’s no question that you’ll want to take advantage of Entitlements and Milestones if the products or services you support have different levels of service, either per customer or per product. However, I’m going to look at Entitlements and Milestones from a different perspective here. They are actually quite analogous to Time-based Workflow Rules, but they have one huge advantage: timing granularity. I can’t overstate how valuable this is, but, hopefully, you’ll catch on after reading this.
Action Timing within Salesforce.com
Before I examine what’s so great about Entitlements and Milestones for Case Management, let me describe the shortcomings with related Salesforce.com functionality in regards to how asynchronous timing is handled. There are two areas of interest:
- Escalation Rules
- Time-based Workflow Rules (and Corresponding Actions)
There are two attributes in particular that I would like to contrast with Entitlements and Milestones:
- Minimum Duration Between Triggering Event and Corresponding Action
- Potential Variance in Expected and Actual Minimum Duration
Minimum Duration Between Triggering Event and Corresponding Action
The first attribute that warrants a comparison is the minimum amount of time between the event that “kicks off” an escalation rule or a time-based workflow rule and the action that it triggers. Take a look at how these three features compare:
The intervals speak for themselves. While you can only configure an action 30-60 minutes out with Escalation Rules and Time-based Workflow Rules, you can configure an action to occur literally one minute after the triggering event with Entitlements and Milestones. Simply put, that’s awesome.
NOTE: Case Escalation Rules can only trigger owner changes and email alerts; unlike Workflow Rules, they cannot drive automated updates of any fields other than Case Owner.
Potential Variance in Expected and Actual Minimum Duration
The disparity between these options is actually greater than what the chart above shows. The intervals of 60 minutes, 30 minutes, and 1 minute are what you configure for the corresponding actions. However, at least for two of the three options, they are infrequently the actual interval that occurs.
If you’re wondering what in the world I’m talking about, let me explain. A subtle, but critical, detail that you need to know about when considering declarative timing is Salesforce.com’s “batching” of pending timed actions. All is not as it seems when it comes to action timing.
Let’s say you create the following Case Workflow Rule:
Assume a new Case is created at 3:16 PM. You would assume that the action would occur at 4:16 PM, right? Well, think again. Salesforce.com executes these time-based actions only at certain hourly intervals, not in real-time as they are configured. Salesforce.com does not publish these times, but, based on my personal experience, they occur at the following times: :00, :15, :30, and :45. To be clear, those are exactly the times on the hour, not intervals from a relative time. That would be mean that this particular Case would trigger actions that would eventually fire at 4:30, 74 minutes after the event instead of 60. Again, this is not official information, but is what has been observed within Salesforce.com.
If you’re looking for a precise solution, count Time-based Workflows and Case Escalations out.
Setting up Entitlements and Milestones to Meet Your Action Timing Needs
Now that I’ve exhausted the topic of why to consider Entitlements and Milestones for Case-related automation, I will walk through how to set up each of the related elements. Navigate to Setup > Customize > Entitlement Management > Settings and check Enable Entitlement Management, if you haven’t already done so previously. Once you enable Entitlement Management, you’ll be presented with additional settings. For now, you can leave them alone:
You’ll need create your Milestone first. Navigate to Setup > Customize > Entitlement Management > Milestones and click on the “New Milestone” button.
Next, it’s on to Setup > Customize > Entitlement Management > Entitlement Processes. Click on the “New Entitlement Process” button. Leave the default values for “Case enters the process” and “Case exits the process.”
Once you set up the Entitlement Process, you’ll need to incorporate the milestone that you created. From the Entitlement Process page, scroll down to “Milestone” and click “New”.
Here, the Milestone is created with criteria of Status EQUALS New. This will result in the milestone being removed from the Case when the Status progresses past New, which is what you want. There is not a need for triggering an event based on meeting the milestone, just missing it. In this case, missing the milestone will result in an Email Alert and a reassignment. You will need to create those workflow actions after creating the Entitlement Milestone and associate them with Violation Action.
NOTE: You will need to consider Field-level Security settings for a slew of standard Case fields that are created automatically when you enable Entitlement Management. For this example, you will need to provide editability to the “Entitlement Name” Field, at the very least.
Create Your Entitlement Record
Since you’re not concerned with Entitlements and Milestones from a perspective of Service Contracts or Support Levels in this example, you will want the new Escalation process to apply to all records across the board. To make this happen, you’ll need to create an actual Entitlement (not Entitlement Process) record and then associate it with the Entitlement Process record you created earlier.
This use of Entitlements is an extension of the original intention of Entitlements and Milestones, so some of the fields don’t apply. Even one of the required fields (Account) has no actual bearing on how the functionality works. Here’s a condensed page layout with the key fields populated. The main fields you will need to consider are:
- Entitlement Name: Required. Make sure to populate with a meaningful description.
- Account Name: Required. This field is actually irrelevant for this example, but you must populate it. Select any Account.
- Entitlement Process: Set with the Entitlement Process that you created earlier.
- Status/Status Icon: Formulas, disregard during record creation.
- Start Date: Set to today or earlier to activate the process.
Case Page Layout Considerations
Each Case will need to be associated with an Entitlement record. This can be done via a simple before insert trigger that updates the Entitlement lookup field to the Entitlement record you previously created. You can also drop the field on the corresponding page layout and make it required to make this a manual step. This will ensure that the proper Entitlement is created each time a Case is created. Of course, if Cases are created through other interfaces, you’ll need to think through that, as well. A validation rule may also be helpful to ensure no Case is created with a blank Entitlement Name field. Overall, using a trigger is ideal, if that’s feasible.
Seeing Your Entitlement and Milestone in Action
Go ahead and Create a new Case. Whether you wrote a trigger to handle the Entitlement Name update on your Case or required entry via the UI, you will be able to see the milestone associate with your Case. Just make sure to leave Status = “New” when creating the Case:
Once you’ve created your Case, you’ll see the Milestone in the Case Milestones related list:
At this point, the Milestone will trigger the configured violation actions as long as Status is still “New”. Once Status is changed from “New”, the Milestone will be removed and no pending actions will exist. Note – if Status changes back to “New”, the milestone will reappear.
Your new Entitlement and Milestone are now in place and working. This Entitlement Process and corresponding Milestone will allow you to configured a timed action as few as 1 minute out from the triggering event. This is very impressive and useful functionality. Make sure to adjust the criteria, timing, and actions to meet your own needs when building this out.
For additional details on using Entitlement Management and other Salesforce.com practical development tips, make sure check to check out my book, Practical Salesforce.com Development Without Code, to be released around the end 2014.