Entries in Apex (19)


Asynchronous Apex on Trailhead

This is one of the best charts or cheatsheets I've seen to show scenarios in which to use


How do I change who gets Apex Error Emails?

I got this question a few times at Dreamforce this year so I thought I would quickly cover it. If you don't want all the System Administrators to see this or would just prefer a specific user(s) get the details there is now an easy way to do this.

Go to Setup and run a quick search for "Apex Exception Email"

Quick Search for "Apex Exception Email"

In the expanded section click on "Apex Exception Email"

From here you can choose either a Salesforce user or users and/or to a non-Salesforce user email.



Salesforce Record Size

As a general rule of thumb - regardless of whether you have 10 fields on an object or 80, Salesforce allocates and estimates 2k for more records. This is all about both performance, governor limits and your storage limits. To learn more check out KB 000193871

Below is a breakdown


Leads -- 2KB
Contacts -- 2KB
Accounts -- 2KB
Person Accounts - 4KB
Opportunities -- 2KB
Tasks -- 2KB
Forecasts -- 2KB
Events -- 2KB
Cases -- 2KB
Case Team Member – 2KB
Solutions -- 2KB
Notes -- 2KB
Custom Reports -- 2KB
Tags: unique tags – 2KB
Campaigns - 8KB
Campaign Members – 1KB
Contracts – 2KB
Google Docs – 2KB
Quotes – 2KB
Custom Objects – 2KB
Quote Template Rich Text Data - 2KB
Articles - 4KB


Person Accounts - You need to keep in mind that with Person Accounts there is an account record and a hidden Contact record associated with it and that is why it is double that of a lead or an account.

Email Messages - This is primarily up to the content size and is a 1 to 1 ratio. 100kb of content takes up 100kb of data storage space.

Note when testing - I really encourage my friends (and anyone who will listen) to take the time and add a few hundred fields to leads, contacts and accounts and make sure you test your code against it. Obviously the more fields you bring back in a SOQL query the more memory and CPU time you are going to use but the point is you want to be prepared for that down the road. 




Local Timezones Now in Debug Logs

One of the things that I've been advocating for the last few years is to show my actual time zone in the debug logs. When you're trying to solve a problem and really honed in it, it is a pain to constantly translate back and forth to GMT. I am super excited and have been the heck out of the new enhancement so my hat goes off to the Salesforce dev team. LOVE IT. If you look at page 345 of the Summer 16' Release notes PDF you'll the same image below. 


10 Principles of Apex Testing (by Salesforce)

I actually just watched this the other day for the first time when thinking of topics for the Dallas Salesforce Developers User Group or as we just say #sfdug.

I highly recommend this one to those getting started or just trying to brush up on skills.

Like it or not, testing your Apex code is a requirement for deployment. Often it seems developers are frustrated with testing because it seems like a platform imposed chore, rather than a useful software development tool. Apex developers can harness testing as a way of improving software quality.

Find it here:

You'll find both the webinar format and the slides.



Salesforce Lightning Experience Roadmap

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

Click to expand


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.