Encrypted Custom Fields

Do you currently use Salesforce.com to track data that is of a highly sensitive and confidential matter? To some extent, all of the data that we entrust into Salesforce.com servers is highly sensitive – but in particular, what information about your Customers are you tracking in Salesforce.com. 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 Salesforce.com 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 Salesforce.com, “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 salesforce.com, 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 Salesforce.com (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 Salesforce.com 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 Salesforce.com. 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 Salesforce.com Help & Training section, searching for “Encrypted Custom Fields” for more details.

Upgrade Problems with Summer'08 Release

There seems to be a problem with the Summer'08 Release on some Salesforce.com Server instances.

NA3 was scheduled to be upgraded to Summer'08 starting at 8:00 PM PDT, and the upgrade was supposed to be completed four hours later. My company's implementation of Salesforce is on the NA3 instance, and I can confirm that the upgrade DID start. There was a service outage for several hours, and we switched over to our offline backup applications (our operations are 24x7, and we need access to information in SFDC at all hours of the day, particularly Contacts, Cases, Solutions, and some custom object data).

Sevice was restored at 12:00am PDT, but even after the maintenance window, the NA3 instance is not yet running on the Summer'08 Release. The http://trust.salesforce.com/trust/status/ is not providing any helpful information. While it mentions the other North America instances (NA2, NA4, NA5), it makes no reference to issues or status on NA3:

12:00 am PDT : NA4 Summer '08 Upgrade Upgrade Has Completed The Summer '08 upgrade work to the NA4 instance has completed successfully!

12:12 am PDT : NA2 Summer '08 Upgrade Upgrade Has Completed The Summer '08 upgrade work to the NA2 instance has completed successfully!

1:15 am PDT : NA5 Summer '08 Upgrade Upgrade Has Completed The Summer '08 upgrade work to the NA2 instance has completed successfully!

7:59 am PDT : NA5 showing intermittent inaccurate maintenance notifications. A small but noticable percentage of logins to the NA5 org are still displaying the maintenance notification from the Summer '08 upgrade performed last night. These notifications are erroneous and the maintenance is not ongoing at this time. We are working to remove the incorrect messaging and should have this resolved very soon. We apologize for any inconvenience or confusion originating from this incident.

8:09 am PDT : NA5 showing intermittent inaccurate maintenance notifications. RESOLVED: The erroneous messaging affecting some NA5 logins has been removed.

I've opened a case with Salesforce.com, and will update the blog as further information becomes available.

Work Is Something I Do, Not Somewhere I Go ...

A friend forwarded an eMail to me, a classic example of "Dilbert-Darwinism", he cited. The letter is from the CEO of his company -- here's an excerpt:

"I believe more inter-departmental communication at [Company] should be a priority because it will give all levels greater opportunity for teamwork. Being in multiple buildings and working different hours are two impediments to getting this done. We will improve on the first of these by consolidating team members in Buildings 3 and 4. To fix the second, the Executive Team has agreed to adopt standard, core work hours, 8:30 AM to 5:30 PM Monday through Friday. This will improve the opportunity for [Company] employees to team with your colleagues in other departments."

Dilbert-Darwinism, I certainly agree. I'm so glad that I'm not similarly shackled at my company.

Work is something I do, it's not somewhere I go.

I've worked very hard to make my entire organization as efficient remotely as they are in the office. I've used platforms like Salesforce.com to give them access to the very best CRM tools over the web: customer / supplier / partner / vendor information, contact info, sales order information, cases & trouble ticket tracking, knowledbase / solution articles, inventory tracking, technical documentation, bug tracking, project management. All accessible to them, 24x7, from anywhere in the world that they can get an internet connection.

All members of my team have laptops and USB headsets, and all of their calls are processed through VOIP telephony applications on their laptops -- so they can be taking calls from the ACD phone system while at the office, logged in from home, or snarfing down a donut at some internet cafe.

GoogleTalk is integrated within our CRM application, so we can broadcast quick questions to each other -- and get quick answers. We carry Blackberrys on our hip, and Blue Tooth wireless ear pieces clipped to our ears, so that if ever we are disconnected from the web, we still have constant communication with the hive -- by phone, email or text messaging.

We have team GoToMeeting accounts, so we can quickly collaborate, train or share screen information. There are very few companies who have done as much as we have to allow their work force to be as seamlessly proficient remotely as they are in the office.

And we work crazy, insane hours. I don't mean just a few of us. I am constantly text messaging or chatting with work colleagues from all areas of the company, long after office hours. I've hosted late night conference calls with a dozen or more colleagues on the line, calls that started in the late evening and drifted into the early morning. And I've collaborated on PowerPoint presentations with colleagues, while we both multi-tasked to get our kids off to school in the morning.

I work in my underwear at home, late at night. I work on a WiFi connection at the park, while my kids climb the monkey bars. I work on a FIOS broadband connection at the cottage, after convincing my Dad he really needed high-speed internet at the family beach house. And yes, I put in an appearance at the office, five days out of seven, for about 8-10 hours a day.

Ask my colleagues and I to be in the office between the hours of 8:30am and 5:30pm? I can't think of anything that would make us LESS productive.