Salesforce Encrypted Fields: Everything You Need to Know

In 2021, the average cost of a data breach hit a 17 year high. Last year, every data breach cost companies approximately $3.86M per incident. The current average is roughly $4.24M per data breach.

Recently, representatives from top technology companies, including Google, Okta, Slack, and Salesforce, have created a partnership to develop a cybersecurity baseline.

This set of guidelines has been dubbed the Minimum Viable Security Product (MVSP).

Among other things, the creators of the MVSP recommend that you encrypt your data. Fortunately, Salesforce already has several mechanisms in place that facilitate the encryption process, including “Salesforce encrypted fields.”

What is an Encrypted Field in Salesforce?

In Salesforce, an encrypted field is a cybersecurity functionality that allows you to mask data. When your data is masked using field encryption, users without the appropriate permissions will not be able to view the data.

Conversely, team members who have a profile with “View Encrypted Data” enabled will have the ability to view encrypted information normally.

Salesforce encrypted fields have several limitations. For instance, the character limit on an encrypted field is often lower than the standard field length, with Case Comment as a prime example. In addition, some field encryptions can limit other features, like Einstein Lead Scoring can be limited if Lead fields are encrypted.

Understanding Salesforce Encrypted Fields and When to Use Them

Encrypted fields aren’t a one-size-fits-all solution, and it is equally important to know how to use them and when to do so. Generally speaking, encryption is the most appropriate for fields that include sensitive, regulated, or personally identifiable information (PII) – as in, any data that could cause significant harm or liability if exposed during or after a breach.

With that being said, encrypting too many fields also comes at a cost. Different encryption schemes can all reduce the efficiency of search functionality, reporting, or even automation. The primary goal should be to find a balance between security and usability.

• Is this data regulated by a compliance framework like HIPAA, GDPR, or PCI-DSS? 
• Would exposing this data cause harm to customers or legal risk to your organization? 

Before encrypting a field, ask yourself: 

If the answer to either is yes, encryption is likely warranted. If the field contains general operational data with no sensitivity, then standard Salesforce access controls may be enough instead.

Encrypt Data in Custom Fields in Salesforce Classic

We were tempted to jump right into custom field encryption for Salesforce Lightning, but we wanted to throw in a section for those who are still running on Classic.

Classic Encryption is included for free for Classic, and you can always add on Shield Platform Encryption if you need additional features. The encryption options work the same way in Classic as they do in Lightning with a few small exceptions.

You can implement Salesforce Classic encryption without the Shield Platform Encryption add-on. The algorithm will be a 128-bit Advanced Encryption Standard instead of a 256-bit AES. If you want to try the add-on, it’s included in Salesforce Developer sandboxes. If you want to check out some additional differences between Classic Encryption and Slalesforce’s Platform Encryption, here’s a handy reference guide.

Encrypt Data in Custom Fields in Lightning Experience

When encrypting new data using custom fields in Salesforce Lightning, you will again have the option to choose between standard encryption or purchase the Shield add-on. If you opt to buy the add-on, navigate to the Platform Encryption Advanced Settings page in your “Setup” menu and enable deterministic encryption.

You will need to remain in the “Setup” menu to create your custom field.

1. Locate the “Object Manager” tab and then choose your object.
2. Then, click on the “Fields & Relationships” button.
3. After doing so, you will be prompted to create or edit a custom field.
4. Make sure that you select “Encrypted” when generating your field.

How Salesforce Field Level Encryption Protects Sensitive Data

Salesforce Field Level Encryption is a method of protecting sensitive data by encrypting it at rest – the data is encrypted at the database layer, making it unreadable for anyone except users who have the correct permissions. This is different from data being only protected via access controls where the plain-text data is still stored in the database.

Key management is the core of this system. Each organisation will either introduce its own encryption keys or will have one provisioned by Salesforce via Shield Platform Encryption. The key in question dictates who/what is able to decrypt the data – making the encrypted values a meaningless block of symbols to everyone, including Salesforce.

Here’s a quick look at how encryption changes the data experience across common scenarios:

This last point is worth emphasizing. Salesforce’s encryption controls exist entirely within Salesforce. When a file is exported or transferred into a new system – the Salesforce encryption controls do not apply anymore, leaving the data vulnerable.

How do I Encrypt Field Data in Salesforce?

Salesforce has numerous encryption scheme fields that you can use to protect Salesforce data. However, setting up an encryption policy requires the Salesforce Shield Platform Encryption add-on. Of course, it is always best practice to test any change in a Salesforce sandbox, prior to implementing in production!

For many organizations, you can enable standard field encryption in a few minutes. To begin, ensure that your organization’s encryption key is active.

1. If it is, then you can navigate to the “Setup” menu and use the Quick Find search box to query the phrase “Platform Encryption.” From the results, select “Encryption Policy.”
2. When the next menu opens, select “Encrypt Fields” and click on the edit button. Select which fields that you would like to encrypt. Salesforce will encrypt all new data governed by that field with a probabilistic scheme.

Unfortunately, that scheme makes it difficult to perform data filtering. Therefore, we recommend switching to deterministic encryption.

You can encrypt both standard and custom objects. In addition, new files and attachments can be encrypted, though the indicator denoting a file and encryption will only be visible if you are using Salesforce Classic.

How do I Decrypt an Encrypted Field in Salesforce?

You can always decrypt a field by turning off Salesforce Encryption! This is needed if you want to integrate data with a legacy portal, use a Salesforce feature that does not support Shield Platform Encryption, or leverage specific Salesforce apps with this data like the Customer 360 Data Manager.

If, for example, you want to implement Salesforce’s Einstein Recommendation Engine in Marketing Cloud, this app does not support Shield Platform Encryption. Any data used with this app will need to be unencrypted. To stop encryption on a field, simply:

1. Select the Encryption Policy in Setup
2. Click Encrypt Fields
3. Deselect the fields that you no longer want to encrypt. Please note that File encryption is either on or off, so you can’t turn it off for just specific fields!

If you want to read more about decrypting data, Salesforce’s Shield Platform Encryption Implementation Guide is a handy reference.

Can Salesforce Search Encrypted Fields?

Under all encryption types, a Salesforce user can search for data using the standard search functionality. Users are not prevented from finding and viewing data that they are authorized to view! SOQL use, however, can be limited on encrypted fields. If you selected the deterministic scheme when encrypting fields, you would still be able to search them in Salesforce. However, there are several limitations, even when using this scheme.

Specifically, Salesforce cannot use encrypted fields in list views or report filters. In addition, Salesforce does not support encrypted fields in some of SOQL clauses, such as WHERE, MAX(), or ORDER BY.

Why a Salesforce Encrypted Field Not Searchable Can Affect Your Workflows?

The search limitations on encrypted fields aren’t just a technical footnote – they could have very real day-to-day implications on the operations in your organization. If you’re dependent upon filtered list views, scheduled reports, or Flow automations that search for certain field values – encryption could secretly break or reduce the quality of those processes.

Here are the most common workflow areas affected:

• List views and report filters — Encrypted fields cannot be used as filter criteria in list views or reports, meaning any view or report built around that field will need to be restructured or removed entirely.
• Salesforce Flow and Process Builder — Automation that filters or branches based on an encrypted field value may not behave as expected, particularly when using decision elements that compare field values.
• SOQL queries — Even with deterministic encryption enabled, certain SOQL clauses like WHERE, ORDER BY, and MAX() are unsupported on encrypted fields, limiting what developers and admins can query programmatically.
• Third-party integrations — External tools that sync or query Salesforce data via the API may encounter unexpected null values or errors when interacting with encrypted fields, requiring additional handling on the integration side.

Before encrypting a field that is already in active use, it is worth auditing which reports, flows, and integrations currently reference it to avoid unexpected disruptions.

Salesforce Encrypted Fields Limitations Developers Should Know

Although Shield Platform Encryption is a powerful solution – it’s important to understand some of its technical limitations which will impact the way you develop and manage your solution on top of encrypted data. Finding these early into the development process will save you a huge amount of rework later on.

• SOQL restrictions — Encrypted fields cannot be used in WHERE, GROUP BY, ORDER BY, or aggregate functions like MAX() and MIN(). This limits the ability to filter, sort, or aggregate data programmatically, even when using deterministic encryption.
• Apex triggers — You can read encrypted field values in Apex, but you cannot perform string operations, comparisons, or pattern matching on them reliably. Any trigger logic that branches based on an encrypted field value should be thoroughly tested.
• Formula fields — Encrypted fields cannot be referenced in formula fields. If your data model relies on derived or calculated fields that pull from sensitive data, you will need to rethink that architecture.
• Flows and validation rules — Certain operators in Flow decision elements and validation rules are unsupported on encrypted fields, which can silently cause logic to fail or behave unexpectedly.
• External ID and lookup fields — Encrypted fields cannot be used as External IDs or as the basis for lookup relationships, which can complicate data migration and integration patterns.
• Managed packages — Not all AppExchange packages support Shield Platform Encryption. Any package that reads, writes, or queries an encrypted field should be explicitly verified for compatibility before deployment.

Key Use Cases for Encryption of Your Salesforce Data

Shield Platform Encryption adds an additional security layer to your Salesforce Organization by encrypting data at rest. Each company can bring its own key or use the key provided by Salesforce, providing flexibility for all industry verticals.

This helps each company meet compliance requirements while also providing a user friendly app with critical elements like search, data validation, and automation like Salesforce Flow. Some of the most common types of data that you can encrypt with Salesforce custom fields include:

• Email addresses
• Phone numbers
• Written text
• Text Area (standard, long, and rich)
• URLs
• Date/Time
• Credit card numbers
• SSNs
• Addresses

The more custom fields you encrypt, the more difficult it will be to query your data. Most organizations only encrypt the most important data types, such as SSNs, credit card numbers, and email addresses.

How to Secure PII in Salesforce Custom Object Data

Custom objects are frequently the place in your Salesforce org where the most sensitive PII reside: patient records, financial profiles or new patient intake forms. Since custom objects have no encryption by default like the standard objects, deliberate configuration is necessary to secure such information.

Here’s a straightforward process for locking down PII on custom objects:

1. Identify your PII fields — Audit your custom objects for fields containing data like SSNs, dates of birth, financial account numbers, or any other information regulated under HIPAA, GDPR, or PCI-DSS. These are your encryption candidates.
2. Enable Shield Platform Encryption — Navigate to Setup, search for Platform Encryption, and ensure your organization’s encryption key is active before proceeding.
3. Apply encryption to the relevant fields — Under Encryption Policy, select Encrypt Fields and choose deterministic encryption where possible, as this preserves more functionality than the probabilistic scheme.
4. Restrict the “View Encrypted Data” permission — Review which profiles and permission sets currently carry this permission and trim access down to only those roles that genuinely require it.
5. Validate your automation and reports — After encrypting, test any flows, validation rules, or reports that reference those fields to catch any breakage before it affects end users.

Treating PII encryption as part of your initial custom object design, rather than a retrofit, will save considerable effort and reduce the risk of gaps in your compliance posture.

Can You Encrypt Standard Account Name Field in Salesforce?

Technically, yes – the standard Account Name field can be encrypted with the help of the Shield Platform Encryption. However, this action also introduces a lot of drawbacks that make it inadvisable for most organizations.

Account Name is one of the most referenced fields in Salesforce. It drives not only search results, but also list views, related lists, and a wide range of AppExchange integrations. Encrypting the Account Name field will either degrade or break most of these touchpoints while also disrupting the capabilities of many native Salesforce features that rely on Account Name.

In situations where the business has a genuine compliance requirement to protect the Account Name field – it would be a lot more practical to apply strict field-level security with profile-based access controls instead of using encryption. If encryption is truly necessary, testing the results of the encryption in a sandbox environment is highly recommended – and be prepared to restructure a major portion of your company’s reporting and automation logic before moving to production.

Best Approach for Using Encrypted Fields in Apex Triggers

Apex triggers are capable of accessing and working with encrypted fields, but the lack of caution may lead to the appearance of insidious bugs that are often difficult to diagnose. Following a few key guidelines will help ensure the consistency and maintenability of your trigger logic:

• Avoid direct value comparisons — Encrypted field values should not be used in equality or pattern-matching comparisons within trigger logic. Instead, handle any branching logic that depends on sensitive values through separate, non-encrypted flag fields where possible.
• Test in a sandbox with encryption active — Many trigger issues with encrypted fields only surface when encryption is actually enabled. Always test in a sandbox that mirrors your production encryption configuration, not one where encryption is inactive.
• Be cautious with before-insert and before-update contexts — Encrypted values may behave differently in before vs. after trigger contexts. Validate your logic explicitly in both contexts rather than assuming consistent behavior.
• Account for null handling — Depending on your encryption scheme and user permissions, encrypted field values may return null to certain running users. Build explicit null checks into any trigger that reads encrypted fields to avoid unhandled exceptions.
• Document encrypted field dependencies — Any trigger that touches an encrypted field should be clearly documented as such, so future developers know to account for encryption-related constraints when modifying the logic.

Salesforce Data Governance From GRAX

While Salesforce encrypted fields and Salesforce Shield allows you to control data within the Salesforce platform, these security controls are limited to data utilization on-platform. Data controls do not extend to data utilization as data is imported and exported out of Salesforce.

To remedy this issue, GRAX is working on a new data governance product. This solution is designed for organizations that use Salesforce but must also adhere to multiple complex regulatory requirements. This technology complements existing Salesforce Shield capabilities while also creating an auditable chain of custody for compliance data.

Contact GRAX today if you would like to be the first to check out our new product. You can also try GRAX for free.

FAQS

What is a Salesforce encrypted field?

A Salesforce encrypted field is a data security feature that protects sensitive information by encrypting it at rest within the Salesforce database. This means the data is stored in an unreadable format and can only be viewed by users who have the appropriate permissions, such as “View Encrypted Data.” Encrypted fields are commonly used to safeguard personally identifiable information (PII), financial data, and other regulated data types within Salesforce environments.

When should you use encrypted fields in Salesforce?

Encrypted fields in Salesforce should be used when storing sensitive, regulated, or high-risk data that could lead to compliance violations or business risk if exposed. This includes information governed by frameworks like HIPAA, GDPR, PCI-DSS, or other data protection regulations. However, organizations should be selective, as over-encrypting fields can negatively impact usability, reporting, and automation within Salesforce.

Do encrypted fields impact Salesforce functionality?

Yes, encrypted fields can significantly impact Salesforce functionality, particularly in areas like reporting, search, automation, and integrations. Certain features—such as list view filters, report filters, and SOQL queries—may be restricted or behave differently when encryption is enabled. Because of these limitations, it’s important to evaluate how a field is used across workflows before applying encryption to avoid breaking critical business processes.

Can encrypted Salesforce data be accessed outside the platform?

No, Salesforce encryption protections are limited to data within the Salesforce platform itself. Once data is exported, integrated into another system, or moved into a data warehouse, those encryption controls no longer apply. This creates a potential security gap, making it important for organizations to implement additional controls when managing Salesforce data outside the platform.

Can you search encrypted fields in Salesforce?

Salesforce does allow users to search encrypted fields using standard search functionality, as long as they have the appropriate permissions to view the data. However, there are important limitations—encrypted fields cannot be used effectively in report filters, list views, or certain SOQL clauses like WHERE or ORDER BY. Even with deterministic encryption, organizations should expect reduced flexibility when querying and filtering encrypted data.