User getting "Invalid attempt. Encrypted data could not be saved" when entering data in an encrypted field

[peterscaramuzzo]

We have a portal form that has a special multi-line encrypted box to put information that my company requires to be encrypted. However non-itil users  are getting "Invalid attempt. Encrypted data could not be saved". We are thinking maybe for these non-itil users we could grant them a role that allows them to write encrypted data while still not letting them read encrypted data. I was looking at doing this from a role perspective but it doesn't seem to have that level of detail. Is something like that possible? Or would there be a much better approach? I was looking at maybe granting this access for the specific form through the layout as this seemed to be suggested in some articles but couldn't seem to make any headway. I am sure this is a somewhat common problem so hoping someone can offer some advice and perspective.

[Allen Andreas · Accepted solution]

Hi,

How do you have this setup today?

I know for direct writing to an encrypted field they'd need to have the role associated with that fields encrypted context (hence the error you're seeing), but if you are using perhaps a record producer and they are writing to a specific multi-line text field that you have mapped to the encrypted field, that may work and not need the context?

Back to what you were talking about though...to be able to write to a field, means they'd need to be able to read it. So you'd have to juggle people writing to a field, which then gets transferred to another field perhaps where they can't read it. I've done something similar for PII logging, where one field we allowed PII in it, but then an audit log was created which was also encrypted on the form outside their view for ease of use that captured who made the edit, when they made the edit, and what the edit was.

Please mark reply as Helpful/Correct, if applicable. Thanks!

[John Sheehan1]

Thank you sir! Very helpful and amazing the knowledge and experience you find out here.

[Linda_G]

Thank you for this, it was extremely helpful!

[peterscaramuzzo]

It is a record producer. I was thinking making the field a non-encrypted field and then in the record producer script, transfer the information to the encrypted field. However the thinking is that since this is a non-itil user opening the portal page it wouldn't be allowed. It was the next thing to try but was looking for a simpler solution as this could help us in other situations as well. I can look into this next.