Force.com uses two types of IDs, 18 character and 15 character. When we use the ID from the URL it is 15 characters, however, when we use the data loader we get 18 character IDs.

The 15-character ID is case sensitive while the 18 character ID is not case sensitive. The 18-character ID is used to migrate data from legacy systems or spread sheets, which do not recognize case-sensitive IDs. Both the IDs work with Force.com and point to the same record. However, if we are to migrate data from the spread sheets or export data to the spread sheets we have to use 18-character IDs.

There are three ways of getting the record ID, they are as follows:

URL and report will always return the 15-characters IDs while the data loader and the API return the 18-digit IDs. API, however, accepts both 15-character and 18-character IDs.

Let us now explore what we can gain from IDs in the URL.

The easiest way to study the record ID is by understanding the standard Salesforce objects. These IDs are fixed and are of similar format across the Salesforce organization. Every custom object will have a fixed pattern, but will be unique to individual organizations only.

For the purpose of an example we will study the record ID of opportunity object. Open an opportunity record as shown in the following screenshot:

The record ID is seen in the address bar of the browser as shown in the following screenshot:

Let's observe the format of the URL of the address bar carefully, the URL is made up of different things as shown in the following screenshot:

Let us now look at the different parts of the URL separated in the preceding screenshot.

One important thing to note is that the record ID is case sensitive. So 00690000003zRfq is not equal to 00690000003ZRFQ. There will be a unique ID per organization, no two records will have same ID. When we migrate data from one organization to another, the IDs are changed. The record ID is further split into two parts as shown in the following screenshot:

The first three characters of the record ID are the object identifiers, which help us to identify the object of the record.

The remaining characters are the unique record ID to identify the record. All the objects thus have three-character encoded ID, which is a prefix to their record ID elsewhere.

The following table shows us the three character prefixes and the objects that they are associated with:

These prefixes for the standard objects are the same across all the Salesforce organization. Now let's play with the URL a bit. If we wish to land on the list view of the standard object, all we need to do is append a /o against the object prefix example for the account object we need to add 001/o.

The final Salesforce URL in this case would be:

This will open the list view or the tab view of the object, similarly we can change the prefix to any standard object.

When we change the /o to /e it automatically opens the edit page for a new account:

This will open the edit page for the account directly. If we add the /e in front of a record ID, we get the update detail page for the record, for example, let's say we want to open the opportunity edit page from our original example.

Now if we add the /e in front of the URL, we get:

This will automatically open this opportunity for editing; try adding a /e against any record URL and we will get the edit page for the record with all the existing data pre-filled with information.

Only when we create the full-copy sandbox of the production organization, do we get similar IDs in productions and sandbox only once.

Record ID in the field is not editable even in code. We cannot include it in DML for insert, but will be useful for DML of update and delete.

Let us recap some important points we learned about record IDs: