We're worried with data volumes that using an AutoNumber may cause overflow problems during the lifetime of the system, so look to the ID as an alternative. (We've been told we may need to scale to a system creating up to 250,000 records a day. Good job they're short lived for storage costs! I may suggest some aggregation process on the front end as a means of reducing this number.)

The ID looks like a Base 62 number and it does sort properly. I can select with ORDER BY. To date it has seemed reliable, apart from one glitch which was seen using a batch process to insert lots of records. I've not been able to recreate that glitch.

I admit using the ID relies on assumptions about Salesforce's implementation, which could easily be changed in future. For example block allocation of IDs would ruin the assumption but would be an obvious means of increasing scalability on Salesforce's part by reducing calls to a Sequence.

I've wondered about using the system clock, but that is vulnerably to both skew in a multi-server environment and granularity which increases chances of racing. So maybe we have to accept the possibility of a sequence overflowing.

Thanks - Richard

1 Answer 1


You can not rely on the Ids being sequential. I have had several instances where Ids were issued from a lower block of Ids to the ones that were already allocated in the org.

One solution to this is to use the following ORDER BY. The will sort all records by the CreatedDate and when multiple records have the same CreatedDate it will fall back on sorting by the Id for those records.

... ORDER BY CreatedDate, Id
  • Thanks. That solves the granularity problem with CreatedDate. We'll give it a go. Dec 1, 2014 at 14:05

You must log in to answer this question.

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