Salesforce Platform Encryption Support & Considerations

This article outlines how Avochato for Salesforce works with Salesforce Shield / Platform Encryption. From package versions v1.56 and onwards, Avo4SF automatically detects encrypted fields and adapts its behavior, so the integration keeps working even in highly secured environments. Here's everything you need to know.

A. What is Salesforce Platform Encryption?

Salesforce Platform Encryption lets orgs encrypt data at rest on standard and custom fields — a common requirement for regulated industries like healthcare, financial services, and government. When a field is encrypted, Salesforce restricts what you can do with it in SOQL queries.

There are two encryption schemes:

Probabilistic Encryption — The strongest protection. Fields encrypted this way cannot be used in WHERE, ORDER BY, LIKE, or != null SOQL operations. This is the most restrictive mode.

Deterministic Encryption — Allows exact-match filtering (e.g., WHERE Email = 'user@example.com') but still prevents LIKE queries and some other operations.

For more background, see the Salesforce Platform Encryption documentation.

Why this matters for Avo4SF: Avo4SF queries Salesforce data using SOQL throughout the integration — for contact matching, list view broadcasting, user setup, and more. When fields involved in those queries are encrypted, the queries need to be written differently. Avo4SF checks the encryption status of each relevant field at runtime and automatically adjusts its query strategy. Non-encrypted orgs see zero behavior changes.

B. Which Features Are Affected?

1. List View Broadcasting

Avo4SF's List View Broadcast feature reads records from a Salesforce List View and sends messages to phone numbers on those records. Encryption can affect two parts of that query:

Phone null filtering: Avo4SF normally filters out records without phone numbers directly in the SOQL query (WHERE Phone != null). When the Phone field is encrypted with probabilistic encryption, != null checks aren't allowed — so this filtering happens in-memory instead. The end result is identical: only records with phone numbers are included in the broadcast.

Sort order: If your list view sorts by an encrypted field, the ORDER BY clause is dropped from the query to prevent errors. Records are still returned and broadcast messages are still sent — they just won't arrive in the list view's original display order.

⚠️ Limitation — Name field encryption: If the Name field on the Salesforce object (Lead, Contact) is encrypted with Platform Encryption, the List View Broadcast page will not load. This is a Salesforce platform limitation — when the page loads, Salesforce internally executes the list view's SOQL query (which sorts by Name), and encrypted fields cannot be sorted. This happens at the Visualforce framework level before Avo4SF's code runs, so it cannot be worked around in our application code. Encrypting the Name field is extremely rare in practice — Platform Encryption is typically applied to sensitive data fields like Phone, Email, and SSN. If you encounter this issue, removing encryption from the Name field in Salesforce Setup will resolve it. All other encrypted fields (Phone, MobilePhone, Email, etc.) are fully supported.

2. API Credential Setup (Webhook User Matching)

When Avochato sends webhook credentials back to Salesforce, it matches the incoming user by email address to confirm which Salesforce User record to associate.

Normally: Avo4SF queries directly — WHERE Email = 'user@example.com'.

When User.Email is encrypted (not filterable): Avo4SF falls back to querying all active users and matching the email address in-memory.

💡 This is fully transparent — your API credentials are set up correctly either way. You won't see any difference in the setup experience.

3. Avochato Setup Page (User List)

The Avo4SF setup page displays a list of active Salesforce users so admins can manage access and assignments. Normally, this list is sorted alphabetically by Last Name, then First Name.

When those name fields are encrypted (and therefore not sortable), the alphabetical ORDER BY is automatically dropped. Users are still displayed — just not in alphabetical order.

4. Email Client Contact Matching (Gmail / Outlook Sidebar)

The Avo4SF sidebar component matches Salesforce Contacts and Leads based on the sender's name and email address. Encryption affects two parts of this lookup:

Name search: Uses a LIKE query to find partial name matches (e.g., WHERE LastName LIKE 'Smith%'). When the Name field is encrypted with probabilistic encryption, LIKE operations aren't allowed — so this search is gracefully skipped rather than throwing an error.

Email matching: Uses exact-match filtering (WHERE Email = 'user@example.com'). When Email is probabilistically encrypted (not filterable), the email filter is skipped as well.

💡 Contacts are still matched by phone number, which is the primary matching method. Name and email matching are supplemental search paths. For best results on encrypted orgs, make sure phone fields are populated on your Salesforce Contact and Lead records.

C. What You Need to Know

Fully backwards compatible — Non-encrypted orgs (the vast majority of Avo4SF customers) experience zero behavior changes. All the encryption-aware code paths only activate when encrypted fields are actually detected.

No configuration needed — Encryption detection happens automatically at runtime using Salesforce's built-in field metadata. There is no setting to toggle or field list to maintain.

Per-field, not per-org — Avo4SF checks each field individually. Only fields that are actually encrypted trigger fallback behavior. You can have a mix of encrypted and non-encrypted fields and the integration handles each one appropriately.

Probabilistic vs. Deterministic matters — Probabilistic encryption has more restrictions and triggers more fallbacks. Deterministic encryption allows exact-match queries, so features like email lookup may still work normally with deterministic encryption in place.

D. Frequently Asked Questions

I'm getting "field 'X' can not be filtered in a query call" during package installation. What should I do?

Upgrade to Avo4SF v1.56 or later. Earlier versions used static SOQL queries that are incompatible with Platform Encryption. The latest version automatically adapts all queries to work with encrypted fields.

Will this affect my org if we don't use Platform Encryption?

No. All encryption-aware logic only activates when encrypted fields are detected at runtime. If your org doesn't use Platform Encryption, Avo4SF runs the exact same code paths as before — no performance impact, no behavior changes.

My List View Broadcast records aren't arriving in the expected order. Why?

If your list view sorts by an encrypted field (e.g., Phone), Avo4SF drops the ORDER BY clause to prevent a query error. Your records are still returned and your messages are still sent — they just won't be in the list view's display order. This is expected behavior when sorting fields are encrypted.

The List View Broadcast page won't load at all. I'm seeing "field 'Name' can not be sorted in a query call." What's happening?

This occurs when the Name field on the object (Lead or Contact) is encrypted with Platform Encryption. Salesforce's Visualforce framework internally executes the list view's query — including its ORDER BY Name clause — before Avo4SF's code runs. Since encrypted fields can't be sorted, the page fails to load. This is a Salesforce platform limitation that Avo4SF cannot work around. To resolve it, remove encryption from the Name field in Salesforce Setup → Platform Encryption → Encryption Policy. Encrypting Name is uncommon — Platform Encryption is typically used on sensitive fields like Phone, Email, and SSN, which Avo4SF fully supports.

Contact matching in the email sidebar seems less accurate. What happened?

When Name or Email fields are encrypted, Avo4SF can't use those fields for lookup matching since the underlying SOQL operations aren't permitted. Contacts are still matched by phone number. For the best matching accuracy on encrypted orgs, ensure that phone fields (Phone, MobilePhone) are populated on your Salesforce Contact and Lead records.

Which Salesforce fields can trigger these encryption-aware fallbacks?

The standard fields Avo4SF checks include:

Object	Fields
Contact	Phone, MobilePhone, Email, LastName, Name
Lead	Phone, MobilePhone, Email, LastName, Name
Account	Name, Phone
Opportunity	Name
Case	ContactPhone
User	Email, FirstName, LastName

Does Avochato handle Deterministic encryption differently from Probabilistic?

Yes. Deterministic encryption allows exact-match filtering (e.g., WHERE Email = 'x@y.com'), while Probabilistic encryption does not allow any filtering on the encrypted field. Avo4SF checks each field's filterability and sortability at runtime, so deterministic-encrypted fields may still work with exact-match query operations like email lookups — meaning you may see fewer fallbacks than you would with probabilistic encryption.

Do I need to tell Avochato which fields are encrypted?

No. Avo4SF uses Salesforce's DescribeFieldResult metadata API to automatically detect each field's encryption status, filterability, and sortability at runtime. There is no manual configuration required on either the Salesforce side or within Avo4SF settings.