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.
