Timeline for installing a package in an org with platform encryption
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 5, 2018 at 12:22 | answer | added | Patlatus | timeline score: 1 | |
| Feb 1, 2018 at 18:38 | vote | accept | Jorjani | ||
| Feb 1, 2018 at 18:38 | answer | added | Jorjani | timeline score: 0 | |
| Feb 1, 2018 at 16:48 | comment | added | Patlatus | Have you contacted Salesforce support and did they shed light on this topic? | |
| Sep 27, 2016 at 15:41 | comment | added | Eric | @DacidJ - No I have never encountered this. It could be a bug. Maybe the package dynamically referenced the field so the protections failed. Who knows. Either way, sounds like SF may have to get involved. | |
| Sep 27, 2016 at 15:27 | comment | added | Jorjani | That sounds right. Have you ever done this? Is it going to take long to revert? We were getting encryption failed emails for other fields that we were querying by. This is the only one that got encrypted and is causing problems although it was being queried at the time we encrypted it. | |
| Sep 27, 2016 at 15:15 | comment | added | Eric |
You may need to contact SF. Encrypted fields cannot be used in the WHERE condition of a query. If the managed packaged (looks like it was) was using that field in a filter you essentially killed it. Turning it off may not be enough to stop this behavior once the field was set as an encrypted field via platform encryption. (Surprised you were even able to do it on a managed field). Hopefully someone else proves me incorrect but me thinks it is time to put on your patience hat and open up a css with SF. good luck...
|
|
| Sep 27, 2016 at 15:00 | history | asked | Jorjani | CC BY-SA 3.0 |