Considerations for Using Deterministic Encryption

API Options to Identify Filterable Fields

Fields encrypted by using the deterministic encryption scheme are filterable. You can use the isFilterable() method to determine the encryption scheme of a particular encrypted field. If the field is filterable, the method returns true.

However, you can’t explicitly detect or set the deterministic encryption scheme via the API.

Available Fields and Other Data

Deterministic encryption is available for custom URL, email, phone, text, and text area field types. It isn’t available for other types of data, including:

• Custom date, date/time, long text area, rich text area, or description field types
• Chatter
• Files and attachments

Case Sensitivity

When you use case-sensitive deterministic encryption, case matters. In reports, list views, and SOQL queries on encrypted fields, the results are case-sensitive. Therefore, a SOQL query against the Contact object, where LastName = Jones, returns only Jones, not jones or JONES. Similarly, when the case-sensitive deterministic scheme tests for uniqueness, each version of “Jones” is unique.

Chat

The Utterance field on the Utterance Suggestion object supports case-sensitive deterministic encryption only. While the UI shows case-sensitive deterministic and probabilistic encryption, those schemes aren't currently functional.

The Actor Name field on the Conversation Entry object supports case-sensitive deterministic encryption, but not case-insensitive deterministic encryption.

Compound Fields

Even with deterministic encryption, some kinds of searches don’t work when data is encrypted with case-sensitive deterministic encryption. Concatenated values, such as compound names, aren’t the same as the separate values. For example, the ciphertext for the compound name “William Jones” isn’t the same as the concatenation of the ciphertexts for “William” and “Jones”.

Select Id from Contact Where Name = 'William Jones'

Select Id from Contact Where FirstName = 'William’ And LastName ='Jones' 
 

Case-sensitive and case-insensitive deterministic encryption schemes support compound fields, but only with individual column queries.

Converting Account and Contact Records to Person Accounts

When you convert account and contact records to Person Accounts, synchronize your data. Syncing resets the indexes that allow case-insensitive filtering.

Can’t Search by Using Merge Account Tool

When the Account Name or Contact Name field is encrypted with probabilistic or deterministic encryption, searching for duplicate accounts or contacts to merge doesn’t return any results.

Custom Field Allocations

To support case-insensitive queries, Salesforce stores a lowercase duplicate of your data as a custom field in the database. These duplicates are necessary for case-insensitive queries, but they count against your total custom field count. For example, if you have 200 custom fields in your org, and you choose to encrypt one with case insensitive deterministic encryption, your custom field total is 201.

External ID

Case-insensitive deterministic encryption supports Text and Email external ID custom fields but not other external ID custom fields. When you create or edit these fields, use one of the recommended field setting combinations.

You can’t save changes to Unique - Case-Sensitive and Encrypted options at the same time. Change one setting, save it, and then change the next.

Filter Operators

In reports and list views, the operators “equals” and “not equal to” are supported with case-sensitive deterministic encryption. Other operators, like “contains” or “starts with,” don’t return an exact match and aren’t supported. Features that rely on unsupported operators, such as Refine By filters, also aren’t supported.

Case-insensitive deterministic encryption supports list views and reports. However, the user interface displays all operators, including operators that aren’t supported for encrypted data. To review the list of supported operators available in Salesforce Classic, see Use Encrypted Data in Formulas.

Filter Records by Strings

You can search for records by using strings. However, commas in strings act as OR statements. If your string includes a comma, use quotation marks around the string. For example, a search for “Universal Containers, Inc, Berlin” returns records that include the full string, including the comma. Searches for Universal Containers, Inc, Berlin returns records that include “Universal Containers” or “Inc” or “Berlin.”

Formulas

Fields encrypted with the probabilistic encryption scheme can’t be referenced in SOQL WHERE queries. However, you can use SOQL WHERE queries with non-formula fields encrypted with the deterministic encryption scheme. Name is an example of a non-formula field.

Indexes

Important

When your encryption scheme includes encrypting fields that are used in indexes, use deterministic encryption for those fields.

There are significant ramifications if you choose to encrypt fields that are part of an index or which have uniqueness requirements. Read this section carefully so that you understand the issues.

Both case-sensitive and case-insensitive deterministic encryption are supported.

• Case-sensitive deterministic encryption supports single-column indexes, single-column case-sensitive unique indexes, two-column indexes, and custom indexes on standard and custom fields.
• Case-insensitive deterministic encryption offers limited support for standard indexes on these standard fields.
  • Contact—Email
  • Email Message—Relation
  • Lead—Email
  • Name

Be aware of these performance considerations before you plan to encrypt index fields.

• Poor query performance: Queries against fields encrypted with case-insensitive deterministic encryption can perform poorly with large tables. For optimal query performance, use custom indexes instead of standard indexes. To set up custom indexes, contact Salesforce Customer Support.
• Lookup field filtering: Lookup fields that reference the Name field also rely on indexes. To filter on the Name field in list views and reports, filter against the standard Name field instead of a lookup field.
• Long enablement process: Expect the enablement process to take longer when you apply deterministic encryption to a field with a large number of records. The enablement process also rebuilds field indexes.

Use these best practices if you do elect to encrypt index fields.

• Ensure consistent encryption: When using deterministic encryption on indexed fields or fields that have uniqueness requirements, ensure all values are encrypted with the same deterministic key. This ensures reliable identification of duplicates across records.
• Perform Encryption Sync: We recommend performing an Encryption Sync soon after making any changes that could affect the uniqueness of indexes, such as changing the encryption scheme or rotating the Deterministic Encryption tenant secret.
• Plan for downtime: Plan these changes during off-peak hours to minimize disruption. The Encryption Sync runs in batches and can take varying amounts of time depending on the entity’s structure, record volume, and the fields involved. Work with our support team to plan the necessary downtime.

Key Rotation and Filter Availability

Adding, removing, or changing a deterministic encryption scheme rebuilds your indexes. User activity on encrypted fields causes duplicate data in indexes, which can interfere with sync operations. After you rotate deterministic key material or change a field’s encryption scheme to case-sensitive deterministic encryption or case-insensitive deterministic encryption, sync your data to your active key as soon as possible. Syncing applies the active key material to existing and new data. If you don’t sync your data, filtering and queries on fields with unique attributes don’t return accurate results.

You can sync data in standard and custom fields yourself on the Encryption Statistics and Data Sync page in Setup. To sync all other data or large volumes of data, contact Salesforce Customer Support. Read more about data synchronization at Synchronize Your Data Encryption with the Background Encryption Service.

Next Best Action Recommendations

When you use deterministic encryption, you can use encrypted fields in load conditions only with the equals or not equals operator.

Removing Deterministic Encryption from Fields

If you remove encryption from a field encrypted with deterministic encryption, Shield Platform Encryption needs some time to decrypt that field throughout your org. The size of your org determines how long this process takes, so the field won’t have the filtering and sorting characteristics of an unencrypted field until that update completes.

SOQL GROUP BY Statements

Assemble where clauses according to the rules on The SOQL/SOSL Reference Page Comparison Operators.

Deterministic encryption doesn’t support the GROUP BY clause. If you do specify GROUP BY using a deterministic field, your groupings won’t be accurate or consistent.

SOQL LIKE and STARTS WITH Statements

Deterministic encryption only supports exact, case-sensitive matches. Comparison operators that return partial matches aren’t supported. For example, LIKE and STARTS WITH statements aren’t supported.

SOQL ORDER BY Statements

Because deterministic encryption doesn’t maintain the sort order of encrypted data in the database, ORDER BY isn’t supported.