Trigger to help Salesforce for Twitter

October 6, 2009 · Filed Under salesforce.com · 1 Comment 

Salesforce for Twitter is one of the best AppExchange packages I've seen. It fulfills the promise salesforce.com made to bring the Service Cloud to all orgs of all sizes. And it works well.

Though a supplemental/unofficial guide to customizing SFDC for Twitter will be released soon on this site, I wanted to share a trigger I just wrote to add new Leads to a campaign:

Firstly, thank you to Scott Hemmeter at Arrowpointe, who wrote the original code that I customized.

Secondly, you could easily duplicate this trigger and set it to run on the Contact object as well.

Please don't set the trigger to "after update," as in testing, it ran into problems when converting a Lead and merging with a Contact already on the "Twitter" campaign.

trigger AddToTwitterCampaign on Lead (after insert) {

    // List containing each Lead being processed
    list<Lead> theLeads = new list<Lead>(); 
      
    //We only execute if we have a campaign named "Twitter"

    if([SELECT Count() FROM Campaign WHERE name = 'Twitter'] == 1){
        Campaign TC = [SELECT id, name FROM Campaign WHERE name = 'Twitter' LIMIT 1];
        
        for(Lead l:trigger.new) { 
            if (l.leadsource.indexOf('Twitter',0 ) >= 0 ||  l.leadsource.indexOf('Tweet',0 ) >= 0 ){  
                theLeads.add(l); // add lead to the main lead list
                }
            }
      
      // List containing Campaign Member records to be inserted
      list <CampaignMember> theCampaignMembers = new list<CampaignMember>(); 
    
      for (Lead ld:theLeads) {
          CampaignMember cml = new CampaignMember();
          cml.leadid = ld.id;
          cml.campaignid = TC.id;
          theCampaignMembers.add(cml);
        }

     //Insert the list of Campaign Members
      if(!theCampaignMembers.isEmpty()){
        insert theCampaignMembers;
        }
    }
}

The trigger requires that you have a Campaign called "Twitter," but feel free to change that to anything else you'd like.

Don't worry if you have other triggers that add Leads to Campaigns - this can work alongside them, so you can add Leads to as many Campaigns as you'd like.

Filtered Lookups, Validation Rules, and Order of Execution

Reading the cheatsheet for Filtered Lookup (beta), I noticed an interesting line:

Lookup filters function similarly to validation rules when you save a record. That is, actions that cause related records to save, such as changes to a roll-up summary fields, also trigger the lookup filters on the related record and block the save.

The implications for this are massive. Let's explore two examples:

Example 1: Filter as Validation Rule from Parent Record

  • We create a lookup on a Child object to Parent.
  • We filter the lookup to EXCLUDE Parent.Status = 'Closed' (Parent.Status is only Open or Closed.)
  • We can edit the Child records as long as the Parent Status is not Closed.
  • When Parent.Status is changed to Closed, existing related Child records are not affected...
  • BUT if we attempt to edit a Child when the Parent is Closed, Force.com will throw an error (which we can customize) beause that the Lookup is invalid.
  • (and clearly we cannot add new Child records either)

Conclusion: Thus, Filtered Lookups act much like Validation Rules. A quick experiment shows that Filtered Lookup errors actually fire before Validation Rules.

Example 2: Filter as Validation Rule on Roll-Up Summary (from Child Record) - what the line above was referencing

  • Use the above example, but change the lookup to a master-detail relationship
  • Create a Roll-Up Summary field to count all child records
  • Prevent saving more than 10 child records for one parent record

Here, we have triggered a filter error without touching a parent record, yet we throw an error based on a value on the parent record.

This second example is significant because we could already prevent more than 10 child records from saving, but doing so required a Roll-Up Summary field on the parent object AND a Validation Rule on the child object. Now we can replace the Validation Rule with the Lookup Filter, though we still need the Roll-Up Summary field. Whether or not this simplifies things is definitely up for debate...

Conclusion

This is a very powerful feature! Thanks to salesforce.com for rolling it out, even in beta form.

Real world example: The above example would be great for Time Sheet Entry and Time Sheet Header objects, as they would create, in effect, a validation rule on the Header record preventing editing of any child records. Awesome!

For further reading, check Salesforce Help's Lookup Filters examples.

A Mention in the Developers Challenge

October 2, 2009 · Filed Under Development, X-Squared On Demand, salesforce.com · Comment 

The salesforce.com Developer Force Challenge has concluded, and the team of Force Squared and The Enforcer won a mention!

Our Daily Shinro site was listed “for sheer exuberance!”

I’m really proud of the site, though the lion’s share of the kudos go to John for the concept and site design. I just coded whatever he told me to code; he’s the creative one!

So if anyone is looking for a custom Force.com Site or website integration to Salesforce, contact us and let’s discuss your needs!