Updates regarding the auto-activation in the behavior of getContent() and getContentAsPDF()

A few people have reached out to me regarding this. Back in Summer '15 there was a change to the behavior of both getContent() and getContentAsPDF(). At the time, we were told these updates would be auto-applied and activated in Winter '16. Salesforce has decided to push this auto-activation to Spring '16. See page 394 of the Winter '16 release notes.

The nice part of the postponement is that this release will be enhanced to allow them to be called in asynchronous Apex (pg 401)

Important note: Even when calls to getContent() and getContentAsPdf() aren’t tracked against callout limits, they’re still subject to the usual Apex limits such as CPU time, etc. These limits are cumulative across all callouts within the originating transaction.



Salesforce Lightning Experience Roadmap

Below (obviously subject to change) is the lastest Lightning Experience Roadmap.

Click to expand


Salesforce Spring '16 Preview Documents Here

Excited to see the new Spring '16 Preview documents are online. Some really cool stuff coming down the way and I recommend when you get a minute that you take glance at what is coming!

Salesforce Spring ’16 Release Notes

Download as a PDF here


Sign up for a Free Salesforce Wave Analytics Developer Account

I went to the Partner Forum the other day at part of the Salesforce World Tour here in Dallas. I've been working my way through Trailhead and absolutely love the concept. One of the things from Dreamforce this year that they went into was Wave Analytcs but I've just been so swamped that I haven't had a chance to deep dive.

Last night I decided I couldn't/shouldn't put it off any longer. In case you are wondering how to get started you go here:

Fill in this form and you're off to the races.

I then recommend you hop into Trailhead and start working on your

Wave Analytics Basics badge.

We're talking way cool here. The power behind Wave Analytics is insane. I've used probably 5 raw statistical programs in my career and another 3 full-blown BI solutions. This is by way the coolest thing I have seen this year. I'm going to be playing with this all weekend. I am blown away. Other vendors need to take notice.






What counts toward Salesforce CPU limits?

Once in a while you we all hit the following Apex CPU time limit exception. Example

System.LimitException: Apex CPU time limit exceeded


Most of the time when I see this and dig into it I'll find things like FOR loops inside of FOR loops (i.e. dream within a dream) or tons of workflows/processes being run before the code that threw the exception was even hit.

To start with let's just cover what counts against this CPU timer and why it is there. The CPU timer is there because Salesforce is a multitenant system. It has to serve many customers on the same servers so the governor limits are there to make sure one customer or block of code is not using up all the resources.

Counts Doesn't Count
Any Apex Code HTTP Callouts
Workflow Execution Database operations, e.g. DML, SOQL
Library functions exposed through Apex SOSL
Any time spent evaluating formulas for validation/workflows


As I said before, one of the biggest trouble spots I often run into is poorly written logic in formulas that eat up time.

One cool thing is that you can open the Developer Console and click on a specific execution. Click on one of the log entries and then switch the perspective to Analysis.

Salesforce Developer Console Switch Perspective

Next you will get to see some nifty tables, charts and graphs that will help you to really see how much of your CPU time is being used and being used by what.

Click to expand (Salesforce Dev Console Execution Timeline)


One great resource to have in your back pocket is if you don't need the code to execute at a given instance run it in a batch. i.e. Database.Batchable



Salesforce Winter '16 Limits Cheatsheet

Don't leave home without it. Each release Salesforce puts out, I always download the latest "Governance" guide to my desktop. Here is the latest one from Winter '16.

Winter '16 Salesforce Limits Quick Reference Guide (version 35)


CLEAN CODE - Apex Edition (Volume 2)

In case you missed Volume 1 of Clean Code - Apex Edition...

We'll start right back up where we left off with tips and pointers on how to make your code better, easier to manage and easier to read...

Method Length

In general, you want to keep methods as short as possible. Often times as we write code we find that the method becomes longer and longer and we can naturally just refactor the method into two or more. As Uncle Bob would say:

The first rule of [methods] is they should be small. The second rule of [methods] is that they should be smaller than that. - Uncle Bob Martin - Clean Coder

The goal is always to do one thing and do it well. That makes it easier to read, easier to troubleshoot and less susceptible to breaking as the code evolves.

Commented Out Code

Commented out code serves no real purpose. If you commented it out - you commented it out for a reason. Either you refactored something and wanted to make sure this code was no longer used or it was past its prime. The problem is that you are the one who commented it out and I bet you a nickel you won't remember 3 days from now why you did it. The code then gets checked in and guess what - nobody else will have the guts to ever remove it. They will think "oh man, this is probably too important to delete, someone must be using it or intends to finish it." Every time anyone sees it they waste brain cycles thinking about it.

Approach 1 - Delete it and know that it is there is source control one revision back (hopefully you're using source control)

Approach 2 - When I comment out a variable or a block of code I put my initials next to it with a comment that says something like:

//SFG - commenting out as this has been refactored - if still here on July 30th, 2015 please delete

Then as part of my code review and check-in routine I made aware of those things. Many time it is as simple as variables that are defined that are never used. Methods that have since become redundant but they still clutter the code. Get rid of them!

Code Commenting

  • Avoid obvious code comments as they just clutter things up and add waste. Take the example below

//deletes the employee passed in

public Boolean deleteEmployee(Employee emp)

So how does the above help anyone? It doesn't. In this case there should be no comment or give more details about what happens - is it a soft-delete, what happens if it fails, etc.

  • Along the same lines (or at least related) - when you checking your code to Source Control (SVN, TFS, whatever) - put some true comments in there about what changed, why etc. I use Jira as my ticketing system so the first thing I do is preface every checkin with the Jira ticket #. That way a year from now, someone can not only go look at Jira and see the original bug or feature request but they can then tie it back to to my checkin. One of my pet peeves is when people checkin 10 files at a time and put the same comment for all of them "fixed some bugs". Really? Thanks - that is a big help. Now I need to go diff those 10 files and figure out which one(s) had anything to do with the original request(s).  It just goes back to the Boy Scout rule - leave the code in a better place than we you found it.


DRY Principle

The goal of your code is to not repeat yourself. If you are repeating yourself that is your first and best clue there is a better way to do this. The DRY Principle states (snippet from Pragmatic Programmer: From Journeyman to Master):

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system



Clean Code - Apex Edition (Volume 1)

A lot of the thoughts, ideas and suggestions below come both from Salesforce documentation, computer legends like Uncle Bob Martin, Martin Fowler and just general experience. I've done my best to credit these sources both in the article and in the references section. If I have left anyone out, it was not intentional - just post a comment and I'll get it updated. This is Volume 1 of a series.

Triggers (one per object and have only a handful of code)

  • Only use one trigger per object. Obviously if you install other apps, they come with their own triggers but just from a debugging and readability standpoint - use one trigger per object.
  • DO NOT put logic in your triggers - triggers should be used to manage execution order and delegate all else.
  • You can never know or guarantee which order a trigger gets executed in, it is therefore much easier to manage/debug flow when you are only looking at one trigger.


Kevin O'Hara (super genius and MVP) has an awesome resource here on Github showing a trigger and a triggerhandler.

Class Names

Ever looked at code someone else has written or even better, you wrote 6-8 months back and try to make sense of it. It can be hard - especially if you have the added pressure of needing to fix something fast. As Uncle Bob says "clarity is king". Classes and object for that matter should use nouns or a noun phrase as their name. Examples: Employee, HelpPage, Customer, ZipCodeParser. Remember from grammar school that nouns represent things. 

A class name should not be a verb (verbs are for your method names).


Method Names

Class names start with nouns or noun phrases. With Method Names we want to use verbs (word used to describe an action, state, or occurrence). We can also use verb phrases. Examples:  deleteEmployee, setName, getName


You've got a great sense of humor (or at least you think you do). Don't put it in your code.

Don't give your variables, methods, classes cute/funny names. Don't use slang. The same goes for code comments - be professional. I can't tell you how many times I look at code and see comments in try/catch blocks that says "if we got here, something went wrong". Thanks, that was a big help in figuring out what the problem was. 

I've seen good programmers that use code comments while they develop and troublehsoot. Anything they don't want to get checked in or was meant as just a reminder they put their inititials in front of. For example:

// SFG - need to understand why this list is being populated and never used anywhere

Before checking in the code you just do a quick search for "SFG" and if you still have those in there, you're not done - or you need to create work items or tickets to come back and review those things. 



When to use SOSL vs SOQL in Salesforce

Both SOQL and SOSL are extremely powerful query tools in Salesforce but they have different uses. In this article we'll explore what these two query languages are best suited for and how to take advantage of them. First let's start out with some simple definitions.

SOQL (Salesforce Object Query Language)

If you are at all familar with SQL (Structured Query Language), SOQL is very similar to SQL in that you use to a SELECT commond to speficy a source object (example Lead), a list of fields to grab, and the conditions for selecting the rows.

Select Id, LastName, FirstName, Company, Email from Lead where email = ''

Just like any database, Salesforce uses indexes to make queries return results faster. SOQL and SOSL use different indexes.

What are some common indexes that can be used to make a SOQL query more efficient? Answer:

  • Primary Keys (Id, Name, Owner Fields)
  • Foreign Keys (lookup and master-detail relationship fields)
  • Custom fields marked as External ID or Unique - often times these are used to tie Salesforce records to external systems.
  • Audit Dates (i.e. LastModifiedDate)

Fields that CANNOT be indexed (and part of the reason SOSL is important) include:

  • Long text fields
  • Multi-select picklists
  • Binary fields (i.e. file, blob, encrypted text)
  • Currency fields (when multicurrency is enabled)

SOSL (Salesforce Object Search Language)

SOSL is used to construct text searches. SOSL's true power is that it enables you to search text accross multiple objects whereas SOQL is just a single object. Example: 

FIND {Salesforce General} IN Name Fields RETURNING lead(name, phone)

When to use SOQL
When to use SOSL
You know which object, fields you want to retrieve
You don't specifically know which object or field the data resides in but you need an efficient way to find the records
You want to get a count of the number of records that meet a specific criteria. i.e. where OwnerId = X
You want to get data from multiple objects and field in the most efficient way - the objects may or may not be related to one another.
You want to sort the results as part of the query
As described above when you are trying to query data in fields that cannot be indexed yet you have a large data
You want to get data from number, checkbox or date
You want to get data from a single object or multiple objects that are related to each other (i.e. Accounts and Contacts)