5 Considerations for Localized, Regulated Data in Salesforce

International privacy and personal data laws are now in effect in more than 120 countries worldwide. Examples include:

• GDPR (EU and UK, effective 2018)
• LGPD (Brazil, effective 2020)
• PIPL (China, effective 2021)

As governments enact legislation to protect citizens’ data, changing regulations create complex challenges for architects, particularly for those taking advantage of cloud technology. In response to these challenges, architects must design data patterns with sufficient flex to adapt to diverse local requirements.

Use the five considerations described in this post to help shape a design for localized, regulated data in your Salesforce architecture.

1. Design based on your organization’s interpretation of the law

Your organization’s legal department must define where and how each law is relevant. Whilst there are publicly available articles from agencies or data privacy consultancies that summarize key principles, the laws themselves are often nuanced and subjective at the detail level. How your organization applies them is instructive to your architecture. Some general factors that influence design include:

• Definitions of regulated data. What is classified as personal data, and what are the differences in a B2B or B2C context?
• Sector-specific regulated data. Some regulations place a higher importance on data that relates to infrastructure projects, or that tangentially connects to a consumer, like telematics data from a connected car.
• Thresholds of regulated data. Some laws may only apply where volumes of data exceed a certain amount.
• The investment cost versus future business forecast in the local jurisdiction. Is the investment in local data architecture justified given the volume of business?
• Residency and processing requirements. Does the law apply only to where data resides, or does it include processing restrictions such as viewing and updating from outside of the locality?

You also need to consider which countries your customers and users reside in, and how these map to one another. In some cases, this could be a simple 1:1 mapping, in others it may incorporate a non-domiciled offshore capability that could support customers and need access to their data.

To support the efforts of your legal department, categorize data so it is clear which entities, attributes, and use cases require regulation. Sometimes a legal department’s definitions can be too abstract to practically implement on a system, so working with them on the next level of detail will help you draft an appropriate design.

Your legal department may set categories specific to the local jurisdiction in which they apply.

As an architect, you’ll need to take these categories to a level of logical definition to support your technical design.

To assist your legal teams as they refine their interpretations, ensure your data is consistently segmented and classified at the database level. Ensure there is a globally consistent method for identifying “local” records in the database, like an international classification field on every object containing an ISO value. It is also possible to classify fields at a metadata level through data classification; when doing so, use the same terminology that you defined with your legal teams to enable traceability back to your legal policies.

2. Document Salesforce data flows within the enterprise

Salesforce is not the only host of customer data in your organization’s enterprise IT landscape. It may be upstream and downstream of other systems and data flows. Ensure your enterprise landscape schematics are up to date, including at the physical level. Document where regulated data is sent and received; within the documentation include:

• Logical entities and systems of record
• Physical entity and attributes, including host countries
• Processing activity on the data within the application or a connected interface
• For Salesforce, catalog outbound interfaces and APIs, automations such as Flow and Apex, and de-duplication rules.
• External and primary keys

Collaborate with colleagues managing other systems to consider the impact of an attribute being redacted or restricted in its use. As architects we should communicate clearly on the impact to business functions should date entities need re-architecting. To help with this, create data flow diagrams, indicating entities, master data sources, host locations, and processing and integration services as well as attributes stored at rest and in transit.

As you complete this exercise, catalog the sources, targets, and uses of each data entity throughout its lifecycle.

3. Weigh multi-org or point of presence alternatives

If you have a single Salesforce org, or multiple orgs outside of the regulated location, you may consider introducing a local Salesforce org capable of hosting and processing data. If Salesforce does not currently have a presence locally, talk with your Account Exec about the roadmap to Hyperforce in the region.

Introducing a new org to your architecture entails other considerations beyond data residency, and will impact the existing operating model of your Salesforce implementation. Consider:

• The strategic model to host the new org. Will the org replicate processes and objects from one or more source orgs and only contain local data? Or will the new org signal a diversification of the model to allow for regional design and customization?
• The impact on regional and global reporting. Consider, for example, reporting sales figures. Rollups or abstractions of data may be replicable globally, but localized reporting from the source org may be needed where customer-level details are required.
• The support requirements of running and maintaining an additional Salesforce org. How will you control change, and monitor and optimize the services for a new org in your landscape?

In some cases, the operating model change necessary to accommodate a new org is too great. Instead you may consider a local point of presence where hosting and processing services exist for regulated attributes. A local point of presence may be hosted on a local cloud provider, such as Alibaba Cloud, or through a global public cloud provider with local presence, such as Amazon Web Services.

When designing a local point of presence, consider these core capabilities:

• Data hosting. Do you need the ability to store regulated or non-regulated attributes in structured tables?
• Data hashing / redaction services. If local regulation dictates personal data must be redacted before it leaves the country (for example, to be synchronized with Salesforce), then the clear text value must be transformed locally. This may be done on the client side or on the server side on the point of presence. A cross-border regulation may forbid hashing outside of the country (for example, server-side on your non-local Salesforce instance, as clear text data will be processed).
• Inbound APIs and composite services. If regulated attributes are collected (like a lead at an event), then this data must be posted to the local point of presence via an API. As it is possible both regulated and non-regulated data is collected, a composite service that can create data within the point of presence, and simultaneously within Salesforce, will allow only regulated values to be stored and processed from the point of presence. For minimal divergence, the sObject in Salesforce should remain the owner of the primary key, and the definer of the object metadata.
• Two-way replication services. A record in Salesforce might only contain a small number of regulated values. The ability to synchronize record structure from Salesforce to the local point of presence maintains data integrity, and enables frictionless operation for users within Salesforce who are (under the hood) maintaining data in two sources.
• Streaming capability, for example through an OData service. For certain regulations, data may be replicated from a local host to Salesforce. OData provides a more lightweight service than two-way replication where data can be surfaced as an external object in Salesforce for use in features like global search.
• Headless data processing services. Where laws dictate processing must also stay within the locality, it may be necessary to provide services on the data that can be invoked from Salesforce, similar to the Salesforce Functions pattern. For example, you may need a duplicate check service locally, as only within the local point of presence can clear text values be compared for processing.
• Client-side components. A Lightning Web Component, for example, can be used to present locally stored clear text values to the local end user. Use the Lightning Design System to replicate the look and feel of standard Lightning components accessing sObject data from the Salesforce server.
• Supporting services. Make sure you consider administrative changes like redacting a new field, secure backup of data and metadata, error handling processes and synchronization logs, and data lifecycle procedures like archiving and deletion.

• In the multi-org or point of presence architectures, consider your local support capability. A regulation may prohibit anybody other than a local administrator to perform configuration on the platform where local data is visible in clear text form.

4. Spend time on the user experience

Particularly in a local point of presence architecture, the impact to the user experience (UX) should be carefully considered. Where a consistent global user experience is implemented, attention should be given to regions directly impacted by localized data, as well as those in the rest of the world that are not. Salesforce packages its platform services and user features as a monolith; by effectively sharding part of the database, there will be a UX impact.

To maintain a consistent global user experience, it may be necessary to include dynamic components that are shown based on a user’s locale. Consider:

• Page layouts. Regulated fields may need to be presented in a separate, access-controlled component, for example a Lightning Web Component streaming clear text values from a point of presence. Introducing a component may require conditional changes to the record detail or existing Lightning record layout. The record detail change could affect all users of the object.
• Reports. Where values are redacted, they will appear hashed or redacted on reports. Summary reports and dashboard components may still function, but an external object may be required to present clear text values on a tabular report.
• List views. Filters, inline editing, and search capabilities within list views on regulated values may need to be performed on point of presence data as opposed to the hashed data at rest on the sObject.
• Related lists. Where redacted values must be displayed on a related list, a composite component may be required to display point of presence hosted and Salesforce hosted data on the same row of a related record.
• Global search. Common search terms like “Last Name” or “Email Address” will not function if these attributes are hashed localized data. External objects accessible only to local users replicate this functionality.
• Action buttons (like New, Edit, or custom actions). It may be necessary to intercept record creation or update processes for regulated attributes so the clear text value is never stored or processed server side.

As an example, consider the following page layout with dynamically shown components based on regulated data access.

Where UX alterations are too pervasive, it may be necessary to bifurcate the user experience between fully native Salesforce users and those that use Salesforce with a local data point of presence. Be intentional about this decision; as well as incurring a training and maintenance cost, the evolving nature of data regulations may increase the number of regions that require localization support. You risk supporting a number of unique user experiences and reducing the agility of the platform.

5. Set clear principles for developers and designers

When considering the variables in the four points covered thus far, you’ll be establishing organizational, technical, and UX principles that will be instructive to low-level designs and user stories. Unlike a business-driven feature, the specifics of requirements will be dictated by your compliance policies and design decisions, rather than a business-specified requirement. Example principles include:

• User experience deviation should be kept to an absolute minimum; this is particularly relevant for a global org with consistent processes, or a replicated org design.
• Regulated attributes must not be stored at rest, cached, or processed server side; consider the standard “New” button. Even if on record create you immediately synchronize with your localized data platform, this may still break regulations by temporarily storing clear text values on a non-local platform.
• User location must be derived from the login IP address; this avoids scenarios where local sales reps travel internationally and access regulated data as clear text from a foreign jurisdiction.
• Design for extension, not a local point solution; the patterns delivered should be extendable for additional countries or regions as data regulations evolve.

Test-Driven Development is a good idea when implementing localized data architectures. It increases the precision of test cases prior to the development cycle, giving greater understanding of how the requirement is realized with respect to the principles you establish for designers and developers.

What should I do next? What should I do first?

If your organization is preparing to deal with a new data regulation, you can accelerate the analysis through housekeeping on your Salesforce org. Make sure your data and attributes are well defined, and remove any technical debt or unused personal attributes. Use tools like Field Trip to gain a deep understanding of the volumes and completeness of attributes in the org.

It’s also useful to gain an understanding of the wider enterprise architecture capability within the target local landscape. If the IT operation is already mature, with reusable localized data services well established, then building your own solution is likely viable.

For less mature local IT operations, consider the ISV ecosystem and partners such as Odaseva or InCountry. When choosing a partner consider:

• International coverage and extensibility options across multiple localities
• Available components to view and process the data from Salesforce
• Supporting services, such as APIs and on-platform functions
• Local hosting models; for example “black box” to customer, or on customer designated hosting platforms

By deeply understanding the size and shape of your data, plus available services in your enterprise architecture, you can establish an architectural hypothesis for testing against your organization’s interpretation of data regulations.