Posts tagged ‘@michaelforce’

June 14, 2013

Summertime & the Livin’s Easy

Yes dear readers, it’s true. Just as Jesus did with Lazarus, I am reviving this blog – and just in time to talk Summer 13! Normally, its the winter releases that I get all amped up about, but Summer 13 is packing some HEAT!

Click for the release notes

Click for the release notes

There are so many features that I want to discuss, that it was really hard to narrow it down for this post. Thankfully, I was given a chance to chat about some features on the ButtonClick Admin podcast yesterday, so I can use this post to talk about a few of the items that we didn’t have a chance to cover them.

read more »

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());        
March 18, 2011

Let’s make some magic…

Throughout my time using, I’ve been lucky enough to have tons of opportunities to network with other customers. One of the many patterns that starts to emerge is from new customers who are struggling to find a starting point. They hear others talking about all the cool & fun stuff they are doing, but have no idea how to have that ‘magic’ in their org.

Now, there are a lot of places to start, but one in particular has a “oooooo” factor in my opinion that gives it a real ‘magic’ feel – validation rules! These nifty little things hold a special place in my heart because they were the subject of the presentation I did the first time I was asked to speak at Dreamforce. (If you want to see that, it’s here – and I sound so totally terrified. How embarrassing!) The great thing about validation rules is that they are fairly simple to set up, have that wow-factor & most importantly, it touches on one of the biggest problems that all databases experience – data quality!

One of my most dreaded projects was when we did territory alignment, but our address data was so messy. My first venture into validation rules took a stab at cleaning that up. Here are some of the first validation rules that I created way back when…

Short & sweet, but it prevents people from marking deals as won with a closed date in the future. (Conversely, if you wanted to prevent people from marking closed won deals in the past, all you need to do is flip the > sign.):

AND((ISPICKVAL(StageName, "Closed Won") ),(CloseDate > TODAY() ))

Another simple one that was a huge win for us was the first step in rolling out approval processes. We had a roll-up summary field that calculated the maximum product discount. If that was over the allowable amount for our sales reps (10%), a checkbox that was only editable by managers must be checked. It was a very simple solution to a complex problem, but it was our first step in the right direction.

AND(Discount_Max__c > .1),(Approved__c = False))

One word of caution – validation rules make data loads & fast testing a pain in the butt. I found this out as we started heavily using them, and I asked Salesforce for a bit of assistance fixing this issue. I understand why my idea is problematic, so I came up with a solution on my own. SAFE HARBOR – use this at your own risk!

I added a field to the User record that is only editable by Sys Admins, called Exempt from V Rules. Then I appended all of my validation rules with the following:

$User.Exempt_from_V_Rules__c = False

Obviously these are a very small sampling of validation rules. A majority of the time, these are something really simple that have big wins. Since these first initial rules, the validation rules I’ve written have gotten more complex, and I always have to be aware that end users will search for ways to game the system, but they are a really great tool in the fight against bad data.

Special thanks to Michael for help with the formatting of this post!

%d bloggers like this: