We are an ISV partner and have managed packages in customer orgs. We want to be able to know the encryption status of a field in the code before working with it so our package does not break in production. I have found "isencrypted()" and "isFilterable()" to allow us to see if a field is encrypted or not. However, the behavior is not what I was expecting, when I use a piece of code similar to below:

        If (!Schema.sObjectType.[ObjectName].fields.[CustomFieldName].isencrypted()) {
            b = [SELECT id from [ObjectName] where [CustomFieldName]!=:null LIMIT 1];   
            system.debug('Field is Encrypted');

I was hoping that using code like this would allow the custom field to be encrypted by bypass it when running the code. The behavior I see is that it still does not allow me to encrypt the field even though the line querying it will never be run (same with isFilterable()). Any thoughts on how to make this possible?

  • 2
    Use Dynamic SOQL, which is compiled at runtime instead of compile-time. – Charles Koppelman Mar 8 '17 at 19:47
  • Thanks @CharlesKoppelman! That sounds like a viable workaround that I hadn't thought of. Having said that, I'm hoping to have a more native way to bypass this check in compile time. – Jorjani Mar 8 '17 at 19:50

Yes we unfortunately don't have yet a great answer to this problem, using dynamic SOQL is the current workaround.

Please consider using isFilterable() instead of isEncrypted(), it is more accurate.

| improve this answer | |

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.