Case Comment from Contact "Locks" Inline Editing on Case

We ran into an annoying little bug, and when we contacted Salesforce.com about it, they confirmed it is a known issue that occurs “sometimes”. Well, before we spent a couple hours chasing it, the bug had not been known to us. Here are the details, including several workarounds and a “fix”.

First, let’s describe how the problem appears to Salesforce.com Users. Your Customer Service Rep or other internal user opens a Case, and starts updating / changing fields using the Inline editing feature. When they save the record, they get an error message that the record was being updated by a Customer:



All of the edits they made to the case are lost, and they have to re-enter them.

As we look at the Case History, we see that the last Customer update was many hours ago.

In our configuration, Customers are able to create Cases through the Self-Service Portal, but they can’t actually edit them. So we were confused as to what was causing these Cases to get “locked” by the Customer contact. However, we did recently add a Case Comment Workflow, which changes the status of a Case from “Waiting on Customer” to “Investigating” whenever a Customer adds a case comment via the Self-Service Portal. This Workflow was added when Case Comment Workflows were introduced in XXX.

Here’s the workflow that we created:



When those filters are hit, a Workflow rule changes the parent Case.Status field from “Waiting on Customer” to “Investigating”.

Salesforce.com told us this behavior is seen “only occasionally”, although we found that we could reproduce the failure 100% of the time:

1.) Create a new Case, set the status to “Waiting on Customer”
2.) Login to Self-Service Portal. Add a Case Comment.

That’s it. At that point, the record is “locked” to inline editing. The first internal user to open the Case and attempt inline editing on any field will get the error message above.

Two Immediate Workarounds

1.) Use the Edit button instead of Inline editing. This wasn’t preferred by our users, since they’ve become very accustomed to the ease and use of the inline editor.
2.) Train your users to look for the “New Comments Have Been Added” bubble (see below) at the top of the case. If they see this icon, they should refresh the page in their browser before doing any inline editing. This refresh will clear the lock on inline editing.




A Better Way

The story would end here if it wasn’t for an interesting discussion I had with David Schach (of X2 on Demand fame: http://www.x2od.com). @dschach and I were chatting on Twitter the other day, then moved our conversation to the telephone (when 140-characters wasn’t enough to get our message across to each other). He was suggesting a solution to a different problem I had, but it turns out that idea has many applications – including a fix to this Inline Editing lock problem here.

The conversation was discussing a way to simulate Apex triggers on a Case Comment object. Recently, Salesforce.com added the ability to perform Workflows in Case Comments (which we took advantage of in the scenario above). However, there isn’t any method for directly adding an apex trigger on the Case Comment. Then Dave proposed this “Hacking a Case Comment Trigger” method.

@pauloveryjr and I tried it out with the usage case above. Rather than having a Case Comment Workflow rule that updates a parent Case, we can now have a Case Comment Workflow that sends an email to an “email-to-apex” application. In our tests, it works beautifully – it updates the parent Case.Status field without locking the record from inline editing.

It turns out this Case Comment Trigger Hack has a lot of uses! Until triggers are added to Case Comments, I think we'll be getting a lot of milage out of this technique. I'll document other use cases here on the blog. In the meanwhile, I hope this explains any peculiar inline editing locking behavior that you might have seen recently.

Case Comment Workflow Rules

Here’s a tricky little problem that stymied me today – and the solution!

THE PROBLEM
In the “Status” picklist field of the Case Object, we have defined a “Waiting on Customer” value.



If a Support Rep is working a Case on behalf of a Customer, they'll often come to a point where they can progress no further -- without additional diagnostic or support information from the Customer. When this happens, they'll contact the customer, let them know what information is required, and change the Case Status to “Waiting on Customer”.

When the Customer provides the information, either through the Self-Service Portal, or through an email, the Case Status remains “Waiting on Customer”. Naturally, this frustrates the Customer! When they review their open cases through the Self-Service Portal, they expect to see this status field updated. The Case is no longer waiting on Customer, it's waiting on us!

My Support Team wanted a Workflow rule that would automatically change the Case Status from “Waiting on Customer” to “Investigating”, whenever the customer added a Case Comment through the Self-Service Portal, or if they send in an email related to the Case (to our email2case application).

When I reviewed the Release Notes for Winter'09, I knew this functionality -- the ability to create a workflow rule on Case Comments -- had been recently added in. But as I started playing with the rule criteria in my sandbox, I got stuck. How do determine if a Case Comment was added by a Self-Service Portal user?

THE SOLUTION
A quick search on the Salesforce Community forums gave me this helpful information.

As len123 observes, every user has a type – but Customers accessing through the Self-Service Portal are not “users” (i.e., no user license required). Therefore, any Case Comment added by entities in which the $User.UserType is NULL must originate from Self-Service Portal users.

My first Workflow Rule formula looked like this:

AND (
ISPICKVAL (Parent.Status , "Waiting on Customer"),
ISPICKVAL ($User.UserType , "")
)


Every time a new Case Comment is added, this workflow rule is evaluated. If the related Case status is “Waiting on Customer” AND the $User.UserType is null, go do some action. In my case, the action was changing the related Case Status to “Investigating”.

The Workflow rule worked great. If the Case Status was something other than “Waiting on Customer”, the workflow never triggered. Of if an Internal user added a Case Comment (no matter what the Case status was), the workflow would not trigger.

But some of our customers communicate with our Support organization through email. We have custom Apex application that processes these emails, looks for a certain tags in the email subject line, and finds the Case that email is related to. The app adds the email to the case, and copies the body of the email into a Case Comment. The Support team wanted to make sure these customer updates would trigger the same workflow.

Here is the final Workflow Rule that I implemented:



If that’s hard to read (click to enlarge), the rule criteria formula text block is below:

AND (
ISPICKVAL (Parent.Status , "Waiting on Customer"),
OR (
ISPICKVAL ($User.UserType , ""),
$User.Username = "mail2case@cedarpointcom.com"
)
)


Now, the Workflow rule fires only when Case Status is “Waiting on Customer” AND one of the following is true: 1) UserType is Self-Service Portal user, or 2) case comment was added by our Apex app (which adds the body section of the email to the Case Comments.

What workflow rules have YOU implemented with Case Comments since Winter'09?

PS – Thanks to Twitter follower @CRMFYI for the good tips, and len123 for the workflow formula!