I was working with some colleagues this morning who had a requirement to send an email using the email template functionality, but wanted to access data from a grandchild object (so Parent Object-->Child Object-->Grandchild Object). At first glance the UI only allows you to select fields from the Parent or Child object, but fear not --- you can supercharge your email template merge fields with just a little extra effort.

Take the example of a school which has an Enrollments object which is related to Classes via a Master Detail relationship. Classes have a similar relationship with Venues (a class has to be held somewhere), but an Enrollment really shouldn't have any sort of relationship with a Venue (thats the classes responsibility). To make things easier we may model this the Class-Venue relationship in another custom object, we could call ClassVenues:

With our newly discovered superpowers in the Email Template, we can easily traverse the new relationship to send our student all the details they need to make it to class right on time. The trick is writing the merge field yourself. You can use the Available Merge Field picklists as a start, but you have to manually add the grandchild relationship. For this example the following code works great:

{!Enrollment__c.Class__c.Venue__c.Building__c}

Now if only I could get fix the 'dog ate my homework' problem :)

Every programming environment has a set of constructs, features and constraints.  These may vary but in every programming environment, the programmer has to consciously manage resources.  These resources could be memory, socket connections, file descriptors etc. - I remember coding in C++ where bad memory (heap) management could bring the entire program crashing.  Java provided better built in support for this aspect but the programmer still had to work within the constraints of the actual heap space available and ofcourse manage the other resources like socket connections, threads etc. 

How does all this relate to Force.com? Your Force.com program runs with all the other programs in a multi-tenant environment where all the resources (memory, network, database connections etc.) is being shared with every other program.  Thus it is very important that the platform not let a badly written program hog all the resources and affect the performance of all the other programs running on the platform.  Force.com does this via governors - when a program exceeds its allocated quota for some resource, an exception is thrown.  To be a good Force.com programmer you need to understand this well - think of the governors as helping you with resource management.  Andrew Albert has written a great article on governors, read it to get started on the way to write efficient, scalable programs on Force.com.  Happy Holiday!

Are you a new Force.com developer? About to write your first Apex trigger or class? Or already developed some Apex just to run into a governor limit? Want to learn more about governors in Apex?

If so, check out this new technical article that explains what governors are, why they exist, and how they are calculated. The article is intended for architects and developers writing Apex code on the Force.com platform. Here is a brief snippet from the Abstract:

This is where Apex governor limits come in. Governor limits are runtime limits enforced by the Apex runtime engine to ensure that code does not misbehave. This article presents an overview of Apex Code governor limits, why they are important, and how to design scalable, efficient Apex code.

If interested in reading the entire article, it can be found here.

One of the great features of the Force.com platform is the ease at which you can meet auditing requirements such as field history tracking. With just a few clicks you can add history tracking to most standard objects, and any custom object. And because everything on the platform is metadata driven you can access this same field history information through the API:

	SELECT OldValue, NewValue, Parent.Id, Parent.name, Parent.customfield__c 
  FROM foo__history

For a standard object, you could use a query such as:

	SELECT OldValue, NewValue, Parent.Id, Parent.name, Parent.customfield__c 
  FROM ContactHistory

I had a customer query this morning asking about Opportunity field history, and access through the API. Naturally, your first instinct is to look for an OpportunityHistory table, which certainly does exist; But Opportunities are a special case, it seems, when referring to field tracking. The OpportunityHistory table stores a record of how a particular Opportunity has progressed through the various stages of it's lifecycle.
I did a little digging, and if you want to access field history tracking for Opportunity you need to use the OpportunityFieldHistory table instead:

	SELECT OldValue, NewValue, OpportunityId FROM OpportunityFieldHistory

 

It's a small tip, I know --- but sometimes these are the best ones.