Did you know that when you're looking at the Id of a record—any record—on the platform, the first three digits tell you what object it's a record of?
For many of you, this is old news. If you've been around the ecosystem for a while, you've probably read about it (like on this blog, or this help article), or been told about it. But I feel like this bit of Salesforce esoterica doesn't get discussed as often as it should and, therefore, that newbies don't learn about it consistently. This is useful information that every Salesforce admin should know.
Last post we looked at how to break down a Salesforce URL. But today we're focusing just on the record Id that's in the URL (or anywhere else you might encounter record Ids, like in a spreadsheet). If I see 0014T000002xyUn, I know that this is an account. How do I know? Because it begins with 001. All account Ids begin with 001.
(That tells you something about Salesforce and its history too, right? Accounts are the basis for the data model. All contacts must be related to an account. All opportunities are child to an account...)
What we've noticed is that the object is identified with a prefix, known as the Key Prefix, within the record Id.
All Accounts begin with 001.
Contacts begin with 003.
Users begin with 005.
Opportunities begin with 006.
Leads begin with 00Q. (Fun to speculate: I assume the Q is from "qualification.")
Reports begin with 00O (that's zero zero letter O).
If you want the truly complete list, let me direct you to Daniel Ballinger's list on Fish of Prey.
Isn't it interesting that Account is 001 and user doesn't come along until 005? I assume that means that Parker built out the data model before bringing in the concept of logged in users interacting with the data. And what happened to 004...?
Your custom objects get assigned a key prefix as well. They usually start with a lowercase a. (Maybe they always start with a lowercase a?)
[Updated with a side note: Phil W pointed out to me that Id prefixes for custom objects can vary from org to org because of what might already have been in use before. If you install managed packages in a different order in two orgs, the custom objects for those packages could vary. This would apply even to the objects of NPSP, since it's theoretically possible that your org had some custom object using one of the prefixes before NPSP was installed in your instance. So don't make assumptions and don't hard code.]
Flows on Tasks
Have you ever wanted to kick off automation, for example, "when someone creates a task related to an opportunity (via the Related To field)"? I get that kind of request all the time because someone wants to do something automatically if anyone has put a note on a grant, or a note on a partnership discussion. But while this seems simple at first glance, you quickly realize this isn't going to work because that Related To field (known by its API name, WhatId) can look up to just about any standard or custom object, it's not just a lookup to opportunity.
But if you know about key prefixes, you can make a task that checks the first three digits of the value in WhatId to figure out if it's on an opportunity.
Easy peasy!
Decoding Errors
The other place I find key prefixes useful is when trying to interpret an error, either in the UI or a flow error email. If the error message isn't very helpful—And, let's face it, that's more often than not!—it becomes a treasure hunt to figure it out. You have to understand the full context, such as what user was unable to do what thing, when/how they were doing it, etc. But often the error isn't directly related to what the user was doing, and instead has to do with other records that are updated because of what that user was doing, and the user doesn't have sufficient permissions to create/update/delete that other record. The Id in the error message might let you know what didn't seem obvious.
For example, I see that I ages ago I had a question in my email about this:
ERROR: INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY: insufficient access rights on cross-reference id: 0014S000003rlts
Immediately upon looking at it, I know that this has something to do with permissions regarding Account. Maybe the integration, in this case, was trying to update a contact or an opportunity, but it's account permissions that got in the way. Now I know where to start.
Or this one:
npsp.TDTM_Opportunity: execution of AfterInsert\n\ncaused by: System.DmlException: Insert failed. First exception on row 0; first error: INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY, insufficient access rights on cross-reference id: a2A000005Lthc
A little sleuthing and I was able to figure out that a2A is the NPSP Data Import Batch object (npsp__DataImportBatch__c). Combined with knowledge that this error came from GiveLively (a donation platform), that might still leave a lot of troubleshooting to work on, but I already know a lot more than the original message conveyed!
One Last Trick
You can use the three digit prefix to go to the tab for the object it indicates. This won't work in all cases, since some objects, standard or custom, don't have a tab. But if you know the prefix for an object, or are looking for the object based on an error message, you can make a quick link to the tab with the prefix. For example
https://yourdomain.lightning.force.com/006
will take you right to the Opportunities tab. Swap the 6 for a 3 and you can jump to the Contacts tab. Etc...