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!

Assigning Cases According To The Email Address From Which They Originated

Someone asked me 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.  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, one for each division (note that you can add more than one at a time by separating them with a linefeed). 

Now go over to Setup->Customize->Cases->Email-To-Case.  Click on the Edit link for your Support routing address for each division. At the bottom of the ensuing page, you can set the Case Origin for this routing address.  After saving this, you now have a field on Case which records which email address it was created from!  You can now use that in your assignment rules.  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.