function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
mmcconnammcconna 

Ids - sometimes 15-character, sometimes 18-character for same objects?

Hi all. I'm confused, and would welcome some help. In an activities-based report within salesforce.com, I use the Activity Id field to give the Id number.

I then export to Excel. Let's say the Excel spreadsheet contains only one Actitivity, Id is 00U20000001Rx6d

Later, we read back the spreadsheet with some changes. I build an SOSQL string like this:

SELECT Id,Outcome__c,TookPlace__c FROM Event WHERE ( Id='00U20000001Rx6d')

and I get one Event (the right one) back, which I read into a keyed dictionary. However, the Event object I read from the API has an Id of 00U20000001Rx6dEAC.

So why is it that the report gives 15-character Ids, and the API reports 18-character Ids on the same item? It makes it difficult to match them up. Is it always safe to reduce the 18-character Id to a 15-character one?

Yours,
Moray

HarryBHarryB
AFAIK all salesforce Ids have been 15 chars in the beginning. Then - on the integration with Excel (Office Toolkit) - it turned out that Excel can not handle the case of the Id correctly. For example the different AccountIds would have been identical to Excel. So the SF guys were forced to add another 3 chars to all Ids when exporting them to external tools (API) - these 3 chars at the end
HarryBHarryB
Whoops, messed up again - maybe some kind Admin can clean up a bit. Sorry for that.
 
AFAIK all salesforce Ids have been 15 chars in the beginning. Then - on the integration with Excel (Office Toolkit) - it turned out that Excel can not handle the case of the Id correctly. For example the two different AccountIds 00120000003VwJv and 00120000003VwJV would have been identical to Excel.
So the SF guys were forced to add another 3 chars to all Ids internally (in the SF database) and when exporting them to external tools (API) - these 3 chars at the end of every object Id contain uppercase letters only and make sure the whole Id is unique.
 
Whenever you have an external application that can handle the case of the entire Id correctly, its save to truncate the first 15 chars and dump the rest.
SF (and SF API) will recognize 15 and 18 char Ids fine.
 
Cheers,
Harry
 
mmcconnammcconna
Here's the reply I had from salesforce themselves, which is annoying but makes sense:

Thank you for contacting salesforce.com Technical Support in regards to the API. 18-character ID values are simply 15-character ID values with a checksum suitable for case-insensitive searches. If you are using a case-sensitive application to match up ID values, you may safely discard the checksum characters. Otherwise, you will need to generate a checksum from the report's 15-character ID values to obtain the 18-character ID value. This is done by creating an zero-based indexed array of [A..Z0..9], then grouping the 15 characters into three groups of 5 characters. Each group creates a bitmask, where 1 is if the letter is uppercase, 0 if lowercase or a number. This five-bit number indexes into the array above. For example:

15-character ID: 00130000000Az53

Bitmask grouping: 00130 | 00000 | 0Az53

Bitmask: 00000 | 00000 | 01000

Indexing: array[0] = "A"; array[0] = "A"; array[8] = "I";

Final 18-character ID: 00130000000Az53AAI

Hopefully this makes some sense. If you are using case-sensitive environments, it's easier to just ignore the final three characters. However, if you need to use the ID values in a case-insensitive manner, this is how you can convert the report values to case-sensitive ID values. For additional information, please browse the Developer Forum for additional information.


NILESH RAJ 20NILESH RAJ 20
The simplest way to check the 15 and 18 digit IDs of a record or to convert 15 to 18 digit Id is by using the Salesforce 15 to 18 digit IDs converter (https://sfdcwisdom.com/salesforce-15-to-18-digit/)