Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

The quick version: Shield Platform Encryption protects data at rest, and you pay for it everywhere the platform wants to compare, sort or calculate. Probabilistic encryption removes a field from WHERE clauses, ORDER BY, GROUP BY, formulas, roll-ups and criteria-based sharing. Deterministic encryption buys back exact-match filtering and gives up some of the security. Decide before you switch it on, because reversing the decision is a data project rather than a checkbox.

Two schemes, one choice per field

Probabilistic encryption produces a different ciphertext every time the same value is encrypted. That is the stronger option and it is why the platform cannot match on the field at all: two identical values do not look identical on disk.

Deterministic encryption produces the same ciphertext for the same value, which allows exact-match filtering and some list view and report filtering. It comes in case-sensitive and case-insensitive variants. The trade is real: repeated values become visibly repeated in the ciphertext, so a field with low cardinality (a status, a country, a flag) leaks its distribution to anyone who gets the file.

Pick deterministic only for fields you must filter on, and only where the value space is large. A deterministic encrypted Country field is close to pointless.

What stops working

Once a field is encrypted, expect these to fail or to disappear from the picker:

  • Formula fields. An encrypted field cannot be referenced by a formula. This breaks more than people expect, because formulas feed validation rules, roll-ups and list view columns.
  • SOQL filtering and ordering. No WHERE on a probabilistic field, no ORDER BY, no GROUP BY, no aggregate functions. Deterministic fields support equality, not ranges and not LIKE.
  • Roll-up summary fields that filter on the encrypted field.
  • Criteria-based sharing rules that reference it. This one is quiet and dangerous: the sharing outcome changes without an error.
  • External ID and unique field settings. Both are incompatible, which rules out most integration key fields.
  • Report filters, groupings and bucket fields on that field.
  • Duplicate and matching rules, unless the field is deterministic and the rule is built for it.

Global search still works, because the search index is encrypted separately and searched in its encrypted form. That surprises people in the other direction.

The integration question nobody asks early enough

Encrypted data is decrypted for authorised users and for API calls made by authorised users, so your middleware keeps working. What stops working is anything that filtered on the field. A nightly job doing WHERE National_ID__c = :value against a probabilistic field fails with a query error, not a permissions error, and it fails for every record.

Audit your SOQL before you encrypt. Grep the codebase for the field’s API name and read every query, formula and flow that mentions it. That grep takes an hour and it is the difference between a controlled change and a Monday morning incident.

Turning it on, and the part about turning it off

Enabling encryption on a field encrypts new and updated data immediately. Existing records are not encrypted until you run the background job from the Encryption Statistics page, and until that finishes the field is in a mixed state where filtering behaves inconsistently. Watch the statistics page rather than assuming.

Disabling is possible: clear the checkbox and the platform decrypts in the background. What does not come back is everything you removed to make encryption viable. The formula you deleted, the sharing rule you rewrote, the external ID you moved to another field, the integration you re-pointed. Those are your real cost, and they are one-way in practice even though the encryption flag is not.

Key management is genuinely one-way. Destroy a tenant secret and every record encrypted under it becomes permanently unreadable, by you and by Salesforce. That is the intended behaviour of the feature. Treat destruction as a deletion operation, because that is what it is.

Frequently asked

Is this the same as the Encrypted Text field type? No. Classic encrypted text is a separate, weaker feature with a masked field type and its own limits. Shield encrypts existing standard and custom fields in place without changing their type.

Does encryption hide data from admins? Not by itself. Any user with access to the field and the View Encrypted Data permission sees plaintext. Shield protects the data at rest and in the backups, not from your own users.

Can I encrypt a field that a flow uses? You can read it in a flow. You cannot use it in an entry condition or a record filter, which is usually the part the flow depended on.

What should I encrypt first? The fields a regulator names, and nothing else. Encrypting broadly because it sounds safer is how orgs end up with a reporting model they cannot rebuild.