0

I am planning to implement this trigger on the FeedComment object, as this object is not available for use via Lightning Process Builder. I'm looking to update the case when a certain type of user (based on profile) adds a comment to a feed item (e.g. someone makes a post on the chatter feed and then a reply is added subsequently).

This simple trigger appears to "do the job," but I am curious as to whether it is to best practices or there is a better more eloquent way to write this:

trigger FeedCommentTest on FeedComment (after insert) 
{
    for(FeedComment f : Trigger.New)
    {
        if(UserInfo.getProfileId()  == '00e23000000DeaWAAS' && String.valueof(f.ParentId).substring(0,3) == '500' )
        {
            Case CaseToUpdate = [SELECT ID FROM CASE WHERE ID =: f.ParentId];
            CaseToUpdate.Status = 'Customer Replied';
            CaseToUpdate.Description = 'success';
            Update CaseToUpdate;
        }          
    }
}

UPDATE:

Here is my updated trigger that I will use in production:

trigger FeedComment_UpdateCaseStatus on FeedComment (after insert) 
{   
    String RecordTypeId = String.valueof([SELECT ID FROM Profile WHERE Name = 'Customer Community Login User'].Id);

    for(FeedComment f : Trigger.New)
    {    
        if(UserInfo.getProfileId()  == RecordTypeId && String.valueof(f.ParentId).substring(0,3) == '500' )
        {
            Case CaseToUpdate = [SELECT ID, Status FROM CASE WHERE ID =: f.ParentId];

            if(CaseToUpdate.Status != 'Customer Replied')
            {
               CaseToUpdate.Status = 'Customer Replied';       
               Update CaseToUpdate;
            }            
        } 
    }
}

Thanks in advance!

  • 1
    The approach looks right. Best practice for triggers normally would be to 1) avoid hardcoding the profileid, and 2) bulkify the Case update - but I can't see the latter being a problem in this case given users would only add a singe FeedComment at a time anywa! – Alex McDonald Feb 4 '16 at 3:03
  • @AlexMcDonald What would be a better solution for replacing the hardcoded id? I wondered if some sort of constant could be used here. – tchock Feb 4 '16 at 7:39
  • Before looping through the trigger, you can use String profileid = [SELECT Id FROM Profile WHERE Name='My Customer Profile'].Id; and then you replace the hardcoded id with if(UserInfo.getProfileId() == profileid) ... – Alex McDonald Feb 4 '16 at 8:10
  • @AlexMcDonald Would there be any real advantage to querying the profileid? Couldn't you run into an issue if the profile name gets changed? I'm just figuring that an id would never change, but a profile name could (but shouldn't). Thanks again! – tchock Feb 4 '16 at 18:24
  • 1
    The ID does change for each Sandbox and Production, while the Name is constant between all the environments. So when you migrate your code from your Sandbox to Production you'll have to edit the code in Prod to change the ID (not best practice). And everytime you create a new Sandbox from Production you'll again have to change the ID in that Sandbox. While one hard-coded ID can be handled, if you use them by default it'll become a maze that needs to be handled. Especially since Salesforce just announced that EE will now include 25 dev sandboxes instead of 1! – Alex McDonald Feb 4 '16 at 22:13
1

Trigger is looking good, but I'd still like to offer my $0.02 and summarize the discussion thus far. A couple points:

  1. Bulkify the Trigger. Your Update CaseToUpdate could potentially cause an issue. The only scenario that will cause a problem is if you need to load FeedComments via DataLoader. You're only allowed 150 DML statements, so if 200 FeedComments get loaded, you'll get an error. You can fix this by storing the cases to update in a list and ending the trigger with an update on the entire list. There's tons of resources on the internet to help, like Salesforce Trailhead!
  2. Custom Settings. Generally, I would recommend to at least provide the ability to turn off a trigger with a custom setting. I see an opportunity for a hierarchy custom setting here. First, you could relatively easily use a checkbox controlled by an admin to turn the trigger on and off (for cases like our data load). Second, by utilizing a hierarchy custom setting, you can provide an admin the ability to configure which profiles this trigger applies to. The reason this is such a big deal is because Profile Id's change from org to org. If you have developed this in a sandbox and deploy to production, you would be surprised to fine that your trigger doesn't work. Again, plenty of help here: Custom Settings Help and Custom Setting Methods.
  3. Test Classes. Finally, you should have at least 1% of coverage on your trigger (but ideally 100%!). https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_qs_test.htm

You've made some good progress, but you asked for best practices :-) There are plenty of other enhancements you could make, but I get the feeling you're not dealing with a huge org.

I know I didn't provide the code for you, but I encourage you to continue trying and asking questions.

Out of curiosity, how many users are in your org?

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.