Hi @JohnMac,
I second your thought on this. There needs to be a easier way to ensure a string is encrypted or substring is encrypted when a system exception occurs.
Our workaround
- We use try-catch on workflow level and catch such unknown exception messages. A link to the approach. The catch blocks consumes such system generated error messages and does not allow it to publish this to logs.
- In the catch block we use regex to check if the pattern matches with a PII,
- If it does, we perform string manipulation (similar to this thread How to mask credit card Number?) and / or encrypt string activity to avoid logging this information in our database/splunk index/log files.
The caveat is that, if you are using invoke worfklow, you will have to fetch the underlying error messages from the invoked workflow to the parent workflow, but this is easily done by using out_arguments.