Every now and then I like to use this blog to take our readers back to basics and visit parts of the Salesforce.com application that they may have overlooked. Today's topic is none other than good old Auto-Response Rules.
Auto-Response Rules are a type of workflow that are available on Case and Lead. Broadly speaking, their function is to generate an email automatically in response to an incoming contact from a customer. They are often used in conjunction with Web To Case, Email To Case, and Web To Lead.
The great thing about auto-response rules is that they can automate that first response to the customer and provide that customer with a branded, professional-looking email that makes that customer feel that he has been heard. There can sometimes be a bit of confusion around when to use auto-response rules and when to use workflow email alerts. It can be fairly said that you can accomplish some of the same things with both. Auto-response rules have workflow-esque criteria, and like an email alert, they generate an email based on an email template. In some ways, workflow email alerts are more powerful in that they allow you to choose who to send the email to from a list of people who are related to the object, whereas auto-response rules only email the Contact on the case or the email address of the Lead.
Indeed, they are much alike, but auto-response rules are specially tailored for the use case of the first response to a customer contact, and they do have two very powerful features to that end. First of all, auto-response rules are processed sequentially, whereas workflow rules are processed in parallel. What does this mean?
Let's say I have two levels of support, Premier and Basic, and two products, Product A and Product B. If a Premier Support customer creates a case, I want to email him back with my Premier Support template, from my Premier Support email address. If the customer is Basic support, however, I want to send him an email from Basic Support using a template that differs by product.
If I were to try to model this using standard workflow rules, I would end up with at least 3 different rules, and with a convoluted set of criteria to ensure that I don't end up sending the email multiple times. Auto-response emails are different, though -- because they're processed sequentially, they are guaranteed to send at most one email. An auto-response rule will try each rule entry in sequence until it hits some criteria that matches, and it will send the email from that rule entry and stop processing the remainder of the rules. Here's how my auto-response rule might look in this example:
While it can seem at times that workflow email alerts and auto-response rules are identical, use cases like this one illustrate the differences. Happy emailing!
The case accept button is a handy thing. It shows up on queue views to allow members of that queue to mass-accept cases (actually, in the Agent Console it shows up in the Mass Action dropdown rather than as a button, but it works the same). If you have a large queue, though, with lots of agents accepting cases at the same time, they may sometimes step on each others' toes. If two agents accept the same cases at almost the same time, then the last one will win, and the first agent will not actually own the cases he thinks he just accepted.
Here's some custom button code I wrote which addresses this issue. It only accepts cases that are still assigned to a queue; if the cases have been accepted by a user already, those cases will remain owned by the users who accepted them.
To add this code, go to Setup->Cases->Buttons and Links and make a new custom button called Accept Cases (or whatever label you'd like to use for this). Its Display Type should be set to List Button, its Behavior to Execute JavaScript, and its Content Source to OnClick JavaScript. Paste the code from this link into the OnClick JavaScript field.
Now you'll have to add this button to the Case list view. To do this, go to Setup->Cases->Search Layouts. Click Edit next to the Cases List View entry, and add your new button from the Available Buttons section to the Selected Buttons section.
So how did I do this? Quite easily really. Perhaps the most important part is the line that invokes {!GETRECORDIDS($ObjectType.Case)}. This little-known merge field allows you to get a list of all the IDs that are selected in a list view or related list -- really handy when you're trying to make buttons that act upon a large number of records. Once I have the IDs of the selected records, I run them through the also little-known retrieve function to get more information about them. The key to that retrieve call is getting Owner.Type -- that will return a string for each case containing either "Queue" or "User" depending on what the type of each case's owner is. A good lesson here is that GETRECORDIDS plus retrieve makes for a quick and powerful combination.
Now I divide the cases into two piles: the "accept" pile for cases that are currently owned by a queue that we're going to allow this user to accept, and the "reject" pile of cases that have already been accepted by other users. If there are any cases in the "accept" pile I call update on it to update those cases, and then I give some feedback to the user of the changes that were made (and the changes that were rejected). And there we have it: The Contention-Proof Case Accept Button. Note that with just a couple of minor changes you can adapt this same code for use with leads and custom objects -- any object that is ownable by a queue.
Today I needed to turn off the Interaction Log in the Service Cloud Console. It was remarkably hard to figure out how to do so! As such I thought I'd document it here.
Interaction Logs are enabled on a per-page layout basis. As such, you'll need to edit each page layout to turn them off. To do so, edit the page layout of a primary tab object (in my example I'm using Contact). You'll find a button called Layout Properties at the top.
Click that button and you'll find a place where you can turn off the Interaction Log.
Press OK. Don't forget to press Save on the page layout!
Now go back to the Console. If you already had a contact open (or whatever object you were editing the page layout of), you may find that it still has the Interaction Log on it. Don't be alarmed -- just close that tab and reopen it. Any new object of that type will be rendered without the Interaction Log.
Bonus for advanced users:
If you've got lots and lots of page layouts and you don't want to go through all of them turning off the Interaction Log for every one, use the Force.com IDE instead. Set it to download all the relevant page layouts. Then do a find-and-replace across all files for:
<showInteractionLogPanel>true</showInteractionLogPanel>
And change it to:
<showInteractionLogPanel>false</showInteractionLogPanel>
Now save them all, and voila, the Interaction Log is off in all your layouts.
The original version of this blog post comes courtesy of guest blogger and all-around Salesforce.com guru Jay Thayer (I've since modified it to apply to the new Report Builder).
Let's say you're trying to build a common report, Cases By Origin, but with a twist -- you want to know what percent of your interactions are coming via each channel. Well, you could build a dashboard with it and eyeball it, but that's not very satisfying -- sometimes you just want cold, hard numbers. The good news is that there is in fact a way to do it using some little-known capabilities of custom summary fields.
First, start by making yourself a standard Cases By Origin report by creating a custom report. Search for the report type simply called Cases -- we don't need any related objects for this report. Next make it a Summary Report by choosing that as the Format:
Now drag the Case Origin field onto the "Drop a field here to select a grouping" header. This will group your cases by origin, so we're nearly there.
On the top of the left hand side you'll notice an Add Formula icon. Drag that right on top of your Case Origin grouping (in the blue area).
This type of field will allow us to do math using both a summary of the group items and a summary of the whole report -- that's exactly what we need to calculate our percentages. First, at the top of the page, give the formula field a name, and set its Format to Percent. Now set it to display at Grouping 1: Case Origin, because that's the granularity at which we want this calculation to occur.
Now let's go to the formula builder and build it up. In order to calculate the percentage for each group, we need the record count for that group, and then we have to divide that by the total number of records in the report. To get the record count for the group, we use the handy-dandy Summary Fields > dropdown, where you'll find that the top item is called Record Count. That inserts an item that says "RowCount." That was easy enough.
Now we have to divide that value by the record count of the entire report. For that, we can use one of the Custom Summary Functions -- to view them all, click the Functions dropdown. Here we see a function called PARENTGROUPVAL. This is exactly what we need, because in this case the parent group is the entire report. Our only grouping summary is Grand Summary, which is fine because that's what we want.
Double-clicking PARENTGROUPVAL adds the following to our report:
PARENTGROUPVAL(summary_field, GRAND_SUMMARY).
Now we just have to select the summary field. Select that "summary_field" part of the above, and replace it with RowCount, so it says:
PARENTGROUPVAL(RowCount, GRAND_SUMMARY)
So your final formula should read:
RowCount/PARENTGROUPVAL(RowCount, GRAND_SUMMARY)
That will divide the rows in the current group by the rows in the entire report. The completed formula field should look like this:
Save your custom summary formula field by pressing OK, and proceed with the report wizard as usual, selecting and ordering your columns and entering criteria. When you run the report, you'll see that it's grouped by Case Origin, and each group is tagged with the percentage of total cases that came from that origin: Eureka!
