FAQs: Encrypting standard fields
What does encrypting a standard field protect?
Encryption adds protection to sensitive data stored in an eligible standard field by converting the stored value into a protected format. It is intended for information that requires stronger safeguards, such as personally identifiable or financially sensitive customer data.
For example, if a standard field contains information that should not be broadly exposed, encryption can help protect that stored data in addition to the platform’s existing security controls.
Are all standard fields eligible for encryption?
Not necessarily. Encryption is available only for supported standard fields. Administrators should verify field eligibility before planning a security configuration around encryption.
If a required field cannot be encrypted, consider whether an eligible encrypted custom field is appropriate for collecting the sensitive value instead.
Can encrypted standard fields be used to protect personally identifiable information?
Yes, encryption is appropriate when a standard field stores sensitive personal information that the organization must protect under its internal privacy practices or applicable obligations.
For instance, an organization handling customer requests may want to apply stronger protection to a field containing sensitive identifying information rather than exposing that data unnecessarily across support workflows.
Does encryption replace field-level permissions?
No, Encryption and field permissions address different needs. Encryption protects the stored value, while field permissions control which user profiles can view or edit a field.
For stronger protection, use both controls together. For example, configure a sensitive field as encrypted and restrict it to Read Only or Don’t Show for profiles that do not require access.
Can an agent still view an encrypted field?
Whether an agent can view a field depends on the organization’s field-permission configuration and the agent’s assigned profile. Encryption does not automatically grant or remove user access.
Administrators should carefully review which roles need access. A billing specialist may need to view an encrypted billing-related field, while a general support agent may not.
How can access to sensitive standard-field data be restricted?
Use Field Permissions to set the appropriate access level for each profile.
- Navigate to Setup > Customization > Layouts and Fields.
- Select Fields Permissions.
- Select the:
- Module
- Profile
- Choose the access level for the required field:
- Read and Write - users can view and edit the field.
- Read Only - users can view but cannot edit the field.
- Don’t Show - users cannot view or edit the field.
- Click Save.
For example, a financial-information field in Contacts can be hidden from general support agents while remaining available to an authorized billing profile.
Can a mandatory standard field be hidden or made read-only for a profile?
No, A field marked as mandatory cannot be configured as Read Only or Don’t Show in Field Permissions. This prevents a profile from being blocked from providing information that the layout requires.
Can Light Agents be granted edit access to a sensitive field?
No, Users with the Light Agent profile cannot be assigned Read and Write access to fields. Their access must be limited to the supported permission levels available for that profile.
Can administrators check how a field looks for different profiles before saving?
Yes. After configuring field permissions, administrators can preview the layout for individual profiles before saving the configuration. This helps confirm whether a field is displayed, hidden, editable, or read-only as intended.
For example, an administrator can preview a phone-number field as a support agent to verify that it is read-only, then preview it as a support lead to verify that it is editable.
