For several years now, Salesforce has been the CRM of choice for ambitious organizations. The platform’s many benefits — including its customizability and extensive app ecosystem — makes it extremely capable of growing alongside rapidly evolving organizations. The result is that, for many, it’s more than a CRM — and, as such, the data it stores is often beyond that of a typical CRM, too.
So as the platform comes to house an increasing number of business functions, there is a clear need for Salesforce data classification to manage the increasingly diverse nature of potentially sensitive or confidential information housed in it.
Salesforce offers its own out-of-the-box tool for data classification. There are also third-party tools for handling it, as well as apps like Netwrix Strongpoint that augment the platform’s native capabilities with enhanced reporting and automation.
On this page, we’re diving in with a comprehensive look at data classification in Salesforce — what it is, why it’s important and how to handle it efficiently.
What is data classification in Salesforce?
Data classification is exactly what it sounds like — a formal process of organizing data based on different categories such as risk, sensitivity level, compliance requirements. This is important for several reasons: security, regulatory compliance, data management, etc.
The bottom line is that businesses store a lot of data, of different types and sensitivity levels. Data classification is simply a way of organizing data and allocating resources more appropriately. In other words, separating the wheat from the chaff: identifying what your important data is, and where it’s located.
Data classification in Salesforce: an overview
In Salesforce, data is captured by fields. So, in order to classify data in Salesforce, we must look at the field level and determine what is being inputted.
Salesforce introduced data classification metadata fields as part of its ‘19 summer release. With this feature, any user with the “Customize Application or Modify Data Classification” permission can add data classification tags to any field in a standard or custom Object.
These tags are stored as metadata on the field. Salesforce’s data classification feature is automatically enabled for all Orgs; out-of-the-box, default sensitivity settings are enabled for standard fields. However, modifying these settings or enabling data classification on custom fields must be done manually.
Benefits of Salesforce data classification
Data security
You can’t protect something if you don’t know where it is — and data is no exception. Data classification can form the basis for a comprehensive security program for Salesforce teams; by identifying objects, fields and other repositories for sensitive data, you can put in place effective controls and restrict access only to the users who need it.
Conversely, data classification can also alert you if critical data unexpectedly appears in an unsecure repository, so you can quickly quarantine it and more effectively troubleshoot the underlying issues that led to its exposure.
It’s also important to remember that Salesforce data classification can help with resource allocation. Ultimately, from both a usability and a cost perspective, it doesn’t make sense to apply restrictive data controls across the board. One of the main benefits of data classification in Salesforce is that it shows you where additional controls are most necessary, so you can apply resources effectively.
Regulatory compliance
Data security and compliance are closely related; auditors will want to see effective, scalable controls around regulated content, whether it’s Rev Cloud pricing controls for organizations that are subject to SOX, or patient records stored in Health Cloud for care providers subject to HIPAA. If you know where this data is, you can track and report on it more easily, and ultimately reduce the time and expense of audit prep.
Another extremely critical use case for Salesforce data classification is GDPR, CCPA and other privacy compliance needs. Manually satisfying data subject access requests for these standards can be time-consuming. But when you know where PII is stored, the process can be automated — this of course saves you time and money, but it also increases user confidence in your organization.
Access management
Your Salesforce Org stores critical information about your customers, prospects and business — excessive or outdated permissions around that data is a clear source of risk, regardless of any compliance requirements.
For obvious reasons, effective access controls require a comprehensive understanding of where sensitive data is stored. With this information readily available, it’s much easier to see if the appropriate users have view, edit or delete privileges.
Data clean up
Finally, classified data is easier to clean, too. Why is this important? Regular cleanup projects — removing obsolete data, consolidating duplicate entries, etc. — help maintain overall data quality. Eliminating technical debt means you’ll avoid paying additional licensing fees for contacts you don’t need. And when users are confident in the quality of data in their Org, they can navigate the system more efficiently — and they’ll be more open to bringing more of their business processes into the system.
For some more details about the benefits of Salesforce data classification, check out our blog.
Salesforce data sensitivity levels
Salesforce offers multiple options for configuring data classification metadata fields. How and why you are using the feature will determine the best way to set it up. Out of the box, users are provided with five default sensitivity levels:
- Public data is viewable by anyone but requires additional permissions to alter or delete
- Internal data is available to authorized Salesforce users, but not shared publicly
- Confidential data is available to an approved group of users; under certain circumstances, it may be shared more broadly
- Restricted data is typically available to an approved group of users, and often restricted by an NDA or MSA
- Mission-critical data is shared among a small group of approved users, and almost always restricted from wider circulation by an NSA
Compliance categorization
Sensitivity level isn’t the only way to classify data. Salesforce’s data classification feature also provides the option of classifying data by compliance categorization — giving companies subject to the following standards an easy way of identifying data that requires additional protection or controls:
- CCPA (California Consumer Privacy Act)
- COPPA: (Children’s Online Privacy Protection Act)
- GDPR: (General Data Protection Regulation)
- HIPAA: (Health Insurance Portability and Accountability Act)
- PCI: (Payment Card Industry)
- PII: (Personally Identifiable Information)
Salesforce data classification metadata fields
Salesforce’s data classification feature gives users a few additional metadata fields for managing and tracking sensitive information:
Data owner
The ‘data owner’ of a field is the internal authority responsible for that particular field. This will, ideally, be someone who understands the importance of, and the broader context for, the data contained by the field. They should also be responsible for determining the sensitivity level and the controls or protections that should be applied.
Field usage
The ‘field usage’ classification is typically used for data cleanup projects. Data owners can specify whether or not data contained in a field is in use, or if it is a potential candidate for deprecation. The available options are:
- Active: the field is in use and visible
- Deprecate candidate: The field is no longer in use, and can potentially be deprecated following an investigation into the impact
- Hidden: The field is not visible, possibly under investigation for deprecation, and should not be used
Customizing Salesforce’s data classification settings
Customizing Salesforce’s data classification metadata fields is easy. Here’s a quick demo showing how to configure the default settings for the EmployeeID field in the Account object:
The downside to data classification
There are clearly a lot of reasons why data classification can benefit companies running Salesforce. There is also a lot of flexibility in how they go about implementing it. However, as versatile as Salesforce’s native data classification tool is, there are some downsides.
Data classification takes time Unless you use a third-party app (more on that below), data in Salesforce must be classified manually. That means going through every field, in every object and determining whether or not the data it contains needs to be classified. In a complex or mature Org, that translates to a lot of initial work, for benefits that may not be immediately obvious or quantifiable.
Data classification requires resources
The cost of getting started with data classification isn’t just financial. A Salesforce data classification project will likely tie up knowledgeable team members with time-consuming work that will prevent them from taking on more demanding projects.
Data classification must be manually updated
Even if you have unlimited time and resources to classify your Salesforce data, what happens when things change? Salesforce is built for continuous evolution — adding a new app or feature changes your data model, which can affect how data is classified in it. Currently, there is no native way to assess the impact of development work on data classification and track how things change over time.
Netwrix Strongpoint’s data classification feature
What if there was a way to get all the benefits of data classification in your Salesforce Org, while automating the most time-consuming parts of getting it set up and keeping it updated?
That’s exactly what Netwrix Strongpoint does. Our native data classification app sits in your Org — no data to import or integrations to worry about — and automatically finds and classifies sensitive data according to the rules you’ve set out. Then, we give you a suite of tools for managing it — managing user permission levels, automating data subject review/deletion requests, running data cleanup projects, and tracking everything in an audit-ready package.
