I need to generate an unique alphanumeric string of length of 30 characters which will be used very similar to the record id. Is it okay to use Crypto.generateAesKey() method to generate this 30 characters string? I'll be converting it to Hex and use String.subString(0,30) to achieve this. Is this enough to generate random string for every insertion? My custom objects can have up to 50 millions of records.

  • 2
    What are you worried about specifically? Execution speed or intersections? – nchursin Aug 19 '18 at 18:17
  • @blank - thanks for the response. My only worry is about the code generating unique code every time and I’m getting an unique 30 characters string everytime. – sfdcnewbie Aug 20 '18 at 6:47
  • 1
    If this only needs to be unique compared to other records in the table, you might find it easier to just take the record ID and add 12 zeros. This also guarantees uniqueness, unlike generating a random number. – IllusiveBrian Aug 20 '18 at 20:30

30 hex digits yields 1.329228e+36 possible values; you're looking at having up to 50,000,000 (5.0e+7) records. This results in an extraordinarily large number of possible ID values (on the order of 2.7e29) per record.

The Crypto documentation does not specify exactly how an AES key is generated. If we can assume Salesforce uses a high quality source of entropy to generate true cryptographically random keys, you should be able to assume your ID values are evenly distributed through the keyspace to enough precision that it won't make any difference to your application.

Collisions will not be likely, to say the least. But it's also not impossible. If you make your Id field a unique External Id field, you could build some fairly simple logic into your before insert trigger to run a query against your generated values to ensure they're not duplicated before you populate the field.


Thanks for your input! Never disappointed with stackexchange.

I guess I've figured out one way to solve this. Email ID coming into our systems for custom object were always uniquw and few were blank. So, I decided to generate AES key while every record to be inserted and encrypted the Email ID and took the 30 characters from it. In case Email ID was blank, I took 30 characters from the AES Key itself for those particular records.

I've tested this code for 10 records insertion, and generating unique id took around 28 ms (maybe it won't be very accurate) which was way faster than the using For Loop 30 times to generate unique string (which I found on one article)

Thanks again everyone! Cheers!

  • Just as a note, the fact that the plaintext value is unique does not require that the first 30 hex digits' worth of ciphertext is unique (it's likely, but not guaranteed). In most cipher modes that wouldn't be the case even if the same key were used, which it's not here. I don't really think that encrypting the email address adds anything over and above generating a new, random AES key. – David Reed Aug 26 '18 at 13:40

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.