Comparable: Sorting Objects in Salesforce

The Comparable interface adds sorting support for Lists that contain non-primitive types, that is, Lists of user-defined types.

To add List sorting support for your Apex class, you must implement the Comparable interface with its compareTo method in your class.

When a class implements the Comparable interface it has to implement a method called compareTo(). This method returns an Integer value that is the result of the comparison. In that method the code has to be written to decide if two objects match or if one is larger than the other.

The implementation of this method should return the following values:

  • 0 if this instance and objectToCompareTo are equal
  • > 0 if this instance is greater than objectToCompareTo
  • < 0 if this instance is less than objectToCompareTo

Let’s take a look at a simple class that takes in an Employee object, stores the employee’s data in it and allows us to sort a list of Employees by their Employee Id.

Apex Class:

public class Employee implements Comparable {

    public Integer Id;
    public String Name;
    public Decimal Salary;

    public Employee(Integer i, String n, Decimal s) {
        Id = i;
        Name = n;
        Salary = s;

    public Integer compareTo(Object objToCompare) {
        Employee emp = (Employee)objToCompare;
        if (Id == emp.Id){
            return 0;
        else if (Id > emp.Id){
            return 1;
            return -1;        

Execute the below code in Developer Console.

List<Employee> empList = new List<Employee>();
empList.add(new Biswajeet.Employee(104,'John Doe', 5000.00));
empList.add(new Biswajeet.Employee(102,'Joe Smith', 9000.00));
empList.add(new Biswajeet.Employee(103,'Caragh Smith', 10000.00));
empList.add(new Biswajeet.Employee(101,'Mario Ruiz', 12000.00));

//Sort using the custom compareTo() method

//Write list contents to the debug log
for (Employee e : empList){


ISBLANK and ISNULL with a Rich Text Field is not working in Validation Rule

Using ISBLANK or ISNULL with a Rich Text Area field always returns true when used in a Validation Rule.
To check whether a Rich Text Area field is empty, use the LEN function.

LEN (Rich_Text_Field__c) = 0

Remove the Salutation, Middle Name and Suffix Fields

Salutation field is Mandatory and cannot be removed from the Layout.
Middle Name and Suffix can be disabled by following these steps:

  • Click Setup || Customize || User Interface.
  • In the Name Settings section, deselect Enable Middle Names for Person Names and Enable Name Suffixes for Person Names.
  • Click Save.

The Middle Name and Suffix fields are available for the following person objects: Contact, Lead, Person Account, and User.

The values of the Middle Name and Suffix fields appear in most places where a person’s full name is displayed with the following exceptions.

  • Activities, including new events, new tasks, and shared activity lookup search results
    Calendar, including meeting invitations and the Scheduled Meetings section on the Home tab
  • Campaigns, including Campaign Member lists
  • Chatter
  • Cloud Scheduler
  • records
  • Forecasts, including the Collaborative Forecasting page
  • Opportunities, including opportunity stage history, the Opportunity Sharing Detail page, and the Opportunity Split Edit page
  • Price Books, including price book history
  • Recycle Bin
  • Search results for users

Authorize a Deployment Connection For Change Sets in Salesforce

Deployment Connection:

A deployment connection is required between two Salesforce orgs to send change sets from one org to another. You can’t create deployment connections between arbitrary orgs. Instead, you create connections between all orgs affiliated with a production org.

For example, if you have a production org and two sandboxes, a deployment connection is created between production and each sandbox. Also, a deployment connection is created between the two sandboxes.

A deployment connection alone doesn’t enable change sets to be sent between orgs. Each org must be authorized to send and receive change sets. This added level of security enforces code promotion paths and keeps orgs’ setup metadata from being overwritten by mistake.

In the following figure explain one possible migration path for a production org (Prod) and two sandboxes (Dev and Test). In this example, the production org can only receive changes that have been fully tested, so only the Test sandbox is authorized to upload change sets to production. To synchronize development projects with the production org, the Prod org can send change sets to the Dev sandbox, but not to the Test sandbox. Finally, because the features in development need iterative testing, Dev and Test sandboxes should be able to send change sets back and forth.

Authorize a Deployment Connection:
Before you can receive change sets from a sandbox or other organization, authorize a deployment connection in the organization that receives the changes.

Click Setup || Deploy || Deployment Settings || Click Continue || Click Edit next to the org you want to authorize

Select Allow Inbound Changes || Save

After authorize the Deployment Connection: