Object Prefix - Third Character

Question

I stumbled across this known issue, "In Winter' 22 release, On Knowledge articles whose recordID has the 3rd character as Capital , Category and Version comparision tabs shows GACK error"

Which states:

After Winter 22 upgrade the knowledge articles whose record id that has the 3rd character as capital letter (i.e. kaD), tabs are showing errors

1.Data category tab , not able to save data category in article and its showing blank popup

2.Version and Version comparison tabs are throwing GACK error

I'm intrigued as Ids have always been mixed case what could the cause be? I'm aware the first 3 characters are the object prefix, is there any special significance to the third character?

Very much an enquiring minds question.

Answer 1

If you're familiar with the Dewey Decimal System (used to categories books in libraries), this conversation will feel familiar. For the most part, Salesforce uses the three prefix characters as a major, minor, individual classification system. For example, all objects starting with 0 are core CRM objects (001 = Account, 005 = User, etc.), while prefixes starting with 1 are what I'd classify as "code resources" (e.g. 129 = LightningMessageChannel), etc.

The system checks the first two characters to make sure that the prefix is in a particular category to quick fail before consulting the database if the ID is invalid. As far as I can tell, the first position will be 0-9, and a handful of lowercase characters. No ID value will have an uppercase letter in the first position.

The second letter depends on the first, but most prefixes appear to support 0-9, a-z, and A-Z (Ids are case sensitive). As the Key Prefix Decoder, linked in a comment on your question, some prefixes only support a subset of these letters. Obviously, not all values in these ranges are valid, but these quick checks are useful to avoid having to check the metadata tables repeatedly.

The third letter, then, is validated against the first two. Since, according to the key prefix decoder you linked, the only valid values are a-z for this type of record, the system should rightly reject a capital letter. However, that's not true. If you create enough KA/KAV records (37+), you'll end up in capital-letter land (the numbers proceed through 0-9, then a-z, and finally A-Z).

This gack was likely the result of a bug fix; it seems that one developer thought that only lower-case letters were allowed, and another thought capital letters were also, so when they fixed the bug checking the third character, they didn't realize that capital letters were indeed being used. This is a really easy mistake to make in a code base this large, especially when custom objects are indeed allowed to use all 62 characters, and were possibly even generated using a common function.

Of course, some of this is speculation, but this is probably as close as you're going to get to The Truth without signing an NDA. All of the statements in this answer are from publicly-available observations, so there may be some inaccuracies, so please take it with a grain of salt.

Also note that the Key Prefix Decoder mentions about 730 prefixes, but my own personal scanning tool indicates about 1600 keys; the remaining keys are mostly used internally, and may not even have "labels" (e.g. have no UI support at all).