Difference between 15 and 18 character ID’s and history of why they both exist


If you have any data updates, integration, formulas using something like ProfileID, or just simply noticed a bunch of characters in your salesforce.com URL when you are reviewing a record then you might know there is a 15 character ID and an 18 character ID. But what is the difference? And why two ID’s?

The 15 character ID is what you will see when you view the URL. Go to an Account and you will see this; for accounts they start with 001. This ID is case-sensitive (I will go more into that later). The 15 characters are completely unique in your salesforce.com instance, when case-sensitive.

The 18 character ID is seen when you, for example, use a tool like Data Loader to extract your data. The first 15 characters are exactly the same as what I wrote above, but with an additional 3 characters. This ID is case-insensitive. The 18 characters are completely unique in your salesforce.com instance, when viewing as case-sensitive or case-insensitive

What does all this case-sensitive or case-insensitive mean? Basically case sensitive means that ABC, aBc, and abc are seen as unique. Case-insensitive means that ABC, aBc, and abc are seen as the same. Databases are can be setup to be case-sensitive or case-insensitive.

Now to a bit of a history lesson to show why salesforce.com has both 15 and 18 character ID’s. Salesforce.com is built on Oracle databases and Oracle is good as default to case-sensitive for databases. Salesforce.com has great developers and used this case-sensitive database approach. I do not know the math but I know the 12 unique characters (not 15, since each ID starts with 3 characters of the object they are in…ie: Accounts = 001) gives for trillions of records without issue of running out of unique ID’s for each object.

Wait, if I can have trillions of records on each object with the 15 character case-sensitive ID why is their this 18 character ID? When salesforce.com first started out there was no API yet. The API came, I believe, towards the end of 2002 / beginning of 2003 (I could be off a bit). Before the API existed ID’s were not that important to customers (a bit but not like now). When the API came out customers started integrated data with salesforce.com, led to running updates against data instead of just importing data, using Excel VLookups (don’t laugh, that is what we did a lot in the olden days) or external databases to match data for updates, deletes, analysis, etc… If you play with data you might be seeing where this is leading. Salesforce.com didn’t have an issue but external systems/applications did.

Many databases are setup as case-insensitive. Excel VLookup and other functions are case-insensitive. Some development languages are case-insensitive.  Etc…etc… The more data you have in a salesforce.com object you have a greater chance of have two ID’s that were the same when viewed as case-insensitive. I encounter this often. Because of this salesforce.com had to add something so people/tools/applications that were case-insensitive could see each ID as unique and able to update data to the correct ID. So salesforce.com added the 3 extra characters to the end of the ID, and now every 18 character ID is completely unique when case-insensitive.

So that is about it. This is why you see both a 15 character ID and an 18 character ID. All about case-sensitivity.

TIP: If you export data from reports and you want to make sure the ID’s are unique you can use the CASESAFEID() function. Basically create a custom formula field on your object.You don’t need to display the field on your page layout. All you will do is use this field when exporting or needing the 18 character ID instead of the 15.

Contacts without Accounts report


NOTE: This page was updated on 1/16/2014. Steps 8 through 10 are not needed. Thanks to Ravi Kumar for pointing out the issue and Thomas Taylor for pointing out those steps are not needed.

On the Success Answer Site many ask how to create reports to show records that do not have a record in a related object. Salesforce.com came up with a great addition to reports called Cross Filters. Very quickly and easily you can say “Show me records WITHOUT data in this object.  Works great.

But one question that comes up a lot is how do I show contacts that do not have an account associated with them. People normally go to create a new report and choose Contacts & Accounts as the report type. Then choose a Cross Filter. But this does not work. It will not show you only Contacts without Accounts.

What you can do is create a custom report type and then report off of this. These are the steps.

  1. Go to Setup–>Create–>Report Types
  2. Click New Custom Report Type
  3. Primary Object will be Contacts
  4. For Label and Description give these names/description that you will remember.
  5. Store in Category should be Accounts & Contacts.
  6. Choose Deployed
  7. Click Next
  8. Click the link “Click to relate another object”
  9. Choose Accounts
  10. Choose ” 
  11. Click Save
  12. Click the Reports tab
  13. Click new Report
  14. Click the plus by Accounts & Contacts, then click on the report type you just created (step 4 is where you named it)
  15. Click Create
  16. For Show click the drop down and choose All Contacts
  17. Remove any dates from your Date Fields
  18. On the left navigation find the Contact folder and right under that is Account Name: Account Name. Drag this field into the filters area.
  19. You will see three boxes.  Keep the first two the same and leave the third box blank.
  20. Click Ok.
  21. It should now say  –  Account Name: Account Name equals “”
  22. Click Run Report.
  23. Presto. Contacts without Accounts

Hope that helps some. Leave comments below if you have any problems or know of a better way to do the above.