7

Currently the pod instance that a record is created on is encoded in the 4 character of the ID, immediately after the key prefix. There are some more details about the Pod identifier in the question What are Salesforce ID's composed of?

As per Has Salesforce hit an architectural limit?, there are currently 61 pods listed on trust.salesforce.com.

What happens when the 62 possible values allowed by base-62 encoding is exceeded?

Will it move to the fifth character as well?

Improve this question
9
  • Just curious, why are you tracking the pod?
    – Adrian Larson ♦
    Jan 26, 2015 at 19:40
  • Seems they would just make the "Really big number" part of the id a little smaller (e.g. remove a digit and add it to the pod. I think it would still be large enough to handle more records than you could possibly hold in Salesforce.
    – Adrian Larson ♦
    Jan 26, 2015 at 19:42
  • @AdrianLarson Mostly out of interest in how the IDs work. In terms of functionality, the only viable use I've found is determining if an OrgID is for a sandbox or not, and then using the correct login URL. Otherwise things like pod migrations make basing any functionality off the pod id too risky.
    – Daniel Ballinger
    Jan 26, 2015 at 19:46
  • @AdrianLarson Moving to the next character makes more sense than increasing the number of characters in an ID. Increasing the length of an ID would cause wide spread chaos.
    – Daniel Ballinger
    Jan 26, 2015 at 19:59
  • 1
    @daniel Snap :) Was that before or after my blog post. Think we came to the same conclusion :) Couple of options. How dependant is it? Creating a sandbox mixes the id's and server id's up anyway. There is probably a lot of legacy code around for it but to me the reasons of having it may not be around any more. But by increasing it is reducing the pool of record id's so isn't that pushing the issue down the road? But with wave and potentially the ability to archive data in the future it maybe a mute point.
    – Francis
    Jan 26, 2015 at 21:16

1 Answer 1

Reset to default
3

And the answer comes from Steven Tamm himself:

"@radnip We've used 2chars for server id for a while now. This documentation is out of date" Source

well that clears that up :)

The documentation you point to is incorrect. We're updating it.

Characters 5 & 6 were reserved as '0' from the beginning. A few years ago we started using the 5th character to represent originating instances. For example, instance cs33 uses "35" as the serverId for the ids it generates, and na41 uses "27". As data can move between instances pretty easily, the InstanceId is only helpful in determining where a record was generated, not where it is now.

Steven Tamm
Source

Improve this answer

You must log in to answer this question.

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