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.
Awesome! Glad to have helped.
ReplyDeleteWe should collaborate more often... it's fun when we start thinking outside the box and then just throw the box out the window.
Would you like to share the template that you're using in the workflow? It might be helpful to see how you're passing the values in it.
Keep monkeying around!
Is this still true as of Summer '09? I tried it with my own org in Summer '09 and it seems to work as expected -- I didn't get any locking error when inline editing after the SSP user triggered the workflow.
ReplyDeleteI haven't had a chance to test this in Summer'09 -- the workaround we implemented has been working great, and our project queue is BIG.
ReplyDeleteThanks for looking into it -- sounds like it's been fixed. And I didn't have to lift a finger. Another reason I love working in the cloud.