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.

  • interestingly enough, the Entity Key prefix decoder notes at the very bottom that the third char is 0-9 and a-z for knowledge which is probably incorrect as seen by the known issue. Sep 14, 2021 at 13:05

1 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).

  • Super interesting, thanks for taking the time :) Why do you your own personal tool for it, if you don't mind me asking?
    – Girbot
    Sep 14, 2021 at 15:38
  • 2
    @Girbot I am a hacker (the good kind). I love seeing what makes things tick. I poke and prod all kinds of systems to peer beyond the veil, to learn new things. Salesforce just happens to be one of those things. Of course, I'd never go so far as to break ToS or MSA, but I will take it as far as I can to see what lies beneath. What secrets does the platform hold? I've reported a number of (non-serious) bugs as a result, and it's made Salesforce at least a little better.
    – sfdcfox
    Sep 14, 2021 at 16:40
  • @Girbot As far as I know, only myself and Daniel Ballinger (now a salesforce.com employee) have bothered to go down that rabbit hole in earnest. He's got an advantage being on the inside, but I think I've done pretty well for myself being on the outside.
    – sfdcfox
    Sep 14, 2021 at 16:43
  • Insightful and good to hear :)
    – Girbot
    Sep 15, 2021 at 8:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .