You’re a Salesforce Service Cloud customer with your agents leveraging Salesforce to service each of your available channels. You’ve trained your agents never to put credit card or social security numbers directly into your Salesforce and you’re feeling pretty good about your internal PII policies to avoid being fined or exposing sensitive personal information about your customers. The problem is how do you train your customers? You can setup encrypted fields or policies as much as possible for your agents, but your customers are still going to do something like this:
Dear Customer Service,
I just noticed I was billed another month for my subscription to your product today. I had meant to cancel that and would like a credit for this last month. My account number is 123456 and please be sure to credit card number 4147-4001-5555-5555. Please let me know if you have any questions and thank you!
Thanks Joe. Thanks for blasting in your credit card via email so that it’s now sitting fully exposed inside your Salesforce. The reality is Joe isn’t alone. A lot of customers simply don’t think before shooting over a credit card or social security number via your Community, Email or Chat. To make matters worse, you are responsible for this behavior – including potential fines. That PII is now sitting exposed and unprotected in your Salesforce across multiple objects. You can try to train your agents to edit or delete the data, but it can potentially stored on objects they don’t have access to adjust – like Email or Chat Transcripts. So, how do you protect yourself from having exposed PII in your Service Cloud?
This is why we came up with GearsDataMask. It’s a simple solution that monitors all of the core Service Cloud objects for various patterns. If it finds those patterns – like a social security number – it immediately obfuscates the data so the number is never stored in your Salesforce, turning that email above into:
Dear Customer Service,
I just noticed I was billed another month for my subscription to your product today. I had meant to cancel that and would like a credit for this last month. My account number is 123456 and please be sure to credit card number xxxx-xxxx-xxxx-xxxx. Please let me know if you have any questions and thank you!
Now you don’t have to worry about Joe blasting over his credit card number and you can handle this credit request per your normal process and procedures. Out of the box, we have pre-loaded patterns for all major US credit cards and social security numbers (read our user guide for the full list). Administrators can easily extend this to look for additional patterns – for instance, maybe your company has their own gift cards that have a unique pattern – or you have a large number of clients on a specific niche credit card. All you need to do is add that pattern to the administration tab and we will monitor for those patterns as well. We will run these checks on all of the core Service Cloud objects including:
- Cases – Subject & Description fields
- Emails – All Email-to-Case inbounds create a Case and an Email record.
- Chat Transcripts – All Live Agent Chats automatically create a Transcript record. On a side note, Salesforce has a feature to mask patterns similar to this in the chat window so your agents won’t see the number as the customer enters it. However, that data is still stored in the Transcript even though it was masked in the window. GearsDataMask will take care of the data side, ensuring no sensitive information is stored.
- Feed – Case Feed leverages the Chatter Feed object so it’s possible for this data to be sent to the Feed as well.
- Case Comments – Community users are not immune to this bad behavior.
With GearsDataMask, you can protect your Service Cloud from Emails, Chats, and Community posts that come in with PII / PID as well as from your own agents that might improperly log PII directly in a Case. As part of your annual subscription, we will continue to update the patterns as credit card companies adjust their algorithms. Contact us to learn more about GearsDataMask and how you can protect your Service Cloud from inadvertent PII.