Archive for May, 2011

May 27, 2011

An elegant solution

While we all have different titles, what this Salesforce admin/developer job really entails is “Problem Solver.” Some of the solutions are slick & cool, others are a bit messy but get the job done. Usually the person with the problem doesn’t really care so much how it gets fixed, so I was surprised the other day when someone commented on how elegant my solution was. To me, it was fairly basic stuff, but the more I thought about it, I realized that it was something pretty clever that I had come up with.

What exactly did I do? I should start with the business problem. Without going into too much detail, we have leads assigned to a queue & the business wanted a sales rep to actively accept or reject the lead before working it, and also capture some key data points at the time of acceptance or rejection.

Now, the fun part – how I solved the problem. I created a new record type, and made it the default. I create a page layout with only key fields displayed & the only buttons that exist are the ‘Accept’ and ‘Reject’ buttons. “What are the ‘Accept’ and ‘Reject’ buttons?“, you may be asking. Pretty simple – a clone of the “Edit” button, except the are passing a value into a field on the record. This passing of a value allowed my to write validation rules to conditionally require data based on whether the lead was accepted or rejected.

So far, pretty cool, but nothing amazing. But wait! There’s more! Once the user is done editing the record & hits “Save”, a workflow rule fires (based off the accept/reject field containing a value) and a field update occurs. Still pretty simple, right? Well, the slick part comes in that the field that gets updated is the Lead Record Type. (Ta-daaaaaa!) The record saves & then the user is presented with the standard lead layout with all the fields, related lists, and other bells & whistles they were used to having.

Magic transformation – all in a day’s work for a salesforce admin!

May 13, 2011

Trigger Happy!

I talk a lot about the ‘auto-magic’ in, but we all know it has it’s limitations. One of the things that I always wished could be done with button-clicking was to create a new record when conditions on another record were met (ya know, using some workflow powers). I really just considered myself out of luck.

That is until I started dabbling in the developer world. And while I consider myself knowing just enough to causing catastrophic damage, a business case presented itself in which trying out my new skills was the perfect fit. In short, the team wanted a record auto-created every time a specific type of event was created.

Here it is, my debut into triggers (excluding my copy-edit-paste of one from MichaelForce):

trigger createPDtask on Event (after insert) {     
List<Support_Request__c> sr = new List<Support_Request__c>();
    for (Event newEvent: Trigger.New)
         if (newEvent.Type__c == '1. Meeting - Initial'){
                 sr.add (new Support_Request__c(
                     Name = 'New PD',
                     Task_Type__c = 'PD',
                     SFDC_Record_ID__c = newEvent.Id,
                     Rep__c = newEvent.OwnerId,
                     Event_Date__c = newEvent.ActivityDate));   
   insert sr;

So there it is. Short & fairly simple, but a HUGE productivity win. Plus, now everyone thinks I’m magic! And if you want a deeper dive explanation on the anatomy of this trigger, read my post on the Teach Me Salesforce blog!

UPDATED!! Here is my test class (Huge thanks to Kyle for help with the System.assertEquals bit:

@isTest private class createPDtask_Test { 
   private static testmethod void testTriggerForEvent(){         
 Event e = new Event();   
 //Required Fields         
 e.Subject = 'testSubject';         
 e.IM_Type__c = '1. Meeting - Initial';         
 e.Product_Interest__c = 'None';         
 e.StartDateTime = DateTime.NOW();         
 e.EndDateTime = DateTime.NOW()+1;                  

 //Insert the Record         
 insert e;                  

 //Query for Inserted SR         
 List<Support_Request__c> testRequests = [SELECT id FROM Support_Request__c             
 WHERE SFDC_Record_ID__c = :e.Id];                      

 //We expect one record to be created         
 System.assertEquals (1, testRequests.size());        
%d bloggers like this: