In the Summer 2015 release, Salesforce introduced an update to their platform encryption capabilities. This feature is included as a component of the Shield product. By providing native platform encryption, Salesforce opens opportunities for highly-regulated industries and customers that have strict data residency and sensitivity requirements to leverage the platform.
The nature of encrypted data imposes its own specific challenges and limitations. For example, data that is encrypted generally can’t be easily sorted or filtered, and may be of limited use in declarative tools such as approval processes, duplicate management rules, and formula fields. In this blog post I discuss the limitations imposed when platform encryption has been enabled, errors that may occur, and highlight some strategies to help mitigate the impact of such limitations.
Common Limitations
The following are the two most common limitations due to platform encryption:
1. Encrypted fields can’t be used with the following SOQL and SOSL clauses and functions:
- Aggregate functions such as MAX(), MIN(), and COUNT_DISTINCT()
- WHERE clause
- GROUP BY clause
- ORDER BY clause
2. Encrypted fields can’t be used with the following features:
- Criteria-based sharing rules
- Similar opportunities searches
- External lookup relationships
- Skinny tables
- Filter criteria for data management tools
- Duplicate Management matching rules
You can find additional limitations here.
Challenges for ISVforce/OEM Application Developers
For ISVforce/OEM application developers, there are particular challenges that must be addressed when dealing with platform encryption. If your customers can’t encrypt the fields they want, the consequence is you’ll miss a sales opportunity or your customers will uninstall your app. It’s mission critical to make your packages comply.
1. Platform encryption may prevent the application from being installed
If Salesforce detects that the code inside a package performs an operation that is invalid on an encrypted field, the installation will fail. A message similar to the following will appear during install.
2. Platform encryption may prevent the application from running correctly
Salesforce can’t catch all the issues at install time. For example, this is particularly true when Dynamic SOQL is used. When accessing a feature that violates platform encryption constraints, a runtime error will occur. These types of issues may be harder to track down and require more extensive testing.
3. No control on whether platform encryption is enabled or which fields are encrypted
As an app developer, you have no control on whether or not the Target org will have encryption enabled or which fields will actually be encrypted. There are two particular scenarios to consider:
- Encrypted standard fields – Platform encryption allows standard fields to be encrypted. This means that any or all of the fields below (as of Winter 17) may be encrypted and this list will most likely grow with every new release. If your application leverages any of these fields, you must guard against this eventuality. The impact to potential customers must be assessed and every effort should be made to support encrypted fields or if needed, gracefully deactivate portions of the application that will not function when particular standard fields are encrypted. However, this latter option may not be acceptable if developing an application targeted to Financial Services, Insurance, or Public sector customers that will most likely have highly sensitive data requirements.
- Encrypted custom fields – Before the Summer 16 release, customers couldn’t encrypt your custom fields, so you didn’t have to worry about it. Now, not only can customers encrypt your custom fields, they may do it without your knowledge. The consequence? Your customer may not be able to encrypt a field because you didn’t guard against it, and now they want to uninstall your package because their privacy officer says the data must be encrypted. Since your package is incompatible, you can kiss your licenses goodbye. This capability could also affect upgrades. If a package was successfully installed and a custom field subsequently encrypted, a future update to the package could be blocked due to an encryption violation that is present in the upgrade but not in the original package. If encrypting a custom field will cause a significant impact to your application, you may decide that encryption of that particular field is unsupported. This information should be clearly stated in any installation documents or release notes. This decision must be balanced between the impact to the application, the likelihood of the field containing sensitive data, and the number of customers potentially affected by this decision.
4. There may be a delay when encryption is turned on and off, and this may lead to confusing errors
The architecture behind platform encryption is such that when turning encryption on and off for a field, a user may encounter a system propagation delay. A consequence of this propagation is that the system may report a field as encrypted even though encryption has been turned off – and customers may encounter difficulties installing or upgrading your package. This should clear up shortly once the changes have fully propagated; however, it may be necessary to open a support case with Salesforce to ensure that all the backend systems are correctly reflecting the encrypted state of the field.
How to Mitigate Issues
1. Use SOSL over SOQL
One of the most common problems encountered is the restriction around including encrypted fields in the where clause of a SOQL statement. A SOSL find statement can sometimes be used in lieu of a SOQL statement.
List<Contact> contacts = [Select Id From Contact Where Email = :emailaddress];
The above query will fail on installation (or at runtime if this is dynamic SOQL) if the the Contact email field is encrypted. However the Query can be replaced with the following SOSL statement:
List<List<SObject> > contacts = [FIND :emailaddress IN ALL FIELDS Returning Contact (Id, FirstName, Last Name]
SOSL and SOQL commands are not always identical so this change should be fully tested.
2. Detect whether platform encryption is turned on
In some situations it may be necessary to run alternate implementations depending on whether encryption is enabled for a field. Salesforce provides a few methods to assist with that. In particular, the isFilterable and the isEncrypted methods can be used.
If (Schema.sObjectType.Contact.fields.Emails.isFilterable()) {
// Run Logic without needing to worry about encryption
}
else {
// Run Logic limited by encryption
}
The isEncrypted() method can also be used to more generally test whether the field is encrypted.
3. Perform Operations in Apex
Some SOQL operations such as GROUP BY or ORDER BY, can’t be performed on encrypted fields. If this functionality is needed and the result sets are anticipated to be sufficiently small, the aggregation or sorting can be done in Apex once the data has been fetched by the SOQL call. The viability of this approach is dependent on having sufficiently selective queries that will return a limited number of records.
4. Have all developers enable encryption in their PDEs
To minimize any retrofit required with platform encryption, have all developers enable platform encryption in their development orgs. They should do this for all standard fields that can be encrypted and for all supported encrypted custom fields. Your developers will then be working in a “worst case scenario” org. Any potential issues will be caught immediately with minimal impact and rework required.
Many customers plan to test features in a platform encryption org only once development and functional testing is complete. This will probably result in additional rework to ensure that encryption is properly supported. It’s best to catch this early.
5. Build secondary package for users that have non encrypted orgs
Your application may have add on features that will really only function if encryption is disabled. For example, you may deploy a set of added value analytical capabilities that can’t be made to work with encrypted filter fields. By combining these into a secondary package, customers who do not have encryption enabled can download and install the secondary package.
This strategy is useful when it’s anticipated that most customers will not have encryption enabled and the core application will still function correctly without the added value components. This approach should be used sparingly and only as a very last resort. It may require additional contracts and security review for the second package and it creates a more complicated installation for most customers. It’s critical not to simply duplicate functionality in a second package, i.e providing a platform encryption version and a “vanilla” version, as this scenario will become a maintenance nightmare.
Summary
In today’s world, encryption of data at rest is becoming a requirement. To educate developers on the migration testing of existing applications and more, Salesforce created a step-by-step guide to help assess the impact of platform encryption on any packages. This guide will help you understand and provide some guidance towards remediation. It also provides tips and tricks on working around some of the limitations encountered when fields are encrypted. Additional platform encryption documentation can be found here.
To fully support customers that have enabled this functionality, ISV partners may be required to update their AppExchange package to ensure continued functionality — regardless of whether customers have enabled platform encryption or not. This is the new reality, and better to solve it sooner rather than later.
Want to ensure your app stays functional no matter the update? We’ve got you covered. Check out www.codescience.com/services to see how we can help.
