2

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.

  • 4
    Only Salesforce can help you with this one. You've discovered one of the Seven Dwarves which are very low level Oracle DB error messages that happen at the interface between the underlying database and the Salesforce Metadata! Good luck and happy hunting. Hi ho! – crmprogdev Nov 12 '19 at 3:50
  • @crmprogdev in your experience, can they actually mitigate issues like this? – Jay Kilian Nov 12 '19 at 18:23
  • 1
    I've never discovered one of the Dwarves myself, but you'll find posts about them here in the forum. Salesforce does work on them and takes them very seriously. – crmprogdev Nov 13 '19 at 17:27
  • I've hit a dwarf error or two. We're an elite group, Jay! All you can do is figure out what you did to overload the database query/update layer and to fix your code. I've always hit it with ridiculous loops in JavaScript. Check if activating encryption will screw with existing code/triggers/workflow. Other than that, it's a bummer, especially because encryption is a tough product to activate. Keep at it! – DavidSchach Nov 14 '19 at 1:10
1

Opening a case is the correct thing to do in cases like this. You should never see messages like that and they'll be able to help determine what's going on. What you're trying to do should work without issue.

One thing you can check is whether you've hit your limits on custom fields. If you have, then you'll run into issues with case insensitive deterministic encryption as it does count against custom field limits and that might manifest this way.

| improve this answer | |
  • Read the last line of the OP's question. – crmprogdev Nov 13 '19 at 17:28
  • Yeah, noticed that after I replied. I edited :) – John Whelan Nov 13 '19 at 17:33
  • Not sure who you're referring to, identigral, but my answer does provide an answer to the question. Troubleshooting path: contact support, they're equipped to track down an exact cause. What OP described doing is supported and should work (which answers several of the questions), and checking that custom field limits haven't been hit is an additional troubleshooting step. It's also very likely the cause. – John Whelan Nov 13 '19 at 19:23
  • @JohnWhelan That's just the text of one of the canned responses when a post ends up in one of the review queues. Text along the lines of "can you try X?" also tends to make answers sound more appropriate as comments. For what it's worth, I'm marking this review item as "looks ok" (i.e. doesn't need any action). – Derek F Nov 13 '19 at 21:46
  • Posters - note update in ticket. – Jay Kilian Nov 14 '19 at 0:56

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.