Another Way To Skip The Case Close Page

Some time ago I wrote about The Quick Case Close Button as one means of skipping the Close Case page.  In fact, there's another way to close cases quickly: you can show closed case statuses directly in the Status field of Case.  This is not enabled by default, so many people miss this option.

You'll find the options that enable this in Setup->Customize->Case->Support Settings, and there are two of them.

Show Closed Statuses in Case Status Field does exactly what its name implies: it allows you to show closed case statuses right in that Status field.  This means you can actually create a case and close it in a single step. Once you have closed statuses in that Status field, you can hide the Close Case button on the Case detail page by editing the Case page layout.  

However, the page layout editor does not allow you to control the buttons on the edit page, and so you may be left with one redundant button, namely the Save & Close button.  Fortunately there's another option for that on the Support Settings page, namely the Hide Save & Close Button.  When this is enabled, the Save & Close button disappears from the edit page also.

For many Salesforce.com customers, this little addition should reduce the number of clicks it takes for their agents to create and close a case.

The Quick View Tab

Lots of people would love to have a tab that just opens directly to a view of their choice.  Unfortunately, standard object tabs can only open the relevant standard overview page, which shows a list of recently viewed cases -- that page can't be preset to open a certain view as soon as you hit the tab.  However, you can create a custom tab which will instantly redirect itself to the view you'd like.  Here's how.

The most common request I get is to create a tab for views on Case, so that's the example I'll give here.  Of course, this technique can be used to create a tab for any kind of view for any object.

First, navigate to the view you'd like to tab-ify by going to the overview page and selecting that view.  In my case, I'll go to the Cases tab and click on the Open Cases view, which is a view I created that shows all the open cases in my org. 

Save the URL of this view; you'll need it later.  It will look something like 

https://na1.salesforce.com/500?fcf=00B300000031l4H

Now go to Setup->Customize->Create->Tabs.  Click the New button under Web Tabs.  Set it to Full Page Width.  Set the Tab Type to URL, and give it a label that makes sense (I called mine "Open Cases" but you can call yours "Cases" if you intend to hide the normal case tab -- just make sure you don't end up with 2 tabs labelled "Cases").  Pick any Tab Style -- it's going to redirect to the Case tab anyway so this doesn't matter.

On the next page of the wizard, enter the following in the Button or Link URL:

javascript:parent.navigateToUrl('<your url here>');

Don't forget those single-quotes around the URL.  So in my example it looks like this:

javascript:parent.navigateToUrl('https://na1.salesforce.com/500?fcf=00B300000031l4H');

And voila!  You now have a tab that navigates directly to your view.

Bear in mind that a quick JavaScript navigation of this sort breaks the Back button minorly -- if you click this tab and then hit the back button, you'll get bounced right back to your view.  You have to click the Back button twice in rapid succession to get back where you started.  Consider yourself warned!

Stamping A "First Response" Field When An Email Goes Out On A Case

A common service-level agreement (or SLA) in the support world is the first response time.  Support organizations are often contractually obligated to respond to a given case within a certain number of hours.  It is a little-known fact that you can use Salesforce.com to manage this type of SLA using simple workflow rules -- no Apex Code required!

First, we should note the existence of the Entitlements Processes functionality built into Salesforce.com.  This capability allows you to measure and track your response, workaround and resolve time SLAs, both in calendar hours and business hours, so if you have some significant entitlement and SLA needs, Entitlements Processes are worth checking out.  It's fairly involved to set that up, though, so today's post is focused more on people with more lightweight needs.  Today we'll look at just using a simple workflow rule to stamp your first response time.

Your first step will be to add a First Response date/time field to Case.  Next, if you haven't turned on Email To Case, do so by going to Setup->Case->Email To Case.  You don't even have to activate any routing addresses.  The reason for this is that once you have turned on Email To Case, there's an object under case called Email Message. 

You can make workflows on this Email Message object which update the parent Case.  So your next step is to create a workflow rule on the Email Message object.  Here, set your criteria such that you stamp your field when the email message is outbound (i.e. "Is Incoming equals false") and the First Response field is empty (because you don't want to stamp it again once it's been stamped). 

Finally, put a field update on this workflow rule to stamp the First Response field to NOW(). 

That's all it takes -- once you activate this workflow rule, your First Response field will begin getting stamped immediately, and you can start reporting on it. 

Also: Note that if you are using the Customer Portal or Self-Service Portal, another means of responding to your customers would be via a public Case Comment.  You can use a very similar process to that given above to stamp your First Response field from a Case Comment -- just set the object on the workflow rule to Case Comment instead of Email Message.

How To Create A Mass Email Distribution List in Salesforce.com

Today we have a quick but common question from the Salesforce.com Answers boards.  People often ask, "I want to email a bunch of people from Salesforce.com at once.  How do I do that?"

Note that this post covers how to send an email from Salesforce.com's default Campaign functionality.  Just prior to when this blog was posted, Salesforce.com acquired ExactTarget, which is a much more industrial-strength solution for outbound email.  This blog post is intended for people that just need to send mass emails to 1000 or less people.

The answer is a little bit roundabout, but:

1.  Create a Campaign that will represent your mailing list.  If you can't see the Campaigns tab, be sure that in your user record Marketing User is checked on, and that in your profile you have create access for Campaigns.
2.  Either fill the campaign manually using the Edit Campaign Members button, or create a report on Contacts with the criteria as needed and press the Add To Campaign button to fill your campaign.
3.  Now go to the Contacts tab and click Create New View.  Set it to All Contacts, put no criteria on it, and enter your campaign in the Filter By Campaign box.  Save the view.
4.  Go back to the Contacts tab and click the link entitled Mass Email Contacts.  Select the view you created in step 3, select your email template, and you're off to the races.

Note that a campaign can contain either Contacts or Leads (or both), so if you want to email Leads instead, modify steps 3 slightly to say "Go to the Leads tab" and "click the link entitled Mass Email Leads."

Reporting On "Cases Filed By My Accounts"

The other day a poster on the Best Practices board asked whether there was a way to filter a report on Cases by "My Accounts."  By default, Case reports are filterable by the case owner, but not by account.  Fortunately, there is a way to do this, it's just a little roundabout:  you have to create a case report which is driven off of Account using Custom Report Types.  Here's how.

1. Go to Setup->App Setup->Create->Report Types.
2. Make a new Custom Report Type.  Select the primary object as Account.
3. On the next screen set the "B" object to Cases -- I use "with or without cases" so you can see accounts of yours that have no cases onthem.
4. Save it.  Now go to the reports tab and make a report of this type.  When you get to the filter part you'll see that you can now filter by "My Account."  You can also add regular criteria to case fields like Case.IsClosed so that you only see the open cases in the report, for example.

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.

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.

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 some restrictions about these workflow rules.  They ask, what if I want to send an email to the case owner?  Why can't the email alert find that field?

As with workflow from Email Messages, Workflow From Case Comments is a "chaining" workflow -- it can trigger other workflow rules.  Certain operations on Case Comment are limited because of what the workflow action is "looking at" -- an Email Alert, for example, is "looking at" the Case Comment and so cannot see the Case Owner, for example.  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 the Case Owner, or to certain members of the Case Team.

Using Visualforce Components Defined in a Managed Package

As part of our KXEN Predictive Offers package, we define a couple of Visualforce components.  This has two purposes.  First, it fosters code reuse: we reuse these components on pages within our package that apply to Contacts, Leads and PersonAccounts, so we don't have to duplicate a bunch of Visualforce code.  Then, our customers may want to embed the capability to show an offer into a larger Visualforce page, so they can use these components themselves in their own pages.

In testing the latter capability today, I ran into a buzzsaw of incomplete and hard-to-find documentation on the Salesforce.com side, so I am going to address it here so that folks googling this topic in the future might find this.

The first issue was that, in attempting to use our component in a target org, it was not found.  I was specifying it just as we do in our own pages, like this:

<c:ShowOfferConsole userId="{!Contact.Id}"/>

This was buzzsaw #1: within our package, we can refer to the component using the standard c: notation.  The component was global, so I should be able to use it, right?  I also tried c:Offers__ShowOfferConsole, thinking maybe the kind of namespacing you do in Apex would work, but no dice there.  Finally I figured it out: outside our package I had to refer to it via its package namespace (which in this case is "Offers"), like this:

<Offers:ShowOfferConsole userId="{!Contact.Id}"/>

Great!  That only took me about an hour to figure out!  But it still didn't work, now for a different reason.  Now I get this error:

Error: Cannot use attribute userid (in component offers:showofferconsole) without global access in a component/page that is not in the same namespace as the component in my_visualforce_page at line 117 column 61

This took a while to track down.  The component is global, yes, so I should be able to use it; but in components, like in Apex classes, you also have to make the individual attributes global in order to access them from outside the package.  Fortunately this is our own package so we can modify the code, and here we needed to modify the component to make the userId attribute global.  Now, finally, I can use the component outside the package!