Salesforce Experience Cloud has an interesting issue with the PII (Personally Identifiable Information) compliance.
In short, if you use a standard Case record detail page and use the Subject field as a free-text field, you might violate GDPR and CCPA compliance.
I’ve already posted about it on LinkedIn some time ago, but this time I’d like to dive a bit deeper and explain the reasoning behind the most common solution.
TL;DR: Do use the Case Subject field as a free-text and ensure none of the PII data ends up there.
PII data in the Experience Cloud URL
If you worked with Experience Cloud and have used standard object pages, then you already know that you can access record detail pages by their IDs.
You might’ve already noticed that when you access the page, it redirects to a different page and updates the URL to include an extra path, which is normally the autonumber field.
It’s because the standard record detail pages use the URL structure :recordId/:recordName.
Surprisingly, there is one standard object with unexpected behavior.
I’m talking about the Case object.
Someone might think that it would use the case number as the :recordName variable.
Unlike other objects, Cases use the standard Subject field instead.
I assume the reason is improved user experience, since such URLs become human-readable.
But there is a caveat.
Since Subject is a free-text field, if you allow customers to enter the value themselves, they might put their PII data there.
It poses a risk of data breaches because if the subject contains sensitive data, for example, submitted by the customer, it ends up in the URL.
Therefore, it can expose sensitive information through browser history, logs, and referrals, potentially violating privacy regulations like GDPR and CCPA.
If your company must comply with such regulations, you must ensure that none of the PII appears in the URLs.
How to ensure PII doesn’t end up in the URL
Unfortunately, it’s not possible to change the URL structure for the standard record pages.
So, you cannot remove the last path or use a different field as a source.
I’ve brainstormed and investigated the alternative solutions.
Another sad thing I noticed is that this issue was already reported to Salesforce a few years ago, but it hasn’t been resolved. Probably, because it has been prioritized.
Of course, I would’ve preferred if Salesforce had given us an option to change the URL configuration, but it is what it is.
Initially, I’ve identified three possible alternatives to solve the challenge.
- One option could be using another field for the actual Subject to ensure none of the PII data gets there.
- Another would be to use a custom page.
- Also, network traffic analysis tools can be used to modify URLs and remove the last path before sending them to third-party services.
Let’s start with the latter because I don't believe it’s viable.
Leveraging the network traffic analysis tools isn’t the most reliable solution and adds another layer of unnecessary complexity.
The other two options are a bit more interesting.
Using a custom page might become a tempting option because it gives you full control over the page URL structure.
Also, switching the fields requires more effort, especially if you reference the Subject field in many places and have a lot of existing data.
For example, how to ensure the old links remain valid when you transition to a new field?
Nevertheless, after some discussion, I believe the best option is to store free-text data in a field other than Subject and to control the values of Subject to avoid accidentally including PII there.
I’ve also got a response from a Salesforce representative confirming that it’s the most common approach their customers use to overcome this challenge.
Sure, it might require extra effort to implement, but there are reasons to stick with the standard pages:
- You cannot have path variables in custom pages. Meaning the only option is query parameters, making URLs less human-readable.
- Using standard pages requires less maintenance and ensures you receive the latest platform updates.
- The core data access rules configured in the core Salesforce org are respected in the Experience Cloud site.
Conclusion
GDPR compliance is a crucial topic, especially in regulated industries such as banking, financial services, and healthcare.
By all means, to remain compliant, your Salesforce org should not expose any personally identifiable information to the URLs, and if you use standard Case record pages in the Experience Cloud website, double-check that they do not allow the entry of PII data into the Subject field.
If you automatically populate that field or allow end customers to enter the data as free text, it has to be addressed.
The suggested solution is to store that data in another field and keep the Subject values static.
I can only assume that Subject has never been intended to be the free-text field and instead represents a case category, similar to what Salesforce uses.
Tip: You can display the other field instead of the standard Subject in the UI and even have “Subject” as its label.
It’s the approach most companies use, and it lets you benefit from low maintenance, better security, and future platform updates.
Nikita Verkhoshintcev
Senior Salesforce Technical Architect & Developer
I'm a senior Salesforce technical architect and developer, specializing in Experience Cloud, managed packages, and custom implementations with AWS and Heroku. I have extensive front-end engineering experience and have worked as an independent contractor since 2016. My goal is to build highly interactive, efficient, and reliable systems within the Salesforce platform. Typically, companies contact me when a complex implementation is required. I'm always open to collaboration, so please don't hesitate to reach out!
