I have read documentation regarding Platform Encryption on managed package and everywhere its written that If a managed package supports Shield encryption then we can encrypt fields.

So if I am building a managed package how do I support "Platform Encryption" in my managed package.

Let say I have written a SOQL with a where clause, and the package gets installed in an org with Shield encryption and they want to encrypt this field. Do they contact us and we change our logic based on that ? Or how does it work.

1 Answer 1


You have to write your managed package defensively and always adhere to Shield's restrictions, as described in the documentation, if you want to allow encryption to be turned on against any given field.

That frequently means that the field cannot be used in SOQL or SOSL WHERE, ORDER BY and GROUP BY clauses, for example. It also cannot be used in aggregate queries. There are a bunch of other restrictions too. You'll find mention of such constraints in the documentation around trade-offs.

We recently went through the pain of updating our managed package to enable certain key fields (like the Contact Name and Email address details). The general learning from this was:

  • Where you used SOQL WHERE against the field consider whether you can query the data using SOSL with a FIND instead (assuming SOSL indexing hasn't also been encrypted) then in-memory filter the results to the actual one(s) required since SOSL may match the value against more fields than you want.
  • Where you used SOQL ORDER BY against the field consider whether you can use standard Salesforce SObject ordering or using post-query (Apex-based) ordering. If these options don't work, consider whether you can ORDER BY against a different field, such as the ID of the object.
  • Where you use SOQL GROUP BY against the field consider whether you can use a different field for the GROUP BY (e.g. switch to grouping by ID).
  • Etc.

Note that you can determine whether or not you can use fields for ORDER BY etc. by querying the Schema. For example, you could do:

// Different ORDER BY clause required if Contact Name field is not sortable (usually if encrypted)
Boolean isNameSortable = SObjectType.Contact.fields.Name.isSortable();

String orderByEmployeeString = (isNameSortable ? 'Employee__r.Name NULLS LAST, ': 'Employee__c, ');


This then allows you to "gracefully degrade" package functionality when the field of interest is encrypted, whilst continuing to work as originally designed when not encrypted.

In the big picture, you must decide which fields you must support encryption against and develop the package defensively for this (we ensure that our critical fields are actually encrypted on our scratch orgs by using a bit of scripting when creating the scratch orgs and pushing the code to them). For other fields, if you can, see if you can consider these in the same way though note that this can limit what your package is able to do.

Since our package existed well before Shield was available, we have the case that we are only able to extend Shield support to fields as and when customers ask. This varies in complexity depending on how we use that field within the product, specifically around SOQL handling.

  • Thanks @Phil. This helps. Commented Dec 10, 2020 at 13:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .