1

I have enabled shield encryption for contact name in dev org.

image

when I try to create a new record on contact the record is still visible to the users and is not in encrypted format

enter image description here

I'm missing out something can anyone suggest

3

I'm not sure what you mean by encrypted format. If you expect the data to be masked (meaning being replaced by something like "*****"), this behavior is going away.

As far as the end user is concerned the data will behave the same whether it is encrypted at rest or not.

4

There is no easy answer to your question, starting a new one given that it's much larger that what can fit in a comment.

We took this decision for multiple reasons

1/ The goal of platform encryption is to protect the data at rest and focuses on attacks such as a hacker stealing a hard drive or an employee having its credentials compromised. When using platform encryption neither our DBAs or our site reliability team have a way to access the encryption key or the data itself other than in ciphertext.

2/ We have multiple ways of controlling access to a logged in user, such as CRUD, FLS or sharing. We have transaction security and platform event monitoring that allow you to audit/act upon an end user attempting something suspicious

3/ Given the complexity of our platform, it has been quite challenging to implement masking reliably and it sometimes broke features that rely on data synchronization, salesforce for outlook for instance used to only work with VED users

4/ Based on our instrumentation, we realized that the ratio between when we were decrypting vs masking the data was more that 1000 times more. These numbers matched the feedback we had from our customers that they did generally not rely on masking and were giving VED to every user.

5/ Masking and encrypting at rest are kind of orthogonal problems, you might want to mask social security numbers regardless whether they're encrypted in the database. There are thoughts internally about having masking as a platform feature but that is again a hard problem to solve. We heard of some customers implementing masking themselves in the presentation layer

All these combined lead us to sunset masking to make us more effective at adding more capabilities and compatibilies to platform encryption. Support for custom formula fields, flow, chatter, wave would have been way much harder and longer to implement if we had to care about masking and this is true for the upcoming features that will be announced at Dreamforce.

All that being said, if masking is truly a must have for your use case, it is still available with classic encryption.

2

See the Spring 17 Release Notes. In order to reduce confusion between masked and encrypted data, Salesforce has effectively deprecated the standard use of a mask over data fields. Fields encrypted with Shield encryption should be hidden from users via means used across all fields, such as field level security.

If you would like the masking behavior (for example, to allow users to see that a field has a value, even if you do not want them to see the value itself), fields encrypted with Shield support use in formulas, so you can make a simple formula which shows the end user either a checkbox or "mask" string indicating the underlying field is populated.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.