Monday, June 23, 2008

Encrypted Custom Fields

Do you currently use to track data that is of a highly sensitive and confidential matter? To some extent, all of the data that we entrust into servers is highly sensitive – but in particular, what information about your Customers are you tracking in Social security numbers? Credit card numbers? Could one of your users casually run a report that collects all this information, export it to Excel, and then print or otherwise allow that data to fall into the wrong hands?

If you have data in that would cause damage or great embarrassment to your organization (or your personal reputation, as the custodian of this data) if it fell into wrong hands, then read on!

Here’s a little trick from the Winter’08 Release that I completely missed the first time around: Encrypted Fields. According to Katherine Owens at, “Encrypted Custom Fields are a new field type that enables customers to store sensitive data in encrypted form and apply a display mask when the data is displayed (e.g., Social Security Number: XXX-XX-1234). Encrypted custom fields allow customers with regulatory requirements around Personally Identifiable Data or Credit Card data to store that data inside, rather than having to maintain a separate data store in-house, allowing them to take full advantage of the benefits of on-demand.”

To date, I’ve been tracking some sensitive data in (VPN and system access IP information, including login names and user passwords). For security, I’ve locked access to these fields down with custom profiles – but I’ve still been very leery of storing this data in a text format, especially when I open up my instance to Customer Support for resolution of open cases. So I decided to give Encrypted Fields a test.

Turning Encrypted Fields On
You can’t use Encrypted Fields unless you first get it enabled by To do this, you need to open a Case with Salesforce. While logged in to Salesforce, click “Help & Training” and then select the “My Cases” tab. Click on the “Log a Case” link.

It can take upwards of a week to get this feature enabled (I put my request in on a Wednesday, and it was enabled the following Sunday).

Adding Custom Encrypted Fields
Once enabled, you will see a new data type option when creating new Custom Fields:

On subsequent screens, when defining the custom field, you can specify a mask for the field. User profiles who have the “View Encrypted Data” configuration enabled will be able to view the field normally. Users who do not have the “View Encrypted Data” profile will see the mask. For instance, if you created a “Credit Card” custom field with the mask type set to “Last Four Characters Clear”, a user without appropriate permissions to view encrypted data would see a credit card number as XXXX-XXXX-XXXX-1234. They would see the credit card number in this format when viewing the data in reports, on page layout views, etc.

NOTE: User profiles that have the “Modify All Data” permission will not be able to see the value of encrypted data fields. Only user profiles with “View Encrypted Data” setting enabled can see the content of these fields in their non-encrypted form.

You still need to administer your profile settings, and ensure that the right users have access to the encrypted data. However, now you can set it up so that all users can see the field, and only a select few users can see the data in a non-encrypted format.

This is particularly helpful if you have a group of users who will be entering the field information in routinely – but once the data is entered, you don’t want them to be able to view the data. These Users can see if the field is empty or filled with some value, and if a mask type is selected, they can see the last few digits (such as when confirming credit card information during a follow-up call).

Nitty Gritty
There are some limitations with the encrypted data field. The field length is restricted to 175 characters in size, and it cannot be type cast as Unique or External ID. An encrypted field cannot be configured with a default value.

You can’t use encrypted fields in filters (such as list view filters or report filters). In other words, a user can’t create a report or list view showing all credit cards ending in 1234 – even if the configured mask type for that field normally allows them to see the last 4 digits in the encrypted field. You can display the encrypted field in the list view or report results (i.e., it can be a column in your report, it just can’t be used as a filter setting for that report).

Similarly, you can’t use the encrypted fields in SOQL “where/order” clauses, formula fields, workflow rules, workflow field updates, approval process entry criteria, and approval step criteria.

If you clone a record that has encrypted custom fields, Salesforce will copy the data from the field ONLY if the user has the “view encrypted data” permission.

If you use encrypted fields in an email template, the results will always be displayed with the selected mask settings (XXXX-XXXX-XXXX-1234), even if the user creating the template has the “view encrypted data” priv.

If you manipulate the data with APEX code, the value is always unmasked, regardless of the permissions of the user who triggered the apex code.

When the data is displayed in a Visualforce page or a custom s-control, the value will be displayed based on the users “view encrypted data” profile settings.

The View Encrypted Data field is disabled for all user profiles – even the Administrator profile. I found this one to be the most annoying, but I understand the reason for it. If you are an administrator, and need access to this data, you’ll need to clone the Standard Administrator profile and give that cloned profile the ability to see encrypted data.

You can’t convert your existing custom fields to encrypted fields. Instead, you’ll need to create your new custom encrypted fields (blank), and then use a tool like the Apex Data Loader to export all existing data, and then import it into the encrypted field. Once you’ve done that, you can go and delete the old non-encrypted fields.

Want more information? Search the Help & Training section, searching for “Encrypted Custom Fields” for more details.


  1. We are having trouble with encrypted fields because we are trying to send out a confirmation receipt to customers to tell them how much they paid and that they paid with a card number of such and such but only show the last 4 numbers. This is all that shows inside Salesforce, all the rest is starred out. But when we use a VisualForce email template (a necessity due to using custom cases and custom order line items) the apex in the visualforce template seems to be decoding the encryption because the entire CC number shows up. Any ideas as to what we can do about this? Work arounds or something?

  2. We are having trouble with the encrypted fields and apex decoding them. We are trying to send out an email confirmation to customers to tell them that we have received their order and this was the cost and they paid with such and such credit card, but only show the last 4 digits of the card. Inside salesforce this works and if we use a regular email template it works, but since we need to use a visualforce template in order to include custom object line item information the entire card number is showing up in the VisualForce template. Any ideas as to how to get around this?

  3. First, that's probably defect / bug. Visualforce email templates should behave the same way standard email templates do, with respect to displaying the content of encrypted fields. If you haven't done so already, I'd recommend opening a Case with Support, and reporting this as a defect.

    That said, as a workaround, you can solve this problem with some simple JavaScript embedded in the Visualforce Email Template (see p.157 of the Winter'10 Visualforce Develoeprs Guide for a sample:

    Write a function that takes the ecrypted field value, does some string manipulation and returns a formated string value as xxxx-xxxx-xxxx-####, where #### are the last 4 digits of the credit card number.

  4. Good article...Thanks!!!

  5. A very good and knowledgeable article....Thanxxx

  6. ... and just to add to the limitations: you cannot change an exiting field to the type: Text (encrypted)

  7. Simple and very informative!!!! Thanks for your effort

  8. Thanks its really helpful for me.