Ask Search:
Banwari kevatBanwari kevat 

18 digit case-insensitive id is not working

Hi i have account id with 15 digit as in below url i'm able to access record
https://ap5.salesforce.com/0017F000008BqLk
Now i am converting this 15 digit case-sensitive Id into 18 digit case Insensitive Id as in below url
https://ap5.salesforce.com/0017F000008BqLkQAK
It's working fine.

Now we know that 18 digit Id is case-insensitive
So i am trying to access record changeing the 18 digit id with changing one char to b
Now new URL would be like below
https://ap5.salesforce.com/0017F000008bqLkQAK
record should be accessible from 0017F000008bqLkQAK but it is throwing below error message
Unable to Access Page
The value of the "id" parameter contains a character that is not allowed or the value exceeds the maximum allowed length. Remove the character from the parameter value or reduce the value length and resubmit. If the error still persists, report it to our Customer Support team. Provide the URL of the page you were requesting as well as any other related information.


Can anyone let me know what does 18 digit id is case-insensitive mean if above url is not able to access the record?
Best Answer chosen by Banwari kevat
Deepak AnandDeepak Anand
Ah! You got it wrong. So let me explain. The last few characters in the 18 Characters Long IDs are called checksums (https://en.wikipedia.org/wiki/Checksum). Now in simpler words, the last 3 characters(QAK) identifies in which ALL positions within the first 15 characters, does an Upper Case Alphabet occurs. These 3 are never use to retain a lost case but in order to make 2 IDs that might look similar.

Follow this figure to know how a 15 characters long ID is converted to 18 characters long ID - 
 


Now if you play around with the casing like say - 
  1. 0017F000008bqLkQAK
  2. 0017F000008BQLkQAK
  3. 0017F000008BqlkQAK
  4. etc...
It will NOT be recognized in Salesforce(like in SOQLs, URLs like you did etc) but it is for external systems that doesn't distinguish IDs based on casing.

Let's take an example of an external database application that doesn't distinguish IDs based on case. Assume that you do not have 15 character Long IDs and assume you have 2 Account records in Salesforce with IDs - 
  1. 0017F000008bqLk
  2. 0017F000008BQLk
If you notice, both the IDs are the same irrespective of the case but they are referring to 2 different records in Salesforce since IDs in Salesforce are case-sensitive.

Thus from external database application's point of view - 
0017F000008bqLk = 0017F000008BQLk
which is NOT true in Salesforce.

But let's say you had 18 characters long version of these IDs(with the 3 letter checksums at the end).Then you would see = 
0017F000008bqLkQAI != 0017F000008BQLkQAO

All Answers

Nathan GraberNathan Graber
It doesn't mean that you can randomly change the case of characters in the URL and it will still work. It means that if you export the IDs to Excel or some other program that cannot differentiate between case, the 18 digit ID is guaranteed to be unique, even accounting for this case insensitivity, but the 15 digit one is not.

For example, if you export the 15 digit IDs of two records, one might be 000000000000abc and one might be 000000000000abC. When you navigate to these two records in Salesforce, you'll see two different URLs (big C vs. little c). However, Excel would not be able to tell these two IDs apart. If you export the 18 digit ID you would never have something like this happen. It would always be something like 000000000000abcdef and 000000000000abCghi, so even Excel could always tell them apart.
Varun KocharVarun Kochar
Below article will solve your doubt-
https://salesforce.stackexchange.com/questions/130158/is-of-18-digit-id-really-case-insensitive/130168#130168
Narender SinghNarender Singh
+1

It is not so simple as it sounds.

ID fields in the Salesforce.com user interface contain 15-character, base-62, case-sensitive strings. Each of the 15 characters can be a numeric digit (0-9), a lowercase letter (a-z), or an uppercase letter (A-Z). Two unique IDs may only be different by a change in case.

Because there are applications like Access which do not recognize that 50130000000014c is a different ID from 50130000000014C, an 18-digit, case-safe version of the ID is returned by all API calls. The 18 character IDs have been formed by adding a suffix to each ID in the Force.com API. 18-character IDs can be safely compared for uniqueness by case-insensitive applications, and can be used in all API calls when creating, editing, or deleting data.

You think of 18-char ids as just a workaround for the environments/platforms that dont recognize the the difference if the difference is only because of characters' case.
Aman MalikAman Malik
Kindly have a look at below reference:
https://salesforce.stackexchange.com/questions/130158/is-of-18-digit-id-really-case-insensitive

Maybe this will help you to understand the concept.
Anshul AroraAnshul Arora
Hi Banwari,

It's basically the last 3 character addition to an ID which makes it "Case Insensitive". For an example once we export the records to an excel sheet Ids, two of the records may have Ids as:

0017F000008bqLk
0017F000008bqLK

This would not show any difference in the external source(for example excle would treat these values as same, you might face issues in V-lookups etc.), So 3 more characters are added to the Id to make it 'case insensitive'. It surely doesn't mean that you could change the case sensitivity and obtain the same record, it's just the salesforce way of making an Id safe when extracted to external sources.
Deepak AnandDeepak Anand
Ah! You got it wrong. So let me explain. The last few characters in the 18 Characters Long IDs are called checksums (https://en.wikipedia.org/wiki/Checksum). Now in simpler words, the last 3 characters(QAK) identifies in which ALL positions within the first 15 characters, does an Upper Case Alphabet occurs. These 3 are never use to retain a lost case but in order to make 2 IDs that might look similar.

Follow this figure to know how a 15 characters long ID is converted to 18 characters long ID - 
 


Now if you play around with the casing like say - 
  1. 0017F000008bqLkQAK
  2. 0017F000008BQLkQAK
  3. 0017F000008BqlkQAK
  4. etc...
It will NOT be recognized in Salesforce(like in SOQLs, URLs like you did etc) but it is for external systems that doesn't distinguish IDs based on casing.

Let's take an example of an external database application that doesn't distinguish IDs based on case. Assume that you do not have 15 character Long IDs and assume you have 2 Account records in Salesforce with IDs - 
  1. 0017F000008bqLk
  2. 0017F000008BQLk
If you notice, both the IDs are the same irrespective of the case but they are referring to 2 different records in Salesforce since IDs in Salesforce are case-sensitive.

Thus from external database application's point of view - 
0017F000008bqLk = 0017F000008BQLk
which is NOT true in Salesforce.

But let's say you had 18 characters long version of these IDs(with the 3 letter checksums at the end).Then you would see = 
0017F000008bqLkQAI != 0017F000008BQLkQAO
This was selected as the best answer