Entries in Apex. Salesforce (21)


Three Common Apex Coding Topics

If you're an admin of a big Salesforce org, then you probably had some users complain about unfriendly errors. If your Salesforce org is in any way customized then those errors are likely related to performance issues in the custom Apex code. Although custom Apex code can be powerful, it can sometimes hinder the overall performance of your Salesforce org. Today, I'm going to introduce three changes you can make in Apex Code that will improve the performance of your Salesforce:


Enhance Validation and Workflow Rules:

One example of the errors your users might get is one that includes FIELD_CUSTOM_VALIDATION_EXCEPTION. This error usually means that you have a scheduled batch that inserts/updates records without fulfilling a Validation Rule(s). Here are a few areas you can improve performance:

  • If you have a batch class, make the class calls a DML operation and that opt_allOrNone is set to False. This will allow the rest of the operation to still succeed even if the record fails.
  • Workflow Rules are most helpful in preventing duplicate records. If you have a lot of Workflow Rules in your org, you can cut down unnecessary processes by deactivating the Workflow and improving the Trigger to do the Workflow Rule'sjob.
  • Review Validation Rules with management and make sure they are necessary to fulfill business logic. Having too many validation rules and required fields can cause unit tests to fail, which will then prevent you from deploying a change set.

Increase Field Length:

If, for example, you have a Trigger that populates values larger than the field length, then you'll most likely get a STRING_TOO_LONG error message. One thing you can do here is to increase the Field Length; it is better to have a large value than getting an error message.


Rectify API Limits:

If your org has a lot of integrations with third party apps and that those integrations are used frequently, your users might then see a "REQUEST_LIMIT_EXCEEDED" error. There's no ideal solution to reducing API usage, but one thing you can do is to evaluate the current API usage in your org (SetupAdministration SetupCompany ProfileCompany Information) and figure out a way to reduce and disperse the number of API calls.


It is always a good idea to periodically review the current custom Apex Code you have in your org with management and stakeholders. Making these changes will not only cut down the number of errors your users encounter, but will help improve the performance and the overall user-experience in your Salesforce.


APEX: Retrieve a Custom Object Field's History

Let's say you have the field "Address" in a custom object labeled "Customer" and you're looking to obtain that particular field's history and tracking details along with the dates on which changes were made. Today, I'll share a query that will help you do just that:


SELECT ParentId, OldValue, NewValue, Field, CreatedById, CreatedDate FROM Customer_History where parentId = :CustomerId and Field ='Address__c'

About SQQL Select 

Salesforce’s Apex SOQL uses the following Syntax for the SOQL Select statement:

SELECT someField
FROM someObject
WHERE someCondition

Here's some helpful tips on
SOQL’s SELECT statement:

  • The syntax is not case sensitive, for example: SELECT = select.
  • Currently, SOQL statements cannot exceed 10,000 characters, but the good news is that Salesforce has promised to raise the limit to up to 20,000 characters, soon.
  • The result is stored in a result table, called the result-set.
  • Results are generally not ordered unless you use an ORDER BY clause in the query

Eloqua to Stay Friendly with Salesforce

After having been acquired by Oracle, Eloqua is said to have even tighter integrations with Oracle’s sales, service, and social apps. When Oracle acquired Elqoua back in December, customers were nervous and weary that Eloqua might not play nice with apps/platforms it currently integrates with.  However, on Monday, Oracle’s Applications Executive Steve Miranda and Eloqua CEO Joe Payne confirmed that preexisting integrations with third party apps/platforms, like Salesforce, will not be subsequently harmed.

“We’re also working with Microsoft Dynamics and even SAP, where we’ve built two integrations for new cloud applications in just the last three months,” Payne said. After this integration, customers will be able to use Eloqua with Oracle Social Suite and Oracle Social Marketing for launching campaigns on Facebook and other social media platforms.

“We aim to be the destination where marketers maintain all their buyer profile information and keep it up to date… If we can capture more information, we can help our customers know their prospects and customers better and build better-targeted marketing campaigns.”


Add a Signature to Your Salesforce Email 

in Salesforce, you can add a text signature to your emails by going to Your Name> Setup> Personal Setup> Email> Email Settings> Signature. 

This email signature, which will be inevery email sent out of SFDC,  is only text. Alternatively, you can add a signature section in HTML via an email template. 



Chipper about Chatter Enhancements

Salesforce Spring '13 releases

There's a slew of new stuff coming to Salesforce Spring '13 release, and one of my favorite updates in the Chatter department. Here's a few of the highlights I thought you'd like to know about:

Chatter Tasks – This is great and seems a little bit more in line with how other task management apps work with inline tasks.  This functionality will...

1. Auto post your tasks related to Accounts, Contacts, Opportunities, and more directly to the Chatter feed so you can have a better understanding of all communication and activity connected to that record 

2. Allow you to create a Task directly ( and quickly!) from a Chatter post.  Instead of filling out a complicated form, just type the gist and move along.  What awesome functionality!


Some Other Minor Chatter Enhancements – Easily search through Group posts, make posts to Public Groups even if you aren't a user and a smaller chatter messenger box has been made when minimized.


Configuring State & Country Picklists

in Salesforce Spring ‘13

Well, Salesforce finally did it. They’ve introduced State and Country picklists to their 2013 Spring release. Phew! No more messy (and often erroneous) text-entry fields. These picklists will allow you to choose a state and country based on a selection in a dropdown menu.

Hold onto your party hats though because it’s not as easy to implement as you might think. You’ll need to do a little behind-the-scenes work to configure state and country picklists so that they work in your organization.

First things first. You’ll need to configure the picklists in the Metadata API and then scan your organization to see where text-based state and country data is used. Next you’ll convert your existing data and fix the existing customizations so that they play nice with the new, standardized values. Finally, you can enable the lists for your users.

The State and Country Picklists page in the Data Management area of Setup is where you’ll spend most of your time preparing your organization to use the picklists. Thankfully, the process is outlined and most of the steps can be executed right there. You can also click “Help for this Page” to get the full documentation for the feature.

The most obvious step for administrators is configuring the picklists in the Metadata API. Using the IDE, you’ll need to edit the AddressSettings metadata component, which is new in Metadata API 27.0. AddressSettings allows you to control which picklist values appear in the Salesforce UI and how to map existing, text-based state and country values to new the picklist values, making the convert process using the address conversion tool in Setup a breeze. The AddressSettings component has four fields for each state and country you enable, and it will look pretty similar to this abbreviated example when you’ve configured them:


<?xml version="1.0" encoding="UTF-8"?>


<AddressSettings xmlns="">








<integrationValue>United States</integrationValue>




<label>United States</label>













































Have fun with the new picklists feature and check back with us for more news soon!


Apex Unit Test



I’ve been developing code on various platforms for years, but lately I’ve been working on Saleforce’s proprietary language apex.  If you know java then apex should not be that strange to you at all.  That is pretty much where the similarities end.  Being a cloud based company, Salesforce enforces all sorts of rules and limits on your code. You’ll quickly learn how to be a smarter developer when you have to think about these limits. 

 Salesforce requires that you have 75% coverage on all code you write.  If you fall below this number then you cannot deploy any of the code you have written.  Coverage just means that if you have piece of code that says “hello” you must test it and verify that it says hello.  If not, every line is counted against your overall number.  You cover your code by writing the infamous unit tests.

Rewind to last month and it is really easy to forget or ignore writing test cases.  You can only get away with this for so long before your coverage starts gradually depleting.  After much effort I did a good job addressing a lot of missing coverage.  One thing that became really evident is that I was failing to do a negative test.  A negative test is just what it sounds like.  You pass in junk data and expect a failure.  This proves that your code not only works, but it handles exceptions correctly.  Below I have some sample code that illustrates both a positive and a negative test case.


           static testMethod void testremoveFormulaFieldsSchema()



              //Negative Test of formula field schema

              Map<String, Schema.SObjectField> targetSchemaFieldMap = null;

              targetSchemaFieldMap = removeFormulaFieldsSchema(targetSchemaFieldMap);

              system.assert(targetSchemaFieldMap == null, 'We did not get a null schema ');


              //Positive Test of formula field schema

              targetSchemaFieldMap = Schema.SObjectType.Account.fields.getMap();

              targetSchemaFieldMap = removeFormulaFieldsSchema(targetSchemaFieldMap);

              system.assert(targetSchemaFieldMap != null, 'We failed to get the account schema ');



As you can see above I call the same method “removeFormulaFieldsSchema” in both scenarios but in the first test I am passing null as a parameter.  This will test our code on how I handle exceptions and I expect nothing back after the code is executed.  In the second example I would expect data to be returned to me.  I also included the actual method I was testing for clarity below.  These two tests gave me 100% coverage in my new method and I was a happy person.


       public static Map<String, Schema.SObjectField> removeFormulaFieldsSchema(Map<String, Schema.SObjectField> schemaMap)


         Map<String, Schema.SObjectField>  resultschema = new Map<String, Schema.SObjectField>();




                for(String field : schemaMap.keyset())



                  Schema.DescribeFieldResult desribeResult = schemaMap.get(field).getDescribe();


                  if (!desribeResult.isCalculated())


                    //Field is not a formula field so it is added to the schema.

                    Schema.SObjectField fieldS = schemaMap.get(field); 




                 return resultschema;

              }catch(exception e)


                     return schemaMap;



I hope this helps some apex coders out there to understand the importance of getting your unit test written with your new code.  It was a lot of effort to go back and fix all the omissions but it paid off.  I even found some bugs in the code that I didn’t expect.  Who would have thought that unit testing actually works and isn’t just some evil chore Salesforce imposes on us.


photo credit: <a href="">epospisil</a> via <a href="">photopin</a> <a href="">cc</a>


What Salesforce Objects Support Apex Triggers?

If you’re running Unlimited, Developer, Enterprise, or editions of, you can use Apex Triggers to execute before or after a database insert, update, delete, merge, upsert undelete, or any combination thereof. allows for Triggers for many standard/system and custom objects. However, not all System Objects support Apex Trigger. Below is a list containing commonly used System objects: