Encryption at Rest in Simpplr

By default, Simpplr encrypts data in transit for all customers. While Simpplr offers a host of security features, customers who want additional protection can add on encryption at rest (EAR). Simpplr uses the same EAR as the Salesforce Shield Platform, protecting your company data and ensuring the highest standards of security.

What is supported?

Simpplr leverages the Salesforce Shield Platform to help customers benefit from a higher security environment. The following are all supported by encryption at rest (EAR):

  • All text fields in Simpplr objects, including but not limited to:
    • Sites
    • People
    • Content
    • Alerts
    • Search data
      • Text
      • Rich text area
      • Text area
      • Long text area
  • All phone type fields in all Simpplr objects
  • All URL type fields in all Simpplr objects
  • All email type fields
  • Integration data (e.g., external apps)
  • Date/Date time: Partially


What is not supported?

Simpplr’s EAR delivers the highest level of security, however, there are certain limitations as outlined below. The following are NOT supported by EAR:

  • ID: Auto-generated record IDs*
  • Checkboxes* (e.g., Yes/No values)
  • Picklists* (e.g., pre-defined set of options such as content type)
  • Date/Date Time (e.g., content publish start date)
  • Fields in the Salesforce standard user object (See next section for more information)

*Note that these do not expose and personal identification information. 


How to protect unsupported fields

Because Salesforce does not support encrypting the user object, Simpplr recommends storing only the minimum required attributes in the object. Rest assured, Simpplr guarantees and automates a process to protect and ensure data privacy by storing random values in the standard user object fields.

Salesforce Standard User Objects

Simpplr recommends storing random values in place of the following fields:

  • Last Name attribute: Store random values in the Last Name attribute
  • Username attribute: Store the username with. any valid value, as it does not need any personal identification information (PII) in the username.
  • Email attribute: Create an alias that does not contain any PII for every user email (e.g., create

    randomalias@customerdomain.com as an alias for john.doe@customerdomain.com).

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request



Please sign in to leave a comment.

Articles in this section

See more