People working on laptops

Organize Salesforce Data With Data Classification Metadata Fields

by Nikita Verkhoshintcev

Just recently, I passed the Salesforce data architect certification exam.

When preparing for that one, I noticed that even though there are certification preparation materials on Trailhead, those were not that well organized for this particular exam.

There are a lot of articles, PDFs, and links to the documentation, but not so many structured training modules.

It also felt repetitive, e.g., on the data skewer issues, but, for example, lacked the details on the master data.

I thought it would be a good idea to write down a series of short posts about different topics you need to know to pass the data architect certification exam successfully.

These are my thoughts based on my experience preparing for the exam and the questions I encountered.

I hope someone will find it helpful to prepare for the certification exam. It could also be useful for admins to improve the data quality in Salesforce organizations.

Let's get started!

Data Classification Metadata Fields

I want to discuss the data classification fields in the first post.

I encountered a few questions about these, but it is still vital to understand what those fields are and, most importantly, how you can access them and run the reports.

Salesforce has data classification metadata fields that are out of the box.

These fields help you to organize all org data into relevant categories to use and protect more efficiently, which is crucial for risk management, compliance, and data security. It also makes the data traceable and searchable.

One of the most important reasons for using such fields is regulatory compliance, e.g., GDPR in Europe.

For example, the social security number field contains very sensitive data. Therefore, as an admin, you should classify it accordingly.

You can use the data classification to guide access, reporting, and data compliance decisions.

The data classification metadata fields are available on all standard and custom objects.

Salesforce offers four data classification metadata fields:

  • Data Owner
  • Field Usage
  • Data Sensitivity Level
  • Compliance Categorization

The data owner is a person or group associated with this field. The data owner understands the importance of the field's data to your company and might be responsible for determining the minimum data sensitivity level.

The field usage tracks whether the field is in use and has the following default values:

  • Active — In use and visible.
  • DeprecateCandidate — Planned for deprecation and no longer in use.
  • Hidden — Not visible and possibly planned for deprecation. Use with caution.

Note: Changing the value of Field Usage doesn't hide or expose the field.

The data sensitivity level specifies the sensitivity of the data contained in the field. The default values are:

  • Public — Available to the public to view but not alter.
  • Internal — Available to company employees and contractors. You must not share this data publicly, but you can share it with customers, partners, and others under a non-disclosure agreement (NDA).
  • Confidential — Available to an approved group of employees and contractors. Law, regulation, or a company master service agreement (MSA) doesn't restrict this data. You can share it with customers, partners, and others under an NDA.
  • Restricted — Available only to an approved group of employees and contractors. Law, regulation, an NDA, or a company MSA likely restrict this data.
  • MissionCritical — Available only to a small group of approved employees and contractors. Third parties with access could be subject to heightened contractual requirements. Law, regulation, an NDA, or a company MSA almost always restrict this data.

Compliance categorization specifies the acts, definitions, or regulations related to the field's data. The default values are:

  • 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
  • PersonalInfo — Personal information. The field data is for use with the Enhanced Personal Information Management feature. Only available if Enhanced Personal Information Management and Digital Experiences are enabled.
  • PII — Personally Identifiable Information

Note: Compliance categorizations don't appear on fields suffixed with **pc when you query the Person Account object. While **pc fields appear in Person Account queries, they reside on the Contact object. To see their compliance categorization, query the Contact object instead. The same limitation applies whether you're using Tooling API (FieldDefinition) or Metadata API (CustomField).

Setting Up The Data Classification Metadata

The Salesforce Setup contains the Data Classification menu items with its settings.

You can decide if you want to use a default data sensitivity level. Select or deselect the "Use default data sensitivity level" checkbox.

It will apply a default data sensitivity level to all contacts, leads, person accounts, and users when enabled.

Some fields contain data sensitivity values by default that are visible in the UI after you enable them.

For example, the email field has a confidential value, and when you enable that checkbox, the default value is applied and visible in the UI.

You can also customize the values for the Compliance Categorization and Data Sensitivity Level fields on that settings page.

Alternatively, you can edit those picklist values via the StandardValueSet Metadata API type.

Note: You can edit the Field Usage values only via the StandardValueSet Metadata API type.

The metadata types for those fields are

  • Compliance Categorization — ComplianceGroup
  • Data Sensitivity — SecurityClassification
  • Field Usage — FieldBusinessStatus

Optionally, you can also upload and download the data classification configuration.

You will get the CSV file with the object, field names, and field-specific data sensitivity level when downloading the data classification. The file contains only the fields with the defined data sensitivity.

Note: The file includes the first 2,000 records for each data sensitivity value.

You can also upload the data classifications via the CSV file. It should contain a maximum of 10,000 rows. Each row must include the object name, field name, and a data sensitivity level.

For example:

Contact,Birthdate,Confidential
Account,AnnualRevenue,MissionCritical

Accessing the Fields and Running Reports

There were no questions about the types of regulations or sensitivity levels in the test, so it is good to have the overall knowledge about the fields, but there is no need to remember the exact values.

Based on the test, knowing how to access and run reports on these fields is the most important.

You can access those data classification metadata values via the FieldDefinition object.

For example,

SELECT Id, DeveloperName, Description, BusinessOwnerId, BusinessStatus, SecurityClassification
FROM FieldDefinition
WHERE EntityDefinitionId IN ('Account', 'Lead')

Here is a list of field API names:

  • Data Owner — BusinessOwnerId
  • Compliance Categorization — ComplianceGroup
  • Data Sensitivity Level — SecurityClassification
  • Field Usage — BusinessStatus

You can also access those fields in the reports to help meet your data management policies.

  1. Create a new report type on Entity Definition.
  1. Add FieldDefinitions as a child object in this report type.
  1. Create a new report using the new report type.

Conclusion

In this post, I described the Salesforce data classification metadata fields that help organize the data, manage the risks, and comply with the regulations.

I also mentioned how you can query these metadata fields and run reports to help you trace and search the data.

I hope this guide will help you protect and manage your Salesforce data efficiently.

Nikita Verkhoshintcev photo

Nikita Verkhoshintcev

Senior Salesforce Consultant

I'm a senior Salesforce consultant based in Helsinki, Finland, specializing in Experience Cloud, Product Development (PDO), and custom integrations. I've worked as an independent consultant building custom Salesforce communities and applications since 2016. Usually, customers reach out to me because of my expertise, flexibility, and ability to work closely with the team. I'm always open to collaboration, so feel free to reach out!

Let's work together!

Do you have a challenge or goal you'd like to discuss? We offer a free strategy call. No strings attached, just a way to get to know each other.

Book a free strategy call

Stay updated

Subscribe to our newsletter to get Salesforce tips to your inbox.

No spam, we promise!