The short version: every field in Salesforce carries four pieces of classification metadata: compliance categorisation, data sensitivity level, data owner and field usage. None of it enforces anything. It is documentation attached to the field itself rather than to a spreadsheet that goes stale, and it becomes valuable the first time somebody asks where personal data lives in your org and expects an answer the same day.
The four fields
Open a field in Object Manager and edit it. Below the usual definition sits the classification block.
- Compliance Categorisation. A multi-select picklist covering the regimes the field falls under: PII, GDPR, HIPAA, PCI, CCPA and so on. You can add your own values, which is worth doing if you have internal categories the standard list misses.
- Data Sensitivity Level. A single picklist, shipping with Public, Internal, Confidential, Restricted and Mission Critical. Customise the values if your organisation already has a scheme, because two competing vocabularies is worse than none.
- Data Owner. Who is accountable for this field. Not who built it.
- Field Usage. Active, deprecate candidate, or hidden. This one has nothing to do with compliance and is quietly the most useful of the four.
Why bother
The honest reason is that the question gets asked, usually at the worst time. A subject access request, a security questionnaire, a penetration test finding, a new data processing agreement. Somebody has to produce the list of fields holding personal data, and without classification that means a person reading two thousand field labels and guessing.
Classification makes it a query. FieldDefinition exposes the values, so the inventory is one line:
SELECT EntityDefinition.QualifiedApiName, QualifiedApiName,
SecurityClassification, ComplianceGroup, BusinessStatus
FROM FieldDefinition
WHERE ComplianceGroup INCLUDES ('PII')That result is the start of a record of processing activities, and it is current, because it comes from the org rather than from a document someone updated in 2023.
Second reason: tooling reads it. Data Mask can select fields to mask in sandboxes based on their classification, which means a correctly classified org gets safe sandboxes without maintaining a separate list of fields to scramble. Anything relying on the classification only works if the classification is there.
Third reason, and the one that pays off weekly: Field Usage. Marking a field as a deprecate candidate is a note to the next admin, visible where they will actually look, saying do not build anything new on this. Every org has forty fields nobody dares delete. Labelling them stops the count reaching eighty.
It enforces nothing
Setting a field to Restricted does not restrict it. There is no permission that keys off sensitivity level, no automatic encryption, no report blocking. A field marked Mission Critical with field-level security open to every profile is open to every profile.
Classification is the map. Field-level security, sharing, Shield Platform Encryption and login restrictions are the locks. Treat the classification exercise as the thing that tells you where to put the locks, and check that the two agree: a Restricted field readable by all internal users is a finding, and the query above is how you find it.
Doing it without a six-month project
Retrofitting every field at once never finishes. What works:
Start with the obvious personal data. Email, phone, address, date of birth, national identifiers, bank details, anything holding health or biometric information. That is usually under a hundred fields and covers most of the risk.
Do it per object, and do the busiest objects first. Contact, Lead, Person Account, plus whatever custom object holds your customer records.
Then make it part of the definition of done for new fields. Classification is part of the field definition in the Metadata API, so it travels with the deployment, and a pull request that adds a field with no classification can be rejected in review like any other missing piece.
Assign data owners to a role or a named function, not a person. People change jobs. “Head of Customer Operations” survives.
Frequently asked
Can I set classification in bulk? Not comfortably through the interface, one field at a time. The practical route is the Metadata API or Tooling API, generating the changes from a spreadsheet you have already reviewed.
Does it deploy between orgs? Yes. The values are part of the field metadata, so they move with the field and stay consistent across sandboxes.
Does classification appear on the field list? Yes, Object Manager can show the classification columns in the fields list, which makes reviewing an object quick once the values are populated.
Should managed package fields be classified? You generally cannot change them, which is itself worth recording. Ask the vendor for their classification, because for a compliance inventory the field’s origin does not matter.
