Service and Support Blog
Service and Support Blog
-
Assigning Cases According To The Email Address From Which They Originated
Oct 21, 2009A customer asked an interesting question recently, which was:
I have multiple email addresses that correspond to different divisions of my company. How do I assign cases to these various divisions according to which email address the original email arrived at?
This seemed at first to be a bit of a head-scratcher, since the email address itself is not stored anywhere on the case. However, there is a simple solution: use Case Origin.Case has a field called Case Origin which can be set on a per-routing-address basis. Our first step, then, will be to set up our Case Origin field to contain the necessary items pertaining to each division. Let's say, for the sake of this blog post, that I'm setting this up for my Customer Service and my Billing divisions.
Go to Setup->Customize->Cases->Fields, and click the Case Origin link:
At the bottom of the page you'll find the Picklist Values. Press the New button to add some entries to this list (note that you can add more than one at a time by separating them with a linefeed). Having done that, I now have:Now I go over to Setup->Customize->Cases->Email-To-Case. I click on the Edit link for my Support routing address:
At the bottom of the ensuing page, I can set the Case Origin for this routing address:
After saving this, I now have a field on Case which records which email address it was created from! I can now use that in my assignment rules, like so:
And that's all there is to it.Oh, and one more thing: if your process requires that you use record types on cases, you can do the exact same trick with the Case Record Type field instead.
-
Case Hierarchy: Divide A Complex Case Into Simpler, Smaller Child Cases
Aug 27, 2009In last week's blog post I described how to set up a case hierarchy. As I discussed in that post, a case hierarchy can be a very powerful tool to manage sets of related cases.
In last week's post I gave the example of a case hierarchy that represents a new hire coming on board, where we create child cases for each of the items required to onboard that employee:
In this type of hierarchy, the parent case is really just a shell -- no one is specifically working the parent case, but individuals will be working the children cases. A useful automation here, then, would be a trigger which synchronizes the parent case's status to the statuses of its children; that is, the parent will be closed only when all its children are closed; and as long as any child cases are open, the parent will remain open as well.
In fact it is fairly trivial to write such a trigger. I have posted some sample code for a trigger like this, complete with a test method, on this page at the Developing With Service & Support Quick Start Wiki.
While you're over there, if you haven't seen it, take a look at the broader Developing With Service & Support Quick Start Wiki page. It's chock-full of great sample code for Service Cloud users, and we keep adding more to it.
As usual, please direct any questions or comments about this sample code to the General Development discussion board.
-
How To Set Up A Case Hierarchy
Aug 20, 2009Well, I'm 36,998 feet over Wyoming right now using some airborne Internet service -- what better time to write a blog entry?
It is perhaps a little-known fact that Salesforce.com has a built-in notion of a case hierarchy. Little-known, I say, because it is hidden by default, and many admins don't expose it because of that. A case hierarchy can be a very useful thing, however -- it allows you to associate related cases together, of course, but in this day and age of Apex Code, it can also allow you to create some handy automations. This is the first of a few blog posts I'm going to publish in the next couple of weeks that will demonstrate how to set up the case hierarchy and some useful things you can do with Apex to take advantage of it.
Today's post will cover the basic setup of a case hierarchy. There are a number of use cases for this type of functionality. For instance, let's say you're running your IT helpdesk on Salesforce.com, as many organizations do, and a new employee is joining your company. You might make a parent case called "New Hire Setup," with child cases for "Setup Phone," "Setup Computer," "Network Access," "Badge," and so on. This allows you to represent all the steps necessary to set up this new hire in a single place.
First things first: before using the case hierarchy, we must expose it. By default in many orgs, the Parent Case field is hidden by field-level security. To unhide it, go to Setup | Customize | Cases | Fields and click on the Parent Case link under Case Standard Fields. Click the Set Field Level Security button:
And on the subsequent page, set the field to be visible for some or all profiles.
Now, while we're at it, let's add the related list to the Case page layout that shows the child cases. In Setup | Customize | Cases | Page Layouts, edit one or more of your case page layouts to add the Related Cases related list:
Once you've saved your page layout, you're ready to go -- you now have a functioning case hierarchy.
Now let's set up some cases like the example I gave above. When setting up child cases, the New Case button on the Related Cases list can be useful, particularly the "Copy Parent Details" button, which basically clones the parent case but makes it a child:
And now we have our related set of cases for this new hire:
Next week, we'll look at some Apex Triggers that we can add that will automate some common processes.
-
Manage Your Entitlements and SLAs With The Service Cloud
Aug 6, 2009A common need among customer service organizations is the ability to manage entitlements (otherwise known as "service contracts" or "warranties") and service level agreements (or SLAs). It is perhaps a little-known fact that there has been a free application on the AppExchange for some time called Entitlements which allows you to do just that.
The Entitlements application, published by Force.com Labs, allows you to manage your customers' entitlements and enforce the service level agreements (or SLAs) that derive from those entitlements.
This package supports two models of entitlements:
-
- You can create Support Programs and Entitlements for each individual account, or
- - You can create just a few different support contracts (like Standard Support and Premium Support) and share them across many accounts.
These two models can coexist.
For example, let's say that Acme Company offers 2 support options: Standard Support, with an 8-hour SLA, and Premium Support with a 2-hour SLA. They do not write separate support contracts for each customer, and they do not have the notion of named callers or named assets. The model that would be best for them would be to make two Support Programs, one for each type of support, and have each account look up to the correct support program according to its support level.
Now let's say that Beta Company offers different support contracts to each customer, with named callers, and where those callers could only call about certain assets. The one-support-program-per-account model would be right for them.
Once an entitlement is applied to a case, Entitlements allows you to track three different SLAs:
- - Entitled First Response
- - Entitled First Workaround (which some companies use to track the time when they sent the customer the resolution to the problem)
- - Entitled Resolve Time (which is fulfilled when the case is closed)
For the Entitled First Response and Entitled First Workaround times, there are corresponding Actual First Response and Actual First Workaround fields that track when these SLAs were fulfilled. When an email is sent from the case or when a call is logged on the case, a trigger will automatically populate the Actual First Response field. If you choose to use the Workaround SLA capability, a button called Stamp Workaround Time is included to stamp a time in the Actual First Workaround field. If there is a way by which you can automatically determine that a workaround has been sent (by case status, for example), you may choose to create a Workflow Field Update that stamps this field. The Actual First Response and Actual First Workaround fields are both available for updates from both the Workflow engine and Apex code if you wish to add additional means of autopopulating them.
These SLA times are calculated using the set of Business Hours that is associated with the case. That means that if you have an SLA of 2 business hours and someone files a case over a holiday weekend, the SLA times will be stamped on such that it jumps to 2 hours into the next available business day (provided you've defined your business hours and holidays in Salesforce.com setup -- that will be the subject of a future blog post).
Once these SLA times have been calculated, the times that the SLAs come due are stamped directly on the case. This means that you can, for example, create a list view sorted by which SLAs are coming due the soonest, or report on cases where the SLA has been violated.
The Entitlements application is available on the AppExchange at no charge. It is compatible with Enterprise and Unlimited Editions of Salesforce.com, and it can be installed from this page.
-
- You can create Support Programs and Entitlements for each individual account, or
-
Service Cloud Basics: Auto-Response Rules
Jul 16, 2009Every 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, 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 (click for full-size image):
The second benefit of auto-response rules is that you can set the From address on them, something you can't do with workflow email alerts. That can be handy to ensure that if the customer emails you back, it doesn't go directly to a person, but to an Email To Case or Email Services inbox instead.
If you're not using auto-response rules to send the first response to your customer contacts, you're missing out! You can set up auto-response rules for Cases by going to , and for Leads at .
-
A New Connect for Outlook Feature For Service Cloud Users
Jul 9, 2009Today's blog post is about a new little checkbox that goes a long way.
Connect for Outlook is Salesforce.com's plugin for Microsoft Outlook. Today we'll look at a new feature introduced in version 3.3.102 of Connect for Outlook which can be very beneficial to those using Salesforce.com for customer service management.
Among its many benefits, Connect for Outlook allows you to create cases directly from an email in Outlook just by clicking the handy "Add Case" button. This has been true for some time:
When you press the Add Case button, you get a window that allows you to add the case and associate it with a contact, like so:
Pressing Add to Salesforce will add this case, using the subject of the email as the subject of the case and the body of the email as the case's description.
The new and very useful feature in the latest version of Connect for Outlook is the ability to auto-assign the case you create using the standard assignment rules:
This little checkbox can make it much easier to make a case that is automatically sent to the right user or queue, and makes Connect for Outlook much more suited to Service Cloud users.
Connect for Outlook is available to users of Personal, Group, Professional, Enterprise, and Unlimited Editions. To download the latest version of Connect for Outlook, click .
-
New in Summer '09: New Portal Administration Capabilities
Jun 25, 2009Since the Customer Portal was introduced back in Summer '07, we've seen enormous uptake of it. As our customers have picked it up, they've been asking us for the ability to manage their portal users better. I'm pleased to say that we've provided a lot of that with the Summer '09 release.
Note that the new features listed here apply to both the Customer Portal and the Partner Portal.
Disable Customer Portal User
Until now, once a contact was made into a Customer Portal user, it was effectively "locked" -- it couldn't be merged or deleted. The Customer Portal user associated with it could be inactivated, but that's about all that could be done with it.
With Summer '09 we've introduced this handy-dandy button to the Contact page:
This button disables the Customer Portal user for a contact. This means that the Customer Portal user gets inactivated, but also that the contact becomes unlinked from that user, which means that you can now treat it like a normal contact. You can delete it, merge it, and generally have your way with it.
Disable Portal Account
In addition to disabling a single contact, you can also disable an entire account's access to the Customer Portal. By pressing the Disable Customer Portal Account button, you can disable the account for the portal and as many as 100 Customer Portal users in that account all at once (if you should have more than 100 Customer Portal users under that account, we recommend that you disable the contacts' Customer Portal users separately).
When you enable an account for the Customer Portal, Salesforce.com automatically creates as many as 3 roles in the system that represent this account. Disabling the account will also delete these autocreated roles.
Transfer Portal User Accounts
As I mentioned, in the past, contacts who were associated with portal users were "locked," and one aspect of that locking was that you could not change the account associated with them. This is no longer the case -- you can now transfer their accounts with impunity just by changing the Account Name field.
Merge Customer Portal Contacts
Let's say you have a contact with a Customer Portal user called Jim Smith, and someone goes and adds a duplicate Jim Smith contact. In the past, because of the aforementioned locking, you would be unable to merge the two contacts; however, now you can merge them like normal accounts, using the Merge Contacts button from the Contacts related list on Account.
You can find the full details of these and all the other Summer '09 features in the Summer '09 Release Notes. Hopefully the features I've described today will help you keep your Customer Portal a well-oiled machine.
-
New in Summer '09: Email Alerts For Case Comment Workflow
Jun 18, 2009Back in Winter '08 we turned on Workflow from Case Comments. That workflow allowed you to perform a field update on the parent Case. Because it is a "chaining" workflow, that means that you could send email alerts or outbound messages by creating another workflow on the parent case which would receive the changes from the Case Comment workflow and react to them. It was a little bit convoluted, but it worked.
Although having a field update capability from Case Comments was useful, many of the use cases for Workflow From Case Comments involved sending emails. As of Summer '09, you can send emails directly from a Workflow From Case Comments. Here's an example of how.
Let's say that I want to create a workflow which, whenever a new comment is submitted to a case, notifies the case team of that new comment.
My first step is to create the workflow rule:
I want any case comment to trigger this workflow, so I'm going to set my criteria to fire whenever a comment is created, and whenever that comment has anything in the body:
In the next step, I can now create an email alert:
Before finishing up this email alert, though, I'll want to make an email template that contains the body of the comment. The {!Case.Last_Case_Comment} merge field is really handy for this:
Finally, I can make my email alert. I want to set it to notify members of the Case Team where their role is Support Staff:
And that's all there is to it! Once I go back to the the workflow rule and click Activate, this workflow rule will fire whenever a case comment is added, notifying the Support Staff members of the case team with an email containing the comment body.
-
New In Summer '09: Salesforce to Salesforce for Cases!
Jun 11, 2009I'm plagiarizing a bit from my esteemed colleague Adi Kuruganti, but I have to trumpet this little nugget -- it's a key addition to the Service Cloud feature set. With Summer '09, specifically as of June 24, 2009, you will be able to share Cases and Case Comments via Salesforce to Salesforce. What this means is that if both you and a partner are using Salesforce.com for customer service, then you can share cases with that partner, and Salesforce.com will ensure that the data remains in sync.
For example:
I have a smartphone issued to me by my company's IT department, and our IT Helpdesk uses Salesforce.com to provide support to our employees. Now let's say that the mobile phone company we use also uses Salesforce.com for their customer service & support. When I have a problem with my phone, I can file a case with IT, and my IT can share that case directly with the mobile phone company using Salesforce to Salesforce. As the mobile phone company works the case, changes its status, and adds data and comments, the corresponding case in my IT Helpdesk will automatically receive those updates and comments. At the same time, my IT department can also collaborate and act on the case, and anything they do with it (any data that they choose to share, at least) will be automatically synced to the mobile phone company's case management system.
We have also posted a video demonstration of Salesforce to Salesforce for Cases for your edification.
Best of all, Salesforce to Salesforce is free to all customers -- it's just another thing that's included as part of the platform.
As I mentioned earlier, this feature will be enabled on June 24, the date on which all of our instances will have been upgraded to Summer '09. Salesforce to Salesforce is an incredible collaboration tool, the kind of thing you can only do with an on-demand system, and I hope to see many of you making use of it soon.
-
Service Cloud Basics: Web To Case
Jun 4, 2009It's been a little while since my last blog post -- I've been out speaking with customers about the Service Cloud. What better place to write a blog post, though, than on a plane? That's right, I'm writing this missive from 38,060 feet over Wisconsin on a Virgin America flight with Wi-fi. How about that!
People often ask me about Web To Case -- how it's used, what it can do, and its limitations. I thought I'd take a moment today to discuss it.
First, let's start with the basics.
What is Web To Case and how does it work?Web To Case is a means by which you can post a simple, unauthenticated web page that allows your customers to submit cases directly to your Salesforce.com instance. This means that you can post a public case submission page on your own website with your own branding and styling.
In a nutshell, Web To Case works by generating for you a snippet of HTML. This HTML is a good old-fashioned HTML form that you can put on any page. When your customer presses Submit, the information on this form is posted directly to a Salesforce.com server, which handles the information, converts it to a case, and redirects the customer's browser back to a page of your choosing.
Setting up Web To Case requires a couple of steps; rather than regurgitating them all here, I will refer to the excellent documentation on the subject.
When your customer posts a case via Web To Case, a few fields are generally required, namely the name and the email address. These values will be stored in the newly created Case in the Web Name and Web Email fields. If that email address happens to be associated with a Contact in your system, then Web To Case will automatically associate that case with the contact who has that email address, and with the account associated to that contact. If that email address is not found, or Web To Case discovers more than one contact with that email address, then Web To Case will not know which contact to associate to the case. In that instance, it will leave the Contact and Account fields on the case blank and allow you to fill them (which you can generally find using those Web Name and Web Email fields).
What is Web To Case useful for?
Let's say that you're doing a lot of support by email. Emails are an unstructured medium, so even if you're automating the process with Email To Case, someone generally still has to look at the cases to classify them -- it's not easy to perform workflow on plain text. Web To Case allows your customers to submit the information directly into the individual fields on your case, so you can perform a great deal of automation, like workflow, assignment, and auto-response rules, immediately. That can save you a lot of man hours.
Meanwhile, Web To Case is a very quick way to put up a web form to accept cases. You can generally have a quick-and-dirty page up in minutes, and because it's standard HTML, it's easy to embed into an existing page.
What are Web To Case's limitations?
First, Web To Case is limited to receiving 500 cases per day. This is to keep things like spambots from beating up your org (and beating up our servers). Speaking of spam, Web To Case does not perform any spam filtering. You could use workflow to filter out cases that appear to be spam, but Web To Case itself does not apply any particular intelligence -- it just takes the cases.
Web To Case cannot handle attachments. This is a side effect of the simplicity of its setup, and of the simple transactional nature of HTTP. Taking attachments via the web is a remarkably complicated process. For instance, try attaching a document in Gmail. You'll notice that you first have to browse to a file; it posts that file immediately to the server. In the background, it associates your in-progress email with the file it just posted, so that when you finally go to send the email, it knows which attachments go with which email. So there are two posts involved here, plus a fair bit of backend logic. Web To Case, on the other hand, is a simple form with a single post that you can embed anywhere. Attachments don't play nice with that.
Out of the box, if Web To Case does not find a contact to associate a case to, it will not autocreate one. However, a previous blog post discusses how, with a simple Apex trigger, you can set your org up to do so.
Finally, Web To Case is solely a tool for the initial submission of cases. If your customers need to be able to track their cases, or add information to them after the initial submission, then you'll want to look into the Self Service Portal or the Customer Portal -- those are authenticated products that allow your customers to file cases, but also to follow up on them, browse the knowledge base, and in the case of the Customer Portal, lots of other things as well.
How can I work around the volume and attachment limitations?
If you need to take more than 500 cases per day, or you want to be able to take attachments, you can now do so using Salesforce.com's facility for unauthenticated access called Force.com Sites. You can find a quick start here on how to create a custom Web To Case form using Sites.
Bookmark