Does anyone know how to use SOQL to verify if a profile has permission to View Encrypted Data? The field is not on the Profile object. Some fields such as View Data Categories do reside on the Profile object, but not View Encrypted Data. Thanks!

  • Why do you need to determine this? As sfdcfox pointed out, the system will generally take care of those permissions automatically. If we know your use case we might be able to provide better answers. – Mike Chale Sep 14 '13 at 16:11
SELECT p.Id, p.Assignee.Name,p.Assignee.IsActive, p.Assignee.Profile.Name, p.PermissionSet.Label
FROM PermissionSetAssignment p
WHERE p.PermissionSet.PermissionsViewEncryptedData = true


There's no way access this encrypted state value in Visualforce/Apex Code. It is also unnecessary to know if it is encrypted as long as you remember to use apex:outputField, which automatically honors the View Encrypted Data permission. If the user doesn't have permission, they will only see the encrypted text, and if they do, they'll see the normal text.

It's important to note that the decrypted value always appears in Apex Code's SOQL results. However, if you try to debug that value, it will appear encrypted to avoid accidentally exposing the value. You can prove that Apex Code sees the decrypted value by copying the value to string and displaying that string on the page, or by using apex:outputText, which will show the non-encrypted data.


Simply query the field normally. If the field is encrypted, they will see only the masked value. You could also describe their profile and permission sets, and determine if they have permission, although this is largely unnecessary as a practical matter.

  • Which field would it be under when describing the profile/permission sets? Is there any list of all the profile fields available from a describe? – Mike Chale Sep 14 '13 at 16:12
  • It's not a standard describe; you have to actually use the metadata API. It's documented in the Metadata API Developer's Guide. – sfdcfox Sep 14 '13 at 18:02
  • It's odd that out of the huge number of permissions that can be checked programatically via the PermissionSet table that this isn't one of them. – ca_peterson Sep 14 '13 at 20:41
  • 1
    I'm not surprised, actually. salesforce.com does many things well, but including something as simple as this often escapes them until many releases down the road. – sfdcfox Sep 14 '13 at 22:53

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.