Salesforce recommends that you only consider this feature if government regulations for your market require it. When developing a packaged solution, your main consideration is what happens if a subscriber wishes to enable it on a standard field you reference in your solution or in one of your packaged fields.
When implementing the 256-bit encryption used by Platform Encryption, by default, Salesforce opted for probabilistic encryption over deterministic encryption. Since the encryption is not deterministic (an encrypted value is the same each time), it is not possible to index fields that have this level of encryption applied. This results in the most significant restrictions for developers and platform functionality regarding querying a field.
Without an index, the platform cannot provide a performant way to allow code to filter, group, or order by encrypted fields in queries. If code attempts to do so at runtime, an exception will occur. Your package installation may be blocked if it detects queries inside Apex code that would not be compatible with these restrictions. Conversely, once your package is installed and the user attempts to enable encryption, this action may fail. Salesforce provides a report in both cases to inform the user which fields are problematic.
It is possible to work around these restrictions in one of two ways, depending on the chosen encryption type for a given field:
- Using Deterministic Encryption will enable some basic filtering but not all. For example, you can run reports or SOQL that compares encrypted fields with a given literal value for equality (case sensitive and case insensitive is a configuration). However, other filter operations, such as greater than or like, are not supported.
- Using Probabilistic Encryption with conditional code, by using Dynamic SOQL to allow runtime formation and the execution of effected queries where encryption is not enabled. In cases where encryption is enabled, you can perform filtering, grouping, and ordering in Apex and/or via Salesforce Object Search Language (SOSL). However, both these options should be considered carefully as they have their own restrictions and may not be the most performant.
Ultimately, you may need to accept that you have to selectively hide functionality in your solution in cases where neither of the above workarounds is acceptable to maintain a good user experience. This decision is one you have to make in conjunction with your users as to how acceptable a trade-off this would be.
I highly recommend that you leverage the Education section in the Partner Success Community. Under the MORE RESOURCES section, you will find a page with videos and other resources dedicated to ISVs.