• Welcome
  • About
    • Leadership
    • Blogroll
  • Force-Squared Blog
  • Support
    • Knowledge Base
    • Log a Case
  • Is It Dreamforce Yet?
  • Welcome
  • About
    • Leadership
    • Blogroll
  • Force-Squared Blog
  • Support
    • Knowledge Base
    • Log a Case
  • Is It Dreamforce Yet?
  • Tips and Tricks
  • Configuration
  • Development
You are here: Home / Salesforce CRM / Development / Apex / Hacking a Case Comment Trigger

Hacking a Case Comment Trigger

April 1, 2009 by David Schach 8 Comments

There has been some discussion about asking the salesforce.com team to include the CaseComment object in the “triggerable” list. After conferring with JP Seabury (ForceMonkey), we designed a Rube Goldberg-esque solution to the problem.

Business Use-Case
Whenever a user adds a comment to a case, add him/her to the Case Team.

The Plan

Here it is, in general terms:

  1. Workflow on
    Java
    1
    Case Comment
    sends email to Apex email service
  2. Email service parses
    Java
    1
    CaseId
    and
    Java
    1
    UserId
    and adds the User to the Case Team

Case Comment Workflow
Use existing workflow functionality to send an email whenever a comment is added to a case.

  • Template Includes:
  • Case Id
  • User Id

The recipient is an Apex email service that we can code using the Email to Idea example by Rasmus Mencke.
For more information on setting up the

Java
1
InboundEmail object

, check the Apex documentation.
Apex Class
The class needs to add the User to the Case Team, which requires a few fields:

  • Java
    1
    MemberId
    – UserId (received from the email)
  • Java
    1
    ParentId
    – CaseId (received from the email)
  • Java
    1
    TeamRoleId
    – Could be hardcoded or found in a SOQL SELECT statement. A better practice would be to pass the name or
    Java
    1
    Id
    in the email (coding it in the template), allowing the use of one Apex Class with multiple Case workflow email templates.
  • NOT
    Java
    1
    TeamTemplateMemberId
    – This is not a createable field. It is only available when Case Team members are added automatically in Salesforce CRM.

That’s it! The unique part of this is that we’re sending an email FROM Salesforce TO Salesforce.
Thinking outside the box – isn’t it more fun?

Related

Filed Under: Apex, Configuration, Development Tagged With: Apex, Configuration, Force.com Builder, Force.com Platform

← Flexible Field Labels Salesforce Blackberry Wallpaper →

Filed Under: Apex, Configuration, Development Tagged With: Apex, Configuration, Force.com Builder, Force.com Platform

Comments

  1. Jeff Douglas says

    April 1, 2009 at 14:10

    Nice post. You are so outside the box that you no longer need it!

    Reply
  2. JP Seabury says

    April 1, 2009 at 19:33

    Late night hacks that start over Twitter, migrate over to a phone call and then end up as a “share what you know” blog post are my FAVORITE type of hacks! It’s great flying wingman with you, David!

    Reply
  3. Werewolf says

    April 16, 2009 at 15:27

    The email service is an unnecessary extra step. As I explain here:

    http://blogs.salesforce.com/support/2008/10/how-to-stop-peo.html

    Workflow From Case Comments is a chaining workflow, which means it fires off the full set of workflow actions on Case. This includes Apex triggers. So all you really need to do is make a trigger on your case which adds the user to the case team when the Workflow From Case Comments touches the case.

    Reply
    • David Schach says

      April 16, 2009 at 17:34

      Interesting approach. Yes, a workflow on Case Comment could make a change to the Case, but the Case (chained) trigger would not have access to the UserID of the running user. How would the triger fire (i.e. how would it know that the workflow had “touched” the Case?
      It’s a good idea; could you please be more specific? The KISS principle is always appreciated here!

      Reply
  4. Werewolf says

    April 17, 2009 at 15:31

    Indeed — you’d have to set your Workflow From Case Comments to store the user ID of the commenter into a custom field on the case, and have your Case trigger use that field. Admittedly, then, you’ll be eating a custom field.

    Reply
  5. Stan says

    April 22, 2009 at 10:49

    The LastModifiedDate field of both the Case and CaseComment records are updated when a Case Comment is modified. However, when modifying a Case record, the LastModifiedDate of any associated CaseComment records are not modified. Consequently, you can compare the LastModifiedDate of the CaseComment records against the LastModifiedDate of the parent Case that generated the trigger. If the LastModifiedDate of the Case record is newer than that of the child CaseComment, changes to the Case record caused the trigger. Otherwise, changes to the CaseComment caused the trigger. I just implemented this today in our sandbox and it seems to work but I haven’t spent a lot of time looking at edge conditions and I could have missed something. This strategy requires no workflow rules and is very easy to implement.

    Reply
    • David Schach says

      April 22, 2009 at 15:21

      That is an interesting approach, and I can certainly see uses for comparing the LastModifiedDate in other scenarios!
      I think I see where you’re coming from: Because CaseComment will also execute any Case triggers, you are comparing those dates. So by editing the Case Comment, it will trigger on the Case. That’s great. How do you query the LMD of the CaseComment record if the trigger sits on the Case? I’m having trouble visualizing it; would you like to post your code or send it to me so I can post it with proper formatting? Feel free to use “Send a File” in the Contact Us section.
      Thanks for the comment!

      Reply
  6. Stan says

    April 24, 2009 at 09:31

    I dropped you the complete code that provides a CaseComment trigger. In response to your question, you can access the Case Comment (which actually caused the Case trigger) using the ParentId field in the CaseComment object. It is the Id of the Case record. The SOQL to get the LMD of the Case Comment is: “CaseComment aCaseComment = [SELECT LastModifiedDate FROM CaseComment WHERE ParentId = :C.Id ORDER BY LastModifiedDate DESC limit 1];”. Get the Case LMD using this: “Case aCase = [SELECT LastModifiedDate FROM Case WHERE Id = :C.Id];”. Then do the comparison: “if (aCaseComment.LastModifiedDate >= aCase.LastModifiedDate)”. Put your code to handle a CaseComment trigger inside that “if” statement. Be sure your code handles the potential exception where the Case has no Case Comments or your users won’t be able to make changes to any of their cases.

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Like Us on Facebook

Like Us on Facebook

Share This Page

Find Us Online

  • Twitter
  • Facebook
  • LinkedIn
  • Google Plus
  • X-Squared G+ Page
  • RSS

Subscribe

RSS Feed Comments

Subscribe via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 5,089 other subscribers

Copyright © 2008–2021 X-Squared On Demand · Genesis Framework by StudioPress · WordPress · Log in