Service and Support Blog

Email-to-Case Best Practices - Part 2: Things to Consider

Guest blogger and Customer Service & Support expert Peter Aubrey continues his thread on Email To Case. Today we feature part 2 of the 2-part series Email-to-Case Best Practices (see part 1 here):

In order to identify the best way to setup email-to-case, it’s best to get a good understanding of exactly how the agent works. You will also need to make a decision on the communication strategy with your customers. Some customer service departments allow agents to give out direct email addresses or direct dial numbers. Others only allow customers to contact the agents via central support email or telephone numbers. Some companies have a mixture of both.

Email-to-case will of course only take email from specific mailboxes that are dedicated to receiving email related to customer support issues. If a customer sends an email directly to one of your agents then the agent can manually add those emails into Salesforce using Force.com Connect for Microsoft Outlook. Salesforce can be configured so that agents can send emails with a variety of From addresses, thus ensuring, for example, that all responses from customers arrive at the central mailbox which email-to-case is polling.

If the majority of the time you want your agents to send emails from a central support address, then each agent needs to modify his Email Settings by going to Setup: Personal Setup: Email: My Email Settings and setting his Email Name and Email Address to the required central support address.

When an agent sends an email from a Case, he gets the choice of sending the email from a number of email addresses. Salesforce will default to the settings specified by the agent in his email preferences, however he also gets the choice of setting the from email address on the email to either their user record’s email address or any Routing Addresses that have been defined in your email-to-case settings.

You can create a custom button that defaults the From address on the email page; for more on that, see this earlier blog entry: The Quick Email Button.

How are emails linked together to form a conversation?
When an agent sends an email from the Case page a special ID is created and added to the subject line of the mail so that a chain of mails can be uniquely identified as a conversation.

However, this conversation ID is not created until an agent manually replies to the original email, an Auto-Response email does not include this unique ID. Therefore if a customer responds to the Auto-Response mail then a new Case will be created since the unique ID is not included in the subject line of the email.

This can be overcome in one of two ways.

1. Do Not Reply
Some of our customers set the sender’s name and email address to “Do Not Reply” addresses, along with a warning in the response saying not to reply to this automated email.

Note you could set up another email-to-case agent that monitors this email inbox to handle any emails are sent to the do not reply address.

2. Create the ID using a Formula Field
The following formula field will calculate the thread ID, which is unique to each case. This thread ID can then be added in to the Subject line or the body in your email template to make sure the ID is set even when an agent does not manually respond to the customer.

Click here to see the formula that synthesizes the thread ID. In the screenshot below, we've stored this formula in a custom field called "Case Communication ID" and added it to the subject line of our autoresponse template.

Note: if you use web-to-case then this technique can also be used to catch any immediate responses that customers may send to your support department, before an agent can respond.

So in summary:

1. Customer sends an email to support@yourcompany.com

2. Email-to-Case agent picks up the email and:

a. Searches Salesforce to see if a Contact exists with an email that matches the from address of the inbound email.

b. If a match cannot be found, or if more than one Contact is found, then the name and address contained in the email are stored in the Web Name and Web Email fields on the Case when it is created. If a match is found then a Case is created and linked to the Contact and its corresponding Account.

3. The appropriate Auto-Response Rule in Salesforce responds immediately with a message detailing Case Number, Subject, estimated response time, customer portal login link, suggested solutions, etc.

4. Assignment Rules evaluate the Case details and either places the Case into the correct queue or gives ownership to the correct individual.

5. The Case Queue members or the individual to which the Case was assigned are notified via email that they have a Case to work on.

6. Agent takes ownership of the Case and replies to the original email explaining that they will be working on their Case going forward. Note that when the agent replies to the original email, the Open Task that was created is automatically closed.

The Magic of the Gartner CSS Magic Quadrant Highlights Dreamforce

Once again, Dreamforce was the highlight event of the season for Cloud computing and customer service and support, with over 34 speakers presenting their success in delivering game-changing solutions for customer service and support using salesforce.com. One of the most exciting events was the presence of Michael Maoz, Gartner analyst, and thought leader, whose vision and insight into the challenges and trends in customer service drew a standing room only crowd to the kick-off of the Customer Service and Support track.

Read more about Michael’s experience at Dreamforce, as well as his ongoing dialog about the how to respond to the challenges you face every day at his blog: Dreamforce demonstrates salesforce.com innovation in cloud computing.

Email-To-Case Best Practices -- Part 1: The Basics

People sometimes ask me whether Salesforce.com has an automated solution for turning emails into cases. The answer is yes! We've had one for years, and I'm not talking about Outlook Edition.

Guest blogger and Salesforce.com Service & Support expert Peter Aubrey has written up a primer on Email To Case and what it can do for you. Here we have it:

Well, what a few days. Dreamforce was a fantastic experience where customers, partners and some of our most experienced employees shared ideas, best practices and generally showed how you can squeeze every dollar of ROI from your Salesforce implementation.

One question that came up during the “Roundtable with the Service and Support Pros” session and one that comes up frequently in conversations I have with customers is what is email to case and how do I use it? Well lets see if I can shed some light on this subject.

What is email-to-case?
Email-to-case is a small Java application that can run on any server, desktop or laptop PC. It is used to connect to an email mailbox on a periodic basis, process any email messages that are currently there by taking the details of the email and creating a Case in Salesforce. Think of it as like any email client application such as Outlook, Lotus Notes or Thunderbird, it just doesn’t need anyone to operate it!

If a Contact in Salesforce has the same email address as that in the from address in the email, then the email-to-case agent will link the Case to the Contact automatically.

If a Contact cannot be found then the details of the sending email are stored in Web Name and Web Email fields on the Case.

What email servers and mail protocols does email-to-case work with?
Email-to-case uses IMAP as the email protocol to communicate with your email server so it’s not a question of does email-to-case work with Microsoft Exchange, but does your mail server support the IMAP protocol.

Exchange, Lotus Notes (Domino) and many other email servers are able to be configured to use the IMAP protocol, however this may not be enabled by default. Also many web based email services such as Google support IMAP, which is what we’ll be using in our examples below.

Can email-to-case use IMAPS?
Yes. Simply state that the mail protocol as IMAPS and the port as 993 in the email2case.txt configuration file.

How do I stop Spam?
Email-to-case does not provide any SPAM checking. It is assumed that customers will provide SPAM filtering capabilities before they reach the email-to-case agent.

Where do I download and setup email-to-case?
To download click here: http://wiki.apexdevnet.com/index.php/Members:Email_To_Case

For instructions on how to setup see the Help files in Salesforce.com.

Where do I get help and support?
1. Search for "Setting Up Email-to-Case" in Salesforce.com's help files.
2. Search for "email-to-case" in the Community discussion forums found here http://www.salesforce.com/community/community/
3. http://wiki.apexdevnet.com/index.php/Members:Email_To_Case
4. If all else fails, you can contact Salesforce.com Support.

Can I have more than one email-to-case agent running at the same time?
Yes. You can have as many agents running at once as you'd like, monitoring at most 50 email inboxes.

How about some sample settings?
Below are the settings I use for my email-to-case demonstrations. There are two configuration files, email2case.txt and sfdcConfig.txt.

email2case.txt

<configFile>
<server1>
      <url>imap.gmail.com</url>
      <protocol>imaps</protocol>
         <port>993</port>
      <userName>******@googlemail.com</userName>
      <password>******</password>
      <interval>1</interval>
      <inbox>inbox</inbox>
      <readbox>ReadMail</readbox>
      <errorbox>ErrorMail</errorbox>
</server1>
<server2>
      <url>imap.gmail.com</url>
      <protocol>imaps</protocol>
         <port>993</port>
      <userName>******donotreply@gmail.com</userName>
      <password>******</password>
      <interval>1</interval>
      <inbox>inbox</inbox>
      <readbox>ReadMail</readbox>
      <errorbox>ErrorMail</errorbox>
</server2>
</configFile>

sfdcConfig.txt

<configFile>
<sfdcLogin>
      <url>https://www.salesforce.com/services/Soap/u/9.0</url>
      <userName>******</userName>
      <password>******</password>
      <loginRefresh>30</loginRefresh>
      <timeout>6000</timeout>
</sfdcLogin>
<notify>
      <notifyEmail>******@gmail.com</notifyEmail>
      <from>******@gmail.com</from>
      <host>smtp.gmail.com</host>
         <port>465</port>
      <user>******@gmail.com</user>
      <password>******</password>
      <service>com.sforce.mail.SMTPNotification</service>
</notify>
<attachments>
      <largeAttachmentDirectory>C:\\largeattach\</largeAttachmentDirectory>
      <largeAttachmentURLPrefix>file:\\YOUR_COMPUTER_NAME\largeattach\</largeAttachmentURLPrefix>
      <largeAttachmentSize>5</largeAttachmentSize>
</attachments>
<services>
      <com.sforce.mail.EmailService>C:\\EmailAgent\\email2case.txt</com.sforce.mail.EmailService>
</services>
</configFile>

Thank you Peter! Next week: Part 2: Things To Consider.

-Marco Casalaina

How To Stop People From Making Comments On Closed Cases

Sometimes customers ask me how they can make closed cases "uncommentable" – once those cases are closed, they don't want their reps to be able to make new comments on them.

Traditionally the way to accomplish this would be to change the record type of closed cases and use a layout for that record type which hides the Case Comments related list. This is not ideal, though, because it means that you can't read the comments either.

Fortunately, with Workflow From Case Comments, there is now a better way.

As I mentioned in my previous blog entry, Workflow From Case Comments is a "chaining" workflow, which means that when it edits the parent case, it kicks off the workflow anew on that case object. We can use this to our advantage in solving this problem. Here's how.

1. Define a checkbox-type custom field on Case called "No more comments." Do not add it to any of the Case page layouts.

2. Make a validation rule which shows the error "You cannot add comments to a closed case" at the top of the page. In the formula section put simply "No_more_comments__c =true" (see first screenshot, left).

3. Make a Workflow on the Case Comments object which fires when Case: Closed equals True (see second screenshot).

4. Make a Field Update in that workflow which sets the No More Comments field to true.

5. Activate the workflow rule!

Now, when you try to submit a comment on a closed case, the workflow will fire on the case comment. This will make the modification to the No More Comments field on the Case to set it to true, which will violate the validation rule and disallow the save, showing the error "You cannot add comments to a closed case." (see triumphant third screenshot)

Workflow From Case Comments to the rescue!

-Marco Casalaina

Workflow From Case Comments!

I am pleased to report that the Winter '09 release includes a feature that customers have been asking about for years: Workflow From Case Comments!

Workflow From Case Comments gives you the ability to create a workflow rule on the Case Comments object. From that rule, you can create a field update that takes effect on either the comment itself or on the parent case.

This means that you can finally create those workflows you've been waiting for!

For example, let's say I have a process whereby I set my case to a status of "Awaiting Customer Response" when I'm waiting for the customer to get back to me. Now my customer logs into the Customer Portal and adds a comment to the case. That constitutes a response, so the system should automatically set my case back to a "Working" status.

The screenshots shown here to the right document how I wrote a workflow that does just that. All I have to do is write a workflow rule on Case Comment with the requisite criteria (and the criteria can refer to items from the Case as well). Once that's done, I can make a field update that updates the status field on the case.

As people begin creating workflows from Case Comments, they inevitably notice that only Field Update and Outbound Message are available from these workflow rules. Then they ask me, what if I want to send an email?

As with workflow from Email Messages, Workflow From Case Comments is a "chaining" workflow – it can trigger other workflow. Right now you can't put an email alert on the comment for the same reason you can't put a task on it: because the Comments object does not support Activities as children. However, you can put an email alert on a workflow on the parent case, and that workflow will get triggered and send out the email (and the email will be associated to the parent case, as you might expect).

So, although you can't send an email directly from a Workflow From Case Comments, you can put an email alert on the parent case. So, for example, you might make a Workflow From Case Comments that updates a "Last Comment" field on the parent case with the text of the most recent comment, and then make a workflow on Case which emails out that last comment to certain members of the Case Team.

Case Teams! A little foreshadowing there – I'll cover that new Winter '09 feature in my next dispatch.

Don't forget, post any questions about this blog entry on the General board on developer.force.com so that the whole community can benefit from it.

-Marco Casalaina

Adding A Link Button To Your CTI Adapter

Here's another question that CTI customers often ask me, particularly in the new age of Visualforce: "Can we add a button to the adapter that navigates to a link and passes it some information about the call?"

Yes you can! You can do it with a minor modification to your CTI adapter code. Here's how.

In my example, I've made an Apex page called "QuickCreate" that takes in as parameters the ANI (or caller ID) and the DNIS (the number that was dialed). Now I'm going to make a button in the CTI adapter that links to this page, passing it the appropriate information for the active call on the line.

In your .h file, add something like this:

#define BUTTON_QUICK_CREATE 21

In your Initialize() method, add this:

      
      CCTIButton pQCButton;
      pQCButton.SetLabel(L"QuickCreate");
      pQCButton.SetLongStyle(true);
      pQCButton.SetColor(COLOR_BEIGE);
      pQCButton.SetLinkURL(L"/001/e");
      UIAddButtonToAllLines(BUTTON_QUICK_CREATE,&pQCButton);

Just after you call OnCallRinging, add this code (I left in my OnCallRinging code for context – add everything from the CCTILine down):

      int nReturn = CCTIUserInterface::OnCallRinging(sCallObjectId, nCallType, true, bLogCall, mapInfoFields, mapAttachedData, nLineNumber);
      
      CCTILine* pLine = GetLine(nReturn);

      if (pLine) {
            CCTIButton* pQCButton = pLine->GetButton(BUTTON_QUICK_CREATE);
            if (pQCButton) {
                  pQCButton->SetLinkURL(L"/apex/QuickCreate?ANI="+mapInfoFields[KEY_ANI]+L"&DNIS="+mapInfoFields[KEY_DNIS]);
                  
            }
      }

When the call is established, add the button to the line like this:

      listEnabledButtons.push_back(BUTTON_QUICK_CREATE);

And that's all there is to it! Now you'll have a button that shows up whenever a line is active which, when clicked, will navigate to your Visualforce page.

Kiva and the Quick Mass Close Button

From time to time in my job as product manager of Service & Support I come into contact with people who are using Salesforce.com to make a difference in the world. One such company is Kiva.

Kiva is a microfinance non-profit that allows you to lend as little as $25 online to an entrepreneur in the developing world that needs a loan. On Kiva, you act as a banker to the poor by lending money to entrepreneurs in developing countries and then you get repaid. Amazingly, in just 3 years, they've lent $44 million to 92,000 entrepreneurs, with an astonishing 98.5% repayment rate.

Kiva is currently competing in the American Express Members Project, which will grant a grand prize of $1.5 million to the non-profit which garners the most votes from Amex cardmembers. This money at Kiva could enable $30 million more loans to fund 60,000 more entrepreneurs so that they can lift themselves out of poverty.

If you are an Amex cardmember, please click here to vote for Kiva – it really is a good cause.

And now on to the meat of today's post:

Kiva runs all of its customer service operations on Salesforce.com. A few weeks ago they came to me with a request which I've heard before: they wanted a Mass Case Close button that skips the Case Close screen and just closes the cases. This is just a twist on the Quick Case Close button that I have written about previously on this blog, so I was happy to oblige.

The code is quite simple:

{!REQUIRESCRIPT("/soap/ajax/13.0/connection.js")}

var records = {!GETRECORDIDS($ObjectType.Case)};
if (records[0] == null)
{
	alert("Please select at least one case to close.")
} else {
	//Get more info on the cases that were selected and generate a query out of it
	var updateRecords = [];

	//Iterate through the returned results
	for (var recordIndex=0;recordIndex<records.length;recordIndex++) {
		var caseUpdate = new sforce.SObject("Case");
		caseUpdate.Id = records[recordIndex];
		caseUpdate.Status = 'Closed';
		updateRecords.push(caseUpdate);
	}

	var result = sforce.connection.update(updateRecords);
	
	//handle errors here
	if (result.error) {
	alert('There was an error processing one or more cases');
	}

	//Reload the list view to show what he now owns
	parent.window.location.reload();
}

To add this code, go to Setup->Cases->Buttons and Links and make a new custom button called Mass Close. Its Display Type should be set to List Button, its Behavior to Execute JavaScript, and its Content Source to OnClick JavaScript. Paste the above code into the OnClick JavaScript field – but be sure to replace the caseUpdate.Status = 'Closed'; line with a status that is present in your org.

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.

As with the Contention-Proof Accept Button, the trick here is that GETRECORDIDS call – it gets us the list of Case IDs that you selected from the list. The rest here is simple, just put all those Case IDs into an array and set the case status fields to Closed, and call update. Easy!

Just imagine what other sorts of mass actions you could do with this method. It's hard to fathom the creativity of the readers of this blog.

And just in case you missed it: Vote for Kiva! :)

The Contention-Proof Case Accept Button

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.

An Even Better Way To Pop Visualforce Pages From CTI

In a previous blog entry I posted a means of popping a Visualforce page from a CTI adapter. That method was somewhat complicated and required an adapter writer to modify some of the core CTI Toolkit library code.

Digging into it a little further, I recently came up with a much simpler way to pop a Visualforce page from CTI. There is one caveat here: using this method, your CTI adapter will always pop this Visualforce page – it won't try to do any other kind of search. As long as you're OK with having your Visualforce page do any searching required, then this method is for you. Here's how to do it.

Make a Visualforce page that takes in ANI and a DNIS as parameters on the URL. You may also want to make it take in other parameters that might be attached to the call.
Whenever you call CCTIUserInterface::OnCallRinging to set the adapter to its "call ringing" mode, set the third parameter to false. This disables the native adapter search mechanism.
After every call to OnCallRinging add this code (replacing the "YourPageHere" with the actual name of your page):

CCTIParty* pParty = pLine->GetPartyByANI(mapInfoFields[KEY_ANI]);
if (pParty) {
	RelObjSetList relObjs;
	CCTIRelatedObjectSet* pSet = 
		new CCTIRelatedObjectSet(L"Visualforce",L"Caller Info",L"Caller Info");
	pSet->SetVisible(true);
	relObjs.push_back(pSet);

	std::wstring apexUrl = L"apex/YourPageHere?";
	apexUrl += L"ANI=" + mapInfoFields[KEY_ANI];
	apexUrl += L"&DNIS=" + mapInfoFields[KEY_DNIS];

	CCTIRelatedObject* pObject = new CCTIRelatedObject(apexUrl,L"Click To View");
	pObject->SetVisible(true);
	pSet->AddRelatedObject(pObject);

	pParty->AddRelatedObjectSets(relObjs);
}
UIRefresh();

This code verbatim added to your adapter just after you call OnCallRinging will cause it to pop to the Visualforce page. The Visualforce page can figure out what it should search on based on the ANI and DNIS that's passed in via the URL.

To take this a step further, you can also append all the members of mapAttachedData to the URL, which will enable you to pass any attached data (say, caller entered digits in the IVR) to your Visualforce page.

One more thing, though: usually, when the CTI adapter pops an object, it tries to add that object to the call log. However, a Visualforce page cannot be added to the call log, and if you try to add one, it will cause the call log to fail upon saving. So you'll want to override the function that adds objects to the call log to ignore Visualforce pages. You can do so by overriding UIAddLogObject in your subclass of CCTIUserInterface, like this (replacing the CDemoUserInterface with the name of your subclass, of course):

void CDemoUserInterface::UIAddLogObject(PARAM_MAP& parameters) {
      std::wstring sId = parameters[KEY_ID];
      if (sId.find(L"apex") == std::wstring::npos) {
            CCTIUserInterface::UIAddLogObject(parameters);
      }
}

Obviously you'll have to add a corresponding method header to your .h file also.

To genericize this, you might consider adding a parameter to your Call Center Definition File (that XML file you distribute to your customers) that specifies the Visualforce page to pop to. If the customer specifies this page in the setup, then always pop to it; otherwise take the normal route of searching for a Salesforce.com object and popping what you find.

And by the way:

Let's say you want your Visualforce page to add an object to the log. As I mentioned earlier you can't put the Visualforce page itself in the log, but you can send a message to the CTI adapter to have it add an object to the log.

All you have to do is have your Visualforce page call the following Javascript function:

sendCTIMessage('ADD_LOG_OBJECT?ID='+entityId+'&OBJECT_LABEL=' + escape(entityLabel)+'&ENTITY_NAME='+entityDevName+'&OBJECT_NAME=' + escape(entityName));

where:
entityId = the Salesforce.com ID of the object you want to add to the log
entityLabel = the name of the object you want to add to the log (like "Lead" or "My Custom Object")
entityDevName = the API name of the object you're adding (like "Lead" or "My_Custom_Object__c")

Case Age In Business Hours

I am pleased to announce that we have released an AppExchange application called Case Age In Business Hours (click link for the AppExchange listing) under the Salesforce Labs banner. In this post I'll explain what it does, how it does it, and how you can modify the code if you so desire to make it do more.

So first, what does it do? More than its name suggests, actually. First, and most obviously, it calculates the Case Age In Business Hours for your closed cases. Fancy that. It also has another useful function, though: it includes two more fields called Time With Support and Time With Customer that distinguish between time spent by your support team and time spent awaiting the customer. Note that these new fields will only be accurate for closed cases -- I'll explain why in a bit.

It sounds like it might be complex, doesn't it? A few years ago, back in my full-time developer days, I wrote some code that calculated time differences in business hours, taking into account time zone differences, daylight savings, and all that jazz. It was hundreds and hundreds of lines of code, and it took me days to get it right. My pinkies still twitch at the thought of it.

Thankfully, some of the capabilities we recently added to the Force.com platform make the Case Age In Business Hours package a cinch. It does everything my old hunk of code did and more, but if you look at the trigger which forms the basis of this package, there are only 55 lines of code, and half the lines are comments or whitespace.

What made it all possible are the BusinessHours methods in Apex, particularly BusinessHours.diff. You pass BusinessHours.diff two times and a set of Business Hours (and you can define as many sets of Business Hours as you want at Setup->Company Info->Business Hours) -- and it spits back at you the time difference in business hours! It does all the time zone translation and daylight savings nastiness for you, and all you have to do is call the method. That's it!

Now for the interesting part, though: how about those Time With Support and Time With Customer fields? How do we figure that out?

Well, if you install the package, you'll notice that it also installs a custom object and tab called "Stop Statuses." To set it up, you access this tab and add the names of the case statuses you'd use when you're waiting for your customer. Some people have "Awaiting Customer Response" or "Awaiting Customer Validation" -- some just have "On Hold." Whatever your statuses may be, add them all in the Stop Statuses section. Then, whatever time your case spends in one of those statuses will be tallied to the Time With Customer field -- and any time your case spends not in a stop status (and not in a closed status, of course) will be added to to the Time With Support field.

Now what if you want to take it to the next level -- let's say you want to add a bucket and measure Time With Tier 1, Time With Tier 2, and Time With Customer? Well, that wouldn't be so hard -- you'd just have to factor in the owner as well as the status when deciding what times go in what buckets.

Before we begin, remember that because the Business Hours functionality is new, this Apex will only compile against the 13.0 API and higher (13.0 being the latest as of the Summer '08 release). If you haven't got the latest Force.com IDE plugin, now would be a wonderful time to download it. It makes Apex development much easier.

First, we'll have to add some fields to Case to store this bucket. Let's call them Time With Tier 1 and Time With Tier 2 (with corresponding API names Time_With_Tier_1__c and Time_With_Tier_2__c respectively).

Now we'll modify the trigger a little to accommodate these new buckets. First, we'll need to figure out if the current user is a Tier 1 or a Tier 2 agent. Let's assume (for the sake of simplicity) that we have two queues, Tier 1 and Tier 2, and that the current case owner will either be in one or the other. It is admittedly a simplistic example, but this is a blog post, not a book.

All you really need to do is add some code after this line:

Double timeSinceLastStatus = BusinessHours.diff(hoursToUse, updatedCase.Last_Status_Change__c, System.now())/3600000.0;

That's the code that actually figures out how many business hours have passed since the last status change. At this point, you have the time you need to add to a bucket -- now all you have to do is find the right bucket to add it to.

In the package, the bucketing code is pretty simple -- either the case spent the time since the last status change in a stop status, or it didn't:

if (stopStatusSet.contains(oldCase.Status)) {
    updatedCase.Time_With_Customer__c += timeSinceLastStatus;
} else {
    updatedCase.Time_With_Support__c += timeSinceLastStatus;
}

We'll have to modify this statement to figure out whether the case owner is in tier 1, and then assign the time to the proper bucket. First, let's find out if the owner in tier 1:

Boolean ownerIsTier1 = false;
//Search the Tier 1 queue for this user
GroupMember groupMember = [Select Id from GroupMember g where g.Group.Name='Tier 1' and 
                           g.UserOrGroupId=:updatedCase.OwnerId];
if (groupMember != null || updatedCase.Owner.Name == 'Tier 1') {
    //We found the user in the Tier 1 queue!
    ownerIsTier1 = true;
}

The variable ownerIsTier1 will now be true if either the owner was found in the Tier 1 queue or if the owner is the Tier 1 queue itself. Now that we've figured that out, we can put the time in the right bucket:

//We decide which bucket to add it to based on whether it was in a stop status before
if (stopStatusSet.contains(oldCase.Status)) {
    //This still goes in the customer bucket!
    updatedCase.Time_With_Customer__c += timeSinceLastStatus;
} else {
    //This is time with support -- let's see which tier's bucket we put it in
    if (ownerIsTier1) {
        updatedCase.Time_With_Tier_1__c += timeSinceLastStatus;
    } else {
        updatedCase.Time_With_Tier_2__c += timeSinceLastStatus;
    }
}

Finally, we change the Case Age In Business Hours total code a little:

if (closedStatusSet.contains(updatedCase.Status)) {
    updatedCase.Case_Age_In_Business_Hours__c = 
    updatedCase.Time_With_Customer__c + 
    updatedCase.Time_With_Tier_1__c +
    updatedCase.Time_With_Tier_2__c;
}

And there we have it. Extending this example, you can calculate business hours times for all kinds of buckets. Just imagine the reporting possibilities? I can hear call center managers around the globe rubbing their hands together in glee.

Here's the finished trigger modified per the example given here. I'll leave it to you to write the test cases for it.

A little earlier I noted that these fields are only accurate for closed cases. Why do you suppose that is?

Back in high school, my creative writing teacher used to say that if you want to hold your reader's attention, you have to leave an unresolved mystery until the end. Well, if you're still reading this, I guess it worked -- thanks Mrs. T!

The answer to today's unresolved mystery is that these fields don't measure the difference between the time the case was opened and now -- they measure the difference between the time the case was opened and the last time the case status changed. That's because only a change to the case can trigger the Apex which updates these fields, and I deemed a status change the most appropriate change to perform this sort of recalculation. Once the case is closed, these fields are frozen -- even if you change it from one closed state to another, they won't budge (if you reopen the case, on the other hand, they'll start tallying again). The fact of the matter is, then, that only once the case is closed will you have a final tally of Time With Customer, Time With Support, and Case Age In Business Hours.