Shield Platform Encryption for ISV

Congratulations! You’ve made it through the process and now have an app on AppExchange. But how do you ensure your app will work in an encrypted Salesforce Org? In the first part of this two-part blog series, that’s just what we’ll discuss: How to Test your App against a Shield PE activated Org?

What is Shield Platform Encryption?

I will not give a very detailed explanation here since I assume that you likely already have some knowledge of what Platform Encryption (PE) is — but if not, I recommend you watch these two short videos on Shield and PE.

Shield PE is one of the three features that compose Shield with Event Monitoring and Field Audit Trail. The purpose of PE is to allow a customer to add an extra level of security and compliance to sensitive, classified, regulated, and private data for many various reasons like regulatory compliance, internal policies or contractual obligations.

Shield PE is natively integrated with key Salesforce features and is using strong encryption at-rest capabilities with customer-controlled keys. A customer can generate and manage his own key material directly from the Setup UI or programmatically via the API. Compare to Classic Encryption with which you can only encrypt special type of custom text fields, Shield PE lets you protect some Standard Fields, Chatter feed, Search Indexes, Einstein Analytics Data Sets, Files and Attachments, and more.

Technical Considerations

As I am writing this blog, a customer cannot encrypt every single standard field of his Org — but with every release, we are allowing more and more standard fields to be encrypted.

It is also possible to encrypt custom fields of the following data types: Email, Phone, Text, Text Area, Text Area (Long), URL, Date, and Date/Time.

But encrypting custom fields comes with some considerations:

• You can’t use encrypted custom fields in criteria-based sharing rules
• Some custom fields can’t be encrypted
• Fields that have the Unique or External ID attributes (available if encrypted with the ‘Deterministic Encryption’ scheme)
• Fields on external data objects
• Fields that are used in an account contact relation
• You can’t use Shield Platform Encryption with Custom Metadata Types

One of the more common considerations is the usage of SOQL Queries. Encrypted fields that use the probabilistic encryption scheme can’t be used with the following clauses and functions:

• Aggregate functions such as MAX(), MIN(), and COUNT_DISTINCT()
• WHERE clause
• GROUP BY clause
• ORDER BY clause

This last consideration is very dependent on the kind of encryption scheme the customer is choosing — see the picture below:

Choosing the Encryption Scheme for a field.

Impact for Customers

You have to keep in mind that enabling Shield PE is at first a customer decision. When your package does not support fields to be encrypted, the impact is huge for an ISV Partner:

• The customer can decide to not buy your package
• The customer can decide to remove your package

How to Test Your Package

The picture below provides a good summary of testing your package:

A Managed Package can be tested in three steps and in a Test Partner Enterprise Org (or a Scratch Org if you are using Salesforce DX) that you should spin up from your Env Hub:

1. Test at the installation phase by encrypting all standard fields first.
2. Your customer can also encrypt your Managed Custom Fields so you should try to encrypt them also. Since Spring 19, customers can encrypt them in a self-service way, without having to open a case.
3. Even if the installation was a success, some Dynamic SOQL Queries may not have been spotted. Try to run all your test scenarios (Apex test Class as well as manual test) to make sure your app is still working.

Have questions? Reach out to our Shield PE experts in our Partner Chatter Group.