Recently, I wrote an end-to-end guide on how one can build a privacy-centric Salesforce ecosystem. Please ensure you go through the blog post, as it will serve as a base for this one.
I put some patterns together that I worked on throughout my journey and some extras that you might find nifty. Let’s dive right in.
Data Masking
Field-Level Security:
This is always the first place to get started with. Restrict access to specific fields based on user profiles.
Example: Set field-level security for the “Social Security Number” field on the Contact object to be visible only to users with the “HR Manager” profile.
Salesforce Classic/Shield Encryption:
Encrypt data at rest and in transit. Supports probabilistic and deterministic encryption.
Example: Enable Shield Platform Encryption for the “Credit Card Number” field on the Order object, using deterministic encryption to allow for filtering and sorting.
Custom Masking with Apex:
Implement custom masking logic using Apex triggers/flows or formulas.
public class ContactTriggerHandler {
public static void maskSensitiveData(List<Contact> contacts) {
for (Contact c : contacts) {
if (c.SSN__c != null) {
c.SSN__c = 'XXX-XX-' + c.SSN__c.right(4);
}
}
}
}
Dynamic Data Masking:
Use formula fields or Apex to dynamically mask data based on user/profile/permission set/custom permission context.
public class DynamicDataMasking {
public static String maskCreditCard(String creditCardNumber) {
if (FeatureManagement.checkPermission('Can_Access_Sensitive_Data')) { // check custom permission
return creditCardNumber;
} else {
return 'XXXX-XXXX-XXXX-' + creditCardNumber.right(4);
}
}
}
Data Mask (SBX):
Example: Use Data Mask to replace all email addresses in the sandbox with fake data while preserving the format: “user123@example.com” becomes “sandbox123@example.com“.
Design Patterns for Data Privacy
Privacy by Design:
Incorporate privacy considerations from the outset of any project.
Example: When creating a new custom object, include fields for consent tracking and implement field-level security from the start.
Data Minimization Pattern:
Collect and retain only necessary data. Meaning, store only the information needed in SF, implement field history tracking selectively, etc.
Consent Management Pattern:
Leverage Salesforce’s Individual object for consent tracking. Implement custom consent fields if needed.
Right to be Forgotten Pattern:
Implement automated data deletion processes. Use Salesforce’s Data Retention Policies and custom Apex jobs for complex scenarios.
Data Portability Pattern:
Implement a system for easy data export. Use Salesforce’s Data Export service or custom API endpoints.
Least Privilege Access Pattern:
Implement fine-grained sharing rules and permission sets to ensure users only access necessary data.
Example: Create a permission set “Read-Only Sales” that grants read access to Accounts and Opportunities, but no create or edit permissions.
Audit Trail Pattern:
Leverage Salesforce Shield Event Monitoring for comprehensive audit trails.
Example: Use Shield Event Monitoring to track all data exports, creating a custom report to review export activities weekly.
Other Patterns/Techniques
Pseudonymization with Custom Encryption:
Implement custom encryption for specific use cases. Use Salesforce’s cryptographic functions.
public class CustomEncryption {
public static String encrypt(String plainText, String key) {
Blob data = Blob.valueOf(plainText);
Blob encryptedData = Crypto.encryptWithManagedIV('AES256', Blob.valueOf(key), data);
return EncodingUtil.base64Encode(encryptedData);
}
}
Tokenization:
Replace sensitive data with non-sensitive tokens. Implement using custom Apex or third-party solutions.
public class Tokenizer {
private static Map<String, String> tokenMap = new Map<String, String>();
public static String tokenize(String sensitiveData) {
String token = EncodingUtil.convertToHex(Crypto.generateAesKey(128));
tokenMap.put(token, sensitiveData);
return token;
}
}
Data Obfuscation:
Modify data to preserve privacy while maintaining usability for testing or analytics. Even use apex for processing obfuscating data in bulk (scheduled mostly).
public class DataObfuscator {
public static void obfuscateEmails() {
List<Contact> contacts = [SELECT Id, Email FROM Contact];
for (Contact c : contacts) {
c.Email = c.Email.substringBefore('@') + '@example.com';
}
update contacts;
}
}
Differential Privacy:
Implement noise addition techniques for aggregate data to prevent individual identification.
public class DifferentialPrivacy {
public static Decimal addNoise(Decimal value, Decimal sensitivity, Decimal epsilon) {
Decimal scale = sensitivity / epsilon;
Decimal noise = scale * Math.log(Math.random() / (1 - Math.random()));
return value + noise;
}
}
Architectural Considerations
- Implement a Microservices architecture for modular privacy controls
- Use Event-driven architecture for real-time consent management
- Adopt an API-first approach for seamless integration of privacy features
- Data Fabric architecture for unified data governance across systems
- Master Data Management (MDM) strategy
Note on Implementation:
While the examples in this blog post primarily use Apex for clarity and specificity, it’s important to emphasize that these privacy patterns and principles are not limited to code-based solutions. They can be effectively implemented and extended using various Salesforce tools such as Flows, Formula fields, or other declarative features. The key is to understand the underlying concepts and adapt them to your organization’s specific needs and technical capabilities. Whether you’re a developer, admin, or architect, these patterns provide a solid foundation for building privacy-centric solutions across the Salesforce ecosystem.
The design patterns and techniques outlined above provide a comprehensive toolkit for enhancing data privacy in Salesforce ecosystems. By strategically implementing these patterns, organizations can not only meet regulatory requirements but also build trust with customers, reduce risk, and create a foundation for responsible data management practices.