Take the 2-minute tour ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

I remember seeing somewhere that IDs are composed of a few pieces. I always have a hard time trying to find that information when I'm looking for it. What I mean by the above is that the various places in the ID represent different things - for example the first few characters represent what type of sObject it is.

share|improve this question
    
Awesome question - especially the valuable data it uncovered by virtue of the replies below. ;) –  AMM Dec 27 '13 at 18:53

3 Answers 3

up vote 48 down vote accepted

The Id Field Type is a base-62 encoded string.

Each character can be one of 62 possible values:

  • a lowercase letter (a-z) - 26 values
  • an uppercase letter (A-Z) - 26 values
  • a numeric digit (0-9) - 10 values

As there is a combination of lower and upper case letters the casing of the 15 character Id has significance. E.g. 50130000000014c is a different ID from 50130000000014C.

Within a 15 character Id the breakdown is:

  • First 3 characters - Key Prefix As per Jon's answer, the first 3 characters are the key prefix that identify the object type. There are a few exceptions to this where multiple objects all share the same key prefix! There are a number of fixed key prefixes that are common across all of Salesforce. Custom objects get a unique key prefix per Org. I'd need to confirm this, but I'm fairly certain that custom objects in managed packages can have a different keyprefix in each installed org.
  • Remaining 12 characters - basically a really big number. Like 62^12 big. It is common to see the first character in this sequence set to a value other than 0 even though most of the following characters are zero. This appears to be some kind of offset and may have significance.
    Update - See comment from @ca_peterson. This first character is a pod identifier.

To this you can add an optional 3 character suffix that will make the Id case insensitive. This is useful when working with programs that can't maintain the case of the ID (E.g. Excel VLookup). Note this is not intended as a check sum to verify the other 12 characters haven't been corrupted.


The algorithm to convert from a 15 character Id to an 18 character Id is: (Source - I'm sure there used to be official documentation on how do this.)

  1. Divide the 15 char into 3 chunks of 5 chars each.

  2. For each character give that position a value of 1 if uppercase, 0 otherwise (lowercase or number).

  3. Combine the bits from each chunk into a 5 bit integer where the rightmost bit is the most significant bit. This will yield a number between 0 and 31 for each chunk.

  4. Construct an array that contains the sequence of capital letters A-Z and 0-5 (26 + 6 = 32 possible values).

  5. Use the integer from each chunk to choose a character from the array.

  6. Append the resulting 3 characters, in chunk order, to the end of the 15 char id.

In a formula there is the CASESAFEID function that will perform this algorithm.

You can apply this algorithm to some sample IDs to see how it doesn't really function as a checksum or checkdigit. For example, if you exclude the alpha characters, every ID between 001100000000001 and 001999999999999 will have the suffix AAA. Infact, you get the same suffix if you include any lowercase alpha characters as well. The suffix will only change in the presence of uppercase characters. It is basically encoding which of the 5 characters that each suffix character represents are uppercase.


If you are working with Data Exports you can also come across the special empty key with the 000 keyprefix.

One area I'm not sure of is the order in which Salesforce increments through the base 62 encoding. E.g. Does it go 0 to 9, then a to z, then A to Z? At this stage I think the sequence looks like '0123456789aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ'

share|improve this answer
5  
The first character after the prefix is a unique number based on the pod it was created on (e.g. NA1, CS5). This doesn't correspond to it's name (CS 5 isn't 5), but instead the order of all pods which it was brought online. –  ca_peterson Dec 19 '12 at 4:46
    
@ca_peterson Interesting, thanks. Might be useful to identify which records were refreshed into a sandbox and which were created locally. –  Daniel Ballinger Dec 19 '12 at 7:17
1  
Rumor has it they're at the max number of pods for a single base-62 encoded digit, so this might spill over into a 2nd character soon. –  ca_peterson Dec 20 '12 at 1:28
2  
Fun fact: you can get a mapping of the pod identifier in the 4th char of the orgId to the pod's name from github.com/ryanbrainard/forceworkbench/blob/… –  ca_peterson Jul 20 '13 at 0:22
    
This whole case-insensitive thing with the checksum characters at the end (18 character ID) is news to me. WOW. That would negate an annoying formula I've used for years in Excel to turn 15-character IDs into something useful for VLOOKUP, COUNTIF, blah blah blah purposes. THANK YOU for that info, ;-) I just never new adding the checksum had that added purpose/functionality! –  AMM Dec 27 '13 at 18:51

The first 3 digits are a prefix that specifies the type of sObject, a big list can be found here:

http://www.fishofprey.com/2011/09/obscure-salesforce-object-key-prefixes.html

I believe the rest of the Id is reference to the record itself. I should also add that the ID's are 15 digits long but can be 18 digits long with the last 3 digits for error correction making the the Id case-insensitive.

So:

3 Digits (Object) / 12 Digits (Record) / (Optional) 3 Digits (Error Correction)

share|improve this answer
2  
Good to note that you can also get the object prefix via describe (s.getDescribe().getKeyPrefix())) –  joshbirk Sep 25 '12 at 17:56
    
I think the 12 digits for record still can be devided into 2 or more groups of different meaning. I remeber once seeing a blog about it, but can't find it. –  Samuel De Rycke Sep 25 '12 at 19:04
7  
Answer is slightly inaccurate. The last 3 characters are not for error checking, but for making the ID case insensitive. ID generation logic is described here in the documentation: salesforce.com/us/developer/docs/api/Content/… –  sorenkrabbe Sep 25 '12 at 19:57
    
@sorenkrabbe You are correct, ill update my answer :) –  Jon Hazan Sep 26 '12 at 8:52

While is is true that the last 3 character ads case insensitivity, I believe the algorithm used to generate them is the check digit. Check digits originated in legacy data transmission to alleviate the introduction if errors in the data. So a bit if both I reckon.

share|improve this answer
    
That's interesting. Could you elaborate more on how you know that or documentation about it? Thanks! –  Peter Knolle Sep 29 '12 at 5:51
3  
astadiaemea.wordpress.com/2010/06/21/…–-do-you-know-how-useful-unique-ids-are-to-your-development-effort/ –  techtrekker Sep 29 '12 at 8:31
    
Thank you for that! –  Peter Knolle Sep 30 '12 at 4:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.