Every record within Salesforce is assigned a record ID when created. This ID is unique throughout your Salesforce org, and is referenced frequently when performing operations using existing Salesforce data.
15 Digit Record ID
To find the record ID within the user interface, simply navigate to the record. The ID will be shown as part of your URL, and is 15 digits in length:
You may see variants of this in configuration, such as viewing record types. Simply click on the record type of a particular object, and you can easily locate the id of that record type:
18 Digit Record ID
The API (e.g. Data Loader) will accept 15 or 18 character IDs, but will return 18 character IDs by default. The 18 character ID is a combination of the 15 character ID with 3 characters added to ensure that it is unique on a case insensitive basis (this is to support legacy applications). Truncating the last 3 characters from the 18 character ID will result in the 15 character ID. The CASESAFEID function case can be used to derive the 18 digit ID within a formula field.
15 Digit ID | 18 Digit ID | |
---|---|---|
Unique (Case Insensitive Basis) | No | Yes |
Usage | User Interface | API |
Example | 006E0000004TquX | 006E0000004TquXIAS |
Sorry if I’m wrong, but for data mangement the 18 digit CASESAFEID() is highly important. When exporting data via reports, only the 15 digit Id is exported. That’s why i had trouble deduplicating in Excel several times (unless you use an external Id, what we do in most cases).
John, what scenario would show the usage of the 18 digit return of the Salesforce Id via API (so without creating a formula without the CASESAFEID() function)? Think i never have seen it.
Regards,
Patrick
If you pull data from the API you will get an 18 digit ID – the 15 digit ID is only presented in the user interface URL and through reports 🙂
Hello All,
Just wanted to share an incident that happened to me before while working on SF:
We had a filter to track down certain account’s HQ by its ID, where ID = XXX, however, all of a sudden the report returned higher values that normal.
Turns out there’s another account with exactly the same characters but capital and small is the only difference between them.
Don’t remember whether the filter was equal or contains, but would be helpful to know that for practical cases but not for the exam. Thanks.
ah so the “equals” designation isn’t case sensitive… that is interesting
Hi John,
This is a great study tool. I think the last sentence (CASESAFEID function case be used to derive the 18 digit ID within a formula field) should read ‘can be used’.
Regards,
Karim
Thank you, updated!
I can’t find where I saw it originally, but here is another reference:
https://developer.salesforce.com/forums?id=906F00000008s3XIAQ
I think SF refers to the Salesforce ID in general terms, as each object has its own “Record ID”. See here for a better explanation:
https://help.salesforce.com/HTViewHelpDoc?id=exporting_from_salesforce.htm&language=en_US
I believe that’s true on the backend, although I don’t think you would see it much from an admin/dev perspective
Hi John
Salesforce.com Help refers to “Salesforce Id”. Is this the same as “Record Id”? It seems like it.
That should be the same thing – where in help did you see that reference?
Hey John,
First up, thanks for the awesome guide.
Second, I believe in the graph you have comparing 15 and 18 digit record Id’s you have the case sensitive mixed up; shouldn’t 18 be case sensitive instead of 15?
15 digit record ID is case sensitive while the 18 digit record ID is not (case insensitive). When importing, updating, or deleting data you should use the 18 digit record ID to avoid accidental changes.
http://www.salesforce.com/us/developer/docs/api/index_Left.htm#StartTopic=Content/field_types.htm?SearchType=Stem
Spot on Nicole, thanks
Hi John
In this module all the screenshots are blank. Kindly let me know why they are blank.
Hi Swetha- the screenshots are working for me. Can you reset your cache and try again? There may have been a problem with the CDN that caused this temporarily.
Hi John,
I think (e.g. updating dating) is meant to be (e.g. updating data)!
Thank you, updated!