We are in the process of encrypting fields in Production to accomodate PII regulations. This is going well for most fields, but today we encountered an issue with the EmailMessage object.
In multiple sandboxes we were able to update the Encryption Policy for the EmailMessage object normally (Setup>Encryption Policy>Encrypt Fields>EmailMessage update all fields, choosing "Deterministic - Case Insenstive).
However, when attempting to move the changes from Sandbox to production (using Gearset) we started receiving these errors:
ORA-06512: at "SLEEPY.CCUSTOMFIELDAVAILABILITY", line 736
ORA-06512: at "SLEEPY.CCUSTOMFIELDDATACOLUMN", line 43
ORA-06512: at "SLEEPY.ENCRYPTABLEFIELDDML", line 415
ORA-06512: at "SLEEPY.ENCRYPTABLEFIELDDML", line 495
ORA-06512: at line 1
After much deliberation, we tried the encryption steps manually and a few of hte fields were successful - Text Body, HTML Body, and Headers. The other OOTB fields below all triggered the SLEEPY error above.
Further investigative note - we could set the Subject and other fields to use Probabalistic encryption method, but that is not our requirement.
Does anyone have experience in how to troubleshoot this issue? Is there a limitation on the encryption types for email address fields (in production only)? Is this a volume issue (too many email messages in production)? We waited a few hours in between attempts in case there was an unknown/unreported API issue.
A case has been opened with SFDC support. Please advise if you can help us figure this out!
UPDATE: Salesforce Tier 3 support logged in using my Granted Login and were able to encrypt the fields as required. They had also suggested flushing the recycle bin in case 1) we were at the field limit (not even close) and 2) there was a custom field in the recycle bin that couldn't be encrypted (no such field in bin). We did not flush the bin.
After being told of resolution, I went to the encryption settings and turned one of the fields back to Probabalistic encryption, which worked, then set it back to Deterministic - Case Insensitive and this time it worked. So, either there was a temporary and undiagnosed issue that resolved between my case and resolution, or the Tier 3 rep has superpowers that broke through the error and fixed it for us.
Kudos to SFDC support for resolution, even if underlying issue was not explained.