12

This answer (from Nathan Pike a Salesforce developer) mentions the idea of an "empty id string" that can be appended to the 3 digit key prefix. I've wanted an ID that matches nothing but is syntactically valid and is not null so am interested in official documentation or any further insight into this.

I note that all these compile and run as expected:

Id id = '003' + '000000000000AAA';
Contact[] cs = [select Name from Contact where Id = :id];
System.assertEquals(0, cs.size());
System.assertEquals(Contact.SObjectType, id.getSObjectType());

with the last line showing that using a real key prefix is safest.

PS

A Daniel Ballinger blog post on this - Salesforce Empty Key Id - 000000000000000AAA.

  • geez -- since the above works, then there should be an sobject method to generate it rather than the above "hidden SFDC lore". I'm curious what your use case is - mocking test objects? – cropredy Mar 2 '16 at 17:39
  • @crop1645 Two places I've wanted it: 1) a dynamic query builder where it was an easy way to avoid invalid empty braces such as where Id in (); 2) to have a named ID value that is other than null to make some code clearer. What got me to ask this question is some dodgy advice I was giving in an answer to another question here that (ab)used this. – Keith C Mar 2 '16 at 17:51
  • @KeithC I realized on my own I could do this about 6 months ago. I used it to get a list of all sObjects and their prefixes by looping through and incrementing the 3 digit prefix. I realized my list was incomplete though as the Org I used it with didn't have access to all sObjects. – dBeltowski Mar 2 '16 at 21:20
  • here is the question that triggers Keith's question salesforce.stackexchange.com/questions/112507/… – Nick Kahn Mar 3 '16 at 14:26
3

Empty Key Id In The Wild

I have only encountered the empty key Id in one circumstance. It represented the "All" List View in a peculiar circumstance I discovered a while back.

Mocking Your Own Dummy Id Values

In my experience, only the key prefix and length of the Id matter. Because of this, I can use the following logic to generate dummy Id values. Here is a simplified example of how I create dummy values in my SObjectFactory test utility.

public class DummyIdProvider
{
    final String prefix;
    Integer counter;
    public DummyIdProvider(SObjectType sObjectType)
    {
        prefix = sObjectType.getDescribe().getKeyPrefix();
        counter = 0;
    }
    public Object getValue()
    {
        return prefix + String.valueOf(counter++).leftPad(15).replace(' ', '0');
    }
}

Using Id values generated from this structure, I can easily mock trigger.oldMap, for instance.

final Integer recordCount = 10;
List<Contact> newRecords = SObjectFactory.create(
    Contact.ObjectType, recordCount, Contact.Id,
    new DummyIdProvider(Contact.sObjectType)
);
Map<Id, Contact> oldMap = new Map<Id, SObject>(newRecords.clone(/*preserveId*/ true));

I'm not sure what other circumstances necessitate dummy Id values. Perhaps there are some edge cases where the other components of an Id matter. See What are Salesforce ID's composed of? for more detail, though @KeithC I'm sure you've read it and voted for it already. You still can't update or query for records with a dummy Id, so I have a hard time believing the pod identifier is relevant.

  • Hi, Adrian, I mentioned two caveats I found while playing around with dummy Id values. The first character must match [0-9a-z] (so, no capital letters), while the fifth character currently throws an exception if it's not [0] (no other letters or numbers work). – sfdcfox Mar 8 '16 at 0:06
  • @sfdcfox So you basically have to leftPad at least somewhat with 0 characters. Interesting. I consider 0 padding the simplest approach to dummy values, so it never occurred to me to try anything else. – Adrian Larson Mar 8 '16 at 0:14
2

There's no documentation I'm aware of, but the basic idea is-- as long as you're not using the Id in a DML operation, you can use any 15 characters you like. I suggest using a real key prefix, and a real pod Id (the first five characters), but the remaining 10 can be whatever you want. There are two character positions that have special rules, though. The first character must be lowercase or a number, and the fifth character must currently be 0. Any 15 random characters that fit into an Id (based on the rules above) will also work in any query, although it may result in fewer records being returned (depending on how the query was written).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.