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.

Salesforce.com Nostalgia – No API, No Problem


This morning I was “cleaning up” some very old folders and files. I came across a 2002 document for a salesforce.com implementation that I was involved in.  For those that haven’t been around salesforce.com that long, which is by far most of you, salesforce.com was a bit different back then. Salesforce.com has grown incredibly. Back in 2002 there was no API. No workflow. No formula fields. I won’t go into all that stuff, at least in this post. This one is a bit different.

Since you couldn’t do all the fun stuff in salesforce.com back then that you can do today you had to get a bit creative. Sometimes you had to “break the rules”. What we did salesforce.com wouldn’t have liked much at the time at all.

Continue reading