About Encrypted Fields

An encrypted field can contain encoded data to prevent unauthorized access to sensitive information (example: Identity information, financial data, etc.).

Encrypted fields can be exposed in CSM using field controls on a form. When an encrypted field is added to a form, it is accompanied by a button control with a decrypt command Decrypt Field Button . In new records, encrypted fields are enabled and blank. Data entered into an encrypted field is masked when the decrypt/encrypt button is selected or when the record is saved (in the Browser Client, tabbing out of an encrypted field also masks the data). The values are encrypted when the record is saved. In existing records, encrypted fields appear as read-only masked text boxes. Users with viewing rights can select the decrypt button Decrypt Field Button to view data in encrypted fields. All encryption/decryption attempts are tracked in Journal-History records (enforced) and Splunk server logs (optional). Entering and viewing data in an encrypted field requires Define Business Object Rights (Access to Data).

Encrypted fields are more restricted than regular fields. Encrypted fields:

Cannot be searched, displayed in grids, or used in many of the areas where regular fields can (examples: One-Step Actions, expressions, widgets, etc.).
Cannot be used in reports as parameters or results.
Are stored in a database table separate from Business Objects, and cannot be indexed.
Cannot have default or calculated values, or set values based on lifecycle state.
Cannot use validation or auto-population.
Are limited to a maximum of 255 characters.
Cannot be permanently decrypted or converted back to unencrypted fields.

The following cannot be encrypted:
- Rich Text fields
- Attachments
- Email messages
- Stored values
- Public IDs

Configure your system to enable field-level encryption and follow these best practices for encrypting fields.