Compliant | Salesforce Architects

Read about our update schedules here.

Introduction

A system architected to be compliant follows legal and ethical guidelines in ways that can be measured and audited. Systems demonstrate compliant behavior by ensuring data can only be accessed by intended parties for intended purposes, by adhering to legal regulations, and by ensuring equitable access for all authorized users.

To prevent and detect compliance violations, it’s important to be proactive. Taking a reactive stance to regulations and standards can create trust issues with your customers — especially if changes are only the result of customer requests or complaints. Such complaints can damage your organization’s brand and reputation, and can lead to revenue losses.

You can build more compliance in your Salesforce solutions by focusing on three key habits: legal adherence, ethical standards, and accessibility.

Legal Adherence

Legal adherence entails following the mandates set out by regional laws and industry regulations. Once your organization’s legal team (or a third-party auditor) has determined the specific compliance requirements for your organization, your responsibility as an architect is to familiarize yourself with these requirements and proactively flag any potential compliance issues as early as possible during design to reduce the risk of fines and lawsuits.

You can improve legal adherence in your Salesforce solutions through data privacy and localization.

Data Privacy

Data privacy deals with how your solution collects, stores, and processes personally identifiable information (PII), the regulations that apply to those processes, and how individuals can control who and what has access to their personal data. Adhering to data privacy regulations may require you to make updates to your sharing and visibility model, update your metadata configurations to restrict access, add encryption at the field level, create automations to export or delete a customer’s data upon request, and create policies defining how data can be used in automations and AI.

Non-compliance with data privacy regulations can lead to large fines and lawsuits. Moreover, exposing stakeholder data due to poor controls or a security breach can result in lost revenue and lost customer trust.

Consider the following as you work to ensure adherence to data privacy requirements:

Consult regulatory experts. Work with your legal team or a third-party auditor to evaluate the industry-specific compliance regulations that your business must adhere to, such as the Health Insurance Portability and Accountability Act(HIPAA) for healthcare companies.
Classify your data. Data classification helps project teams understand when the various data elements in your org may or may not be used. It also gives your business the ability to report on data management policy compliance. Classify the data in your org by specifying applicable regulations at the field level to capture who the owner is, the sensitivity level, and whether or not the field is currently in use.

During the classification process, it’s important to think about how all of the fields in your data model might be used and not just the ones that seem like they might be sensitive at first glance. In some cases, fields that seem inconsequential can become sensitive if used within the wrong context. For example, postal codes in the United States are sometimes used to predict the race of individuals who live in them. Names can be used to predict gender, country of origin, race, religion, and even age, as popular names tend to change from generation to generation. Include classifications of all fields and a clear description of how any associated AI functionality will use them in your documentation.

Use artificial intelligence (AI) tools such as Einstein Data Detect to identify sensitive data (for example, age, race, and gender) within your org. If fields are classified as sensitive or if you know which fields are sensitive, tools like Einstein Content Selection will also identify fields that are highly correlated and therefore can be proxies for those sensitive fields.

Establish best practices for data governance. Ensure that all relevant documentation is complete, up-to-date, and centrally stored so it’s easily available for all stakeholders. This will add a layer of protection for your organization against legal liability while also maintaining trust with your customers and partners. For example, a data dictionary documents the object and field-level definitions and classifications for all data elements that will be stored in your system, design documents contain details about any automations you’ve created to comply with regulations, and a security matrix outlines what data users have access to.

The list of patterns and anti-patterns below shows what proper (and poor) data privacy management looks like within a Salesforce solution. You can use these to validate your designs before you build, or identify areas of your system that need to be refactored.

To learn more about Salesforce tools for data privacy, see Tools Relevant to Compliant.

Localization

Localization is about adapting a product to a particular language, culture, and desired local look and feel as well as adapting to region-specific regulations, including data residency laws. Regulations vary from country to country, and sometimes even from municipality to municipality. As a result, your systems may need to comply with more than one set of regulations, depending on where your customers are located and how your business goes to market with its products and services.

In addition to variations in data privacy laws, many countries are also enacting data residency laws. At a minimum, data residency laws require all data related to a country’s citizens to be physically stored within that country’s borders. Some laws go further, requiring local storage of all data that country’s citizens can potentially access (including data about products and services). Taking it one step further, some countries and regions have regulations requiring citizen data to be maintained only by other citizens.

Non-compliance could lead to large fines and lawsuits. For example, the EU's data protection authorities can impose fines up to €20 million or 4% of global revenue, whichever is higher. In the U.S., the California attorney general's office can seek significant penalties for both intentional and unintentional violations.

Consider the following to better manage localization and data residency requirements:

Consult regulatory experts. Work with your legal team or a third-party auditor to evaluate laws in the regions where your business operates to determine which ones are applicable. Potential examples include the General Data Protection Regulation (GDPR) in the EU, or the California Consumer Privacy Act (CCPA) in the state of California.
Store data locally. Ensure that data relevant to a specific region stays in its own, separate org. Use Hyperforce, Salesforce’s public cloud substrate to host your org in a specific region.
Avoid data replication. Local data storage means that data is stored at rest in the country; of course, compliance issues can arise when data is transferred out of the country through standard interfaces. For example, creating and maintaining records locally but replicating them to a data warehouse in another country for reporting will violate data residency laws. If you work for a global business with cross-regional reporting requirements, first aggregate your data within the country where it’s stored, remove all information that could potentially identify the citizens associated with it, and then replicate only the aggregate information. This approach may require you to communicate reporting limitations to your stakeholders so that they know that while more granular data will be available at a country or regional level, only summary data will be available globally.

The list of patterns and anti-patterns below shows what proper (and poor) localization and data residency processes look like within a Salesforce solution. You can use these to validate your designs before you build, or identify areas that need to be refactored.

To learn more about Salesforce tools for localization, see Tools Relevant to Compliant.

Legal Adherence Patterns and Anti-Patterns

The following table shows a selection of patterns to look for (or build) in your org and anti-patterns to avoid or target for remediation.

✨ Discover more patterns for legal adherence in the Pattern & Anti-Pattern Explorer.

	Patterns	Anti-Patterns
Data Privacy	In your documentation: - You have an up-to-date data dictionary containing field level names, descriptions, and classifications - You have an up-to-date security matrix that identifies which users have access to what data - You have up-to-date design documentation, including standards and diagrams for any automations created to address regulatory requirements	In your documentation: - A data dictionary does not exist or has not been kept up-to-date - Sharing and visibility documentation does not exist or has not been kept up-to-date - Design standards, diagrams, and documentation for automations that address regulatory requirements does not exist or has not been kept up-to-date
Data Privacy	In your org: - All objects and fields that contain sensitive information or are subject to data privacy regulations have Compliance Categorization, Data Owner, Data Sensitivity Level, and Field Usage configured	In your org: - Objects and fields that contain sensitive information or are subject to data privacy regulations are missing configuration for Compliance Categorization, Data Owner, Data Sensitivity Level, or Field Usage
Localization	In your documentation: - You have an org strategy that outlines where data will be stored and maintained to comply with all applicable data residency requirements - You have an integration strategy that outlines acceptable scenarios and processes for replicating data across borders - You have an analytics strategy that outlines the level of granularity reports and dashboards can contain at regional, national, and global levels	In your documentation: - You do not have an org strategy or your org strategy does not address data localization and residency requirements - You do not have an integration strategy or your integration strategy does not address data localization and residency requirements - You do not have an analytics strategy or your analytics strategy does not address data localization and residency requirements

Ethical Standards

In business contexts, ethical standards are the guidelines for how companies and individuals conduct themselves from a values-based or moral standpoint. At Salesforce, our core values guide everything we do as a company and as employees. We also have an ethical use policy team that helps to ensure customers are using our software in an ethical way. Our Acceptable Use Policy (AUP) is an extension of our core values, and helps guide our decision-making if questions around usage arise.

Your organization may have an additional set of policies that extend beyond simply complying with local regulations. These types of policies can come in many different forms, ranging from adhering to other regions’ regulations, declining to do business with certain organizations or markets, or monitoring employee-customer interactions to identify and eliminate discrimination or biased behaviors. In order to support these policies, you may need update your design standards or system configuration as you would for legal adherence.

You can build better adherence to ethical standards in your Salesforce solutions by ensuring alignment with company policies and evaluating how you’re using artificial intelligence.

Company Policies

Company policies are guidelines that define how various aspects of the business (including people, processes, and technology) should operate. Customers prefer to do business with organizations they trust. Most company policies are designed to reflect this principle. Customer trust will erode quickly if your systems create user experiences that don’t align with your stated policies.

Effective policies flow naturally from a culture of ethics, in which every employee is educated about their responsibility for ethical use from engineering, design, data science, marketing, and sales. In such a culture, employees see clear incentive structures to reward ethical behavior along with clear, consistent consequences for unethical behavior.

Consider the following to ensure your organization’s policies are reflected in your designs:

Be aware of unintended consequences. As an architect, you have a responsibility to understand how your solutions will be used and their potential impacts. Don’t fall into the trap of only considering or testing for happy paths. Apply the expertise you’d use in testing edge cases and evaluating tradeoffs to think through the ethical impacts of your solutions. Think about everyone that will be affected by the product, especially those who are underrepresented, marginalized, or vulnerable. Evaluate the multitude of ways someone, or something, might interact with your solution and create unintended consequences. Use the Build With Intention Toolkit to design with inclusion in mind.
Embed ethics into your company's acceptable use policy. Work with your legal team or a third-party to include ethics in your acceptable use policy to ensure the use of your solutions aligns with your company values. In your documentation, include information about which of your organization’s values and policies are supported by your solutions, whether developed with low-code or pro-code tools. Publish your acceptable use policy to show your commitment to building trust with your employees and customers.
Use inclusive language. Understand the different ways people experience your solution and refine the language in your user interface, in your code, and in your documentation to more accurately reflect inclusivity. You can start by identifying and removing exclusive language first and then commit to understanding the types of habits or practices that can lead to exclusion.

The list of patterns and anti-patterns below shows what proper (and poor) adherence to company policies looks like within a Salesforce solution. You can use these to validate your designs before you build, or identify areas in your system that need to be refactored.

To learn more about Salesforce tools for aligning designs with company policies, see Tools Relevant to Compliant.

Artificial Intelligence

Artificial intelligence involves using a system to perform tasks that normally require human intelligence. Examples can include speech recognition, visual pattern recognition, language processing, and decision making. The Salesforce platform comes with a built-in AI layer called Einstein. This is a suite of tools that the platform uses to perform a variety of tasks such as analyzing patterns in your data, predicting business outcomes, and providing recommendations. Einstein also includes tools for language processing and chatbots that enhance customer communications.

Most of the underlying Einstein algorithms are not configurable, but the models are fine-tuned by your customers' data once it enters your system. So, if your underlying data is biased or skewed, your models will become biased and inaccurate as well. An example of bias is not including members of a certain race, gender, or ethnicity in your contact list even though your customer base is diverse and includes members of that group. Refer to the Salesforce Responsible Creation of AI Trailhead module, AI Ethics Maturity Model, and Trusted AI principles for more information.

Not accounting for applicable legal regulations and your company’s own ethical standards can lead to biases within your AI, resulting in lawsuits, lost revenue, customer trust issues, and damage to your company’s public image.

Here’s what to consider for the responsible and ethical use of AI:

Examine your datasets. Ensure that your datasets are representative of everyone your AI functionality will impact. This may require you to research your users to understand who they are and determine whether or not your data accurately represents them all in order to mitigate any potential biases.
Increase prediction model transparency. Some tools, such as prediction builder and recommendation builder, enable you to design models that drive the types of predictions or recommendations the system will make. These tools offer the option to segment your dataset if you only want the system to analyze a subset of your data. This helps to improve accuracy but also makes it possible to introduce bias into the data you’re asking the system to analyze. Document your models thoroughly and use the features available within tools like Einstein Discovery to detect and remove bias from your models. Lastly, ask your organization’s legal team or a third-party auditor to review your models prior to implementing them in your production environment.
Design chatbot conversations with care. Chatbots enable you to design the messages your system can send to your external users as well as the overall flow of the conversation. If designed carelessly, a chatbot may use exclusive or offensive language that will reflect poorly on your business. Review the guidelines outlined in Conversation Design Best Practices. Include them in your design standards along with any additional guidelines that align to your organization’s values and ethics. Document your chatbot logic along with all message text, and ask your legal team or a third-party auditor to review it.
Be prepared for regulations. In addition to ethical concerns with AI, many governments have also passed or are in the process of passing legislation that regulates the use of AI by organizations that operate within their jurisdictions. This legislation can include the requirement to publish model cards that describe how an AI solution was created and works. Before you implement an artificial intelligence-based solution, be aware of what type of AI-related functionality is or isn’t acceptable in the regions where your systems will be used and make any necessary adjustments to your strategy. You may find that you have to disable certain features in some regions to comply with local regulations; if so, ensure that your systems can continue to operate without those features.
Monitor your organization’s AI models. Impacted users should know when an AI has been used and have the opportunity to easily report harm and request remediation. It’s important to note that reporting alone may not be sufficient to determine if your AI functionality is causing harm to a user or group of users. Continually monitor your models for data drift, changes in fairness/bias scores, accuracy, and robustness. Make sure that you have plans in place to handle quality alerts and respond quickly when negative impacts are identified.

The list of patterns and anti-patterns below shows what proper (and poor) AI design looks like within a Salesforce solution. You can use these to validate your designs before you build, or identify areas of your system that need to be refactored.

To learn more about Salesforce tools for implementing more ethical AI policies, see Tools Relevant to Compliant.

Ethical Standards Patterns and Anti-Patterns

The following table shows a selection of patterns to look for (or build) in your org and anti-patterns to avoid or target for remediation.

✨ Discover more patterns for ethical standards in the Pattern & Anti-Pattern Explorer.

	Patterns	Anti-Patterns
Company Policies	In your design standards: - Standards include clear guidance for areas impacted by company policies	In your design standards: - Design standards do not exist or do not provide clear guidance about areas that are subject to company policies
	In your documentation: - Documentation for configuration and customizations includes references to supported company values	In your documentation: - Documentation for configuration and customizations does not reference company values or policies
	In your org: - All objects and fields that are subject to company policy-related compliance have Compliance Categorization, Data Owner, Data Sensitivity Level, and Field Usage configured	In your org: - Objects and that are subject to company policy-related compliance are missing configuration for Compliance Categorization, Data Owner, Data Sensitivity Level or Field Usage
Artificial Intelligence	In your design standards: - Policies and approved use cases for AI applications are clear and easy to find - Standards for chatbot messaging and conversation flow have been documented - Generative responses always identify data sources used by AI models - No generative responses are sent directly to end users without points of human involvement - Data sets that can/can not be used for prompt enginerring have been documented - Bots and generative AI responses are clearly identified to users - Standards for when and how to use disclaimers for generative AI are clearly defined - Clear requirements for how to document points of human involvement in AI solution designs exist - Standards for documenting direct and indirect feedback paths in AI solution designs exist - Points at which AI must be identified for a user are clearly defined	In your design standards: - Design standards don't exist or do not include clear policies and approved use cases for AI applications - Clear standards for chatbot messaging and conversation design do not exist (but chatbots are being used) - Generative responses do not identify data sources used by AI models - Generative responses are sent directly to end users without points of human involvement - Data sets used for prompt engineering are not documented - Bots and generative AI responses are not identified to users - Disclaimers regarding generative responses are missing - No requirements for documenting points of human involvement in AI solution designs exist - No standards for documenting direct and indirect feedback paths for AI solution designs exist - Design standards fail to indicate points at which AI must be identified to users
Artificial Intelligence	In your documentation: - Documentation for configuration and customizations involving AI functionality contains a thorough description of all process logic and is stored in a central location that is accessible by legal teams or auditors - Models that drive predictions and recommendations are clearly documented, including any applicable data segments - Conversation logic and chatbot messages are thoroughly documented - Processes are in place to monitor your organization's AI models for data drift, changes in fairness and bias scores, accuracy, and robustness - Descriptions are maintained for the training, evaluation, and testing data used for all AI processes - Descriptions are maintained for any AI-related data cleaning along with bias testing, associated results, and performance/accuracy scores (for example, F1 scores)	In your documentation: - Documentation for configuration and customizations involving AI functionality is missing, incomplete, or stored in an inaccessible location - Predictions or recommendations are implemented in your org without documentation of their models - Chatbots are implemented in your org without documentation of messages and conversation flow - AI monitoring processes do not exist or are not documented - Information about training, evaluation, and testing data used for all AI processes is unclear or unavailable - Information about AI-related data cleaning, bias testing, and results is unclear or unavailable

Accessibility

In technology, accessibility deals with how usable systems or solutions are for people with different abilities. Ensuring your systems are designed to work for all users, regardless of ability, is a legal requirement in some locations and industries. Beyond legal requirements, building accessible systems enables your organization to build and grow trust with your stakeholders. In customer-facing applications, it can even boost revenue, if customers decide to use your systems over alternatives that aren’t as accessible.

Salesforce publishes Accessibility Conformance Reports (ACRs), which are industry-standard documents that explain how our software meets accessibility standards, and most of our UI-based controls, including Lightning Web Components and Experience Cloud Templates, were built to adhere to accessibility standards. Depending on how your business goes to market with its products or services, our baseline accessibility features may be sufficient. However, you may have additional requirements that extend beyond our standards so make sure to review our ACRs and release notes prior to the start of any project and document any additional accessibility requirements.

You can improve how accessible your systems by focusing on two key areas: data entry and navigation.

Data Entry

Data entry activities happen any time a user needs to input information into a field, form, or another part of a user interface. While keyboards and mice are the most common ways to enter data into systems, some users may rely on speech-to-text or similar devices. In addition to using different input tools, your users may also speak different languages.

When your solutions are not designed with accessibility in mind, individuals with certain types of disabilities can be excluded from interacting with them.

Consider the following when designing for accessibility:

The language your users prefer. Depending on where your business operates, you may decide to set a single, standard language for your systems or you may want to offer multilingual capabilities. If you want to display text in more than one language, maintain in your design standards a list of field labels and other UI elements, such as notifications and error messages with text that needs to be translated, and ask a native speaker to review the translations to ensure that they make sense. Use Salesforce translation features to power your metadata and data translations in real time, and be sure to test any multilingual features thoroughly.
The types of input devices that will be used. List any tools that may be used for data input beyond a standard keyboard and mouse in your design standards. Include accessibility testing in your test plans and make sure all inputs are tested with multiple types of input devices.
The usability of your forms. Ensure your forms include visible labels, provide helpful error messages, guide the user toward completion, inform the user of their progress, and let them review, confirm, and edit their inputs.

The list of patterns and anti-patterns below shows what data entry looks like when properly (and poorly) designed for accessibility within a Salesforce solution. You can use these to validate your designs before you build, or identify areas in your system that need to be refactored.

To learn more about Salesforce tools for building more accessible data entry, see Tools Relevant to Compliant.

Navigation involves users moving focus between screens and between fields within a screen. Users may need to navigate through the various UI elements in your system in a variety of ways, including via clicks and keystrokes, while relying on their sight, hearing, and touch. Ensure that your design standards include a list of navigation devices that you plan to support. Implementation teams should refer to this list when testing to make sure that all possibilities are accounted for.

Consider the following questions — and their answers — as you design accessible navigation:

How will users navigate your solution? List any devices that may be used for navigation beyond a standard keyboard and mouse in your design standards.
Is your navigation consistent? Include standards for navigation controls in your design standards to ensure consistency across your entire system. Navigation paths should be similar throughout your entire system. Having a blue Next button in the bottom right corner of one screen and a green Next button in the center of the following screen might be a mild annoyance for users who don’t have disabilities, but it can make your application impossible to navigate for users who do.
Do your tests account for accessibility? Include accessibility testing in your test plans and make sure all navigation flows are tested with multiple types of input devices.
Is the keyboard focus consistently visible? Always visually display the current state of keyboard focus so users who rely on a keyboard to navigate know where it is.
Does your navigation rely on color? Avoid using color alone to present information or to request an action. Ensure you are following the Web Content Accessibility Guidelines (WCAG) 2.0 for proper use of color as meaning, and apply the right level of contrast.
Have your designs been reviewed? Conduct regular reviews to ensure that your user interface is consistent and easy to comprehend.

The list of patterns and anti-patterns below shows what navigation looks like when properly (and poorly) designed for accessibility within a Salesforce solution. You can use these to validate your designs before you build, or identify areas of your system that need to be refactored.

To learn more about Salesforce tolls for building more accessible navigation, see Tools Relevant to Compliant.

Accessibility Patterns and Anti-Patterns

The following table shows a selection of patterns to look for (or build) in your org and anti-patterns to avoid or target for remediation.

✨ Discover more patterns for accessibility in the Pattern & Anti-Pattern Explorer.

	Patterns	Anti-Patterns
Data Entry	In your design standards: - All devices that may be used for data input beyond a standard keyboard and mouse are listed - Text values and their translations into all supported languages are listed	In your design standards: - Only some, or none, of the devices that may be used for data input beyond a standard keyboard and mouse are listed - Supported languages are listed along with UI elements to be translated
	In your test plans: - Test steps include using multiple types of input devices to enter data - Test steps include data entry in multiple languages	In your test plans: - Accessibility testing is not included or testing for accessible data entry is done ad hoc
	In your org: - Translations for supported languages are stored in Translation Workbench	In your org: - Translations are stored in custom labels
Navigation	In your design standards: - All devices that may be used for navigation (not just standard keyboard and mouse) are clearly listed - UI/UX standards specify the type and style of all navigational controls - The types of visual cues approved to convey meaning or state are clearly listed, and color is not a primary cue	In your design standards: - Design standards do not exist or do not account for accessibility requirements for navigational controls - UI/UX standards for navigation are inconsistent - Visual cues for meaning or state rely on color or there are no clear lists of visual cues for builders
Navigation	In your test plans: - Test steps include using multiple types of input devices to navigate - Test plans include using UI/UX testing to ensure consistent navigational paths	In your test plans: - Accessibility testing is not included or testing for accessible navigation is done ad hoc

Tools Relevant to Compliant

Tool	Description	Legal Adherence	Ethical Standards	Accessibility
Consent API	Track customer preferences for consent	X
Consent Event Stream	Send notifications for changes to consent or contact info	X
Consent Management Objects	Manage customer privacy and consent preferences	X
Data Access and Portability	Export customer-related data upon request	X
Data Classification	Record key compliance and audit info for object fields	X
Data Deletion	Delete data to comply with legal regulations	X
Data Privacy Preferences	Store customer data privacy preferences	X	X
Data Translation	Translate data presented to users	X		X
Einstein Data Detect	Align categories and sensitivity levels to actual data	X
Einstein Data Exploration Consent	Manage project and object permissions for data scientists	X	X
Einstein Prediction Builder	Make custom predictions without writing code		X
Files Connect	Browse, search, and share external files from Salesforce	X
Hyperforce	Comply with local data storage requirements	X
Model Card Generator	Document usage info about your AI predictions		X
Metadata Translation	Translate languages to localize applications	X		X
Portability API	Compile customer data identified in your portability policy	X	X
Preference Center	Gather customer communication preferences	X	X
Privacy Center	Satisfy customer requests and data privacy laws	X	X
Restriction of Data Processing	Restrict personal data processing methods	X	X
Right to Be Forgotten	Delete individual customer data upon request	X
Salesforce Files	Share and store files privately	X
Security Center	View security and privacy settings across multiple orgs	X
Shield Platform Encryption	Encrypt data at rest and in transit	X
Translation Workbench	Maintain translated values for metadata and data labels	X		X

Resources Relevant to Compliant

Resource	Description	Legal Adherence	Ethical Standards	Accessibility
5 Principles for Responsible AI Design	Design Artificial Intelligence (AI) functionality ethically		X
Accessibility Basics (Trailhead)	Learn why accessibility is important			X
Accessibility Conformance Reports (ACRs)	Understand how Salesforce meets accessibility standards			X
Accessibility Overview	Understand accessibility within Salesforce Lightning			X
AI Ethics Maturity Model	Develop a roadmap to operationalize ethical principles		X
Best Practices for Conversation Design	Follow best practices when designing chatbots		X	X
Best Practices for Sustainable Design (Trailhead)	Incorporate sustainability into your designs		X
Consent Management	Track and comply with consent and opt-out requests	X
Data Policies for Einstein	Control data use across Einstein functionality	X	X
Design Standards Template	Create design standards for your organization	X	X	X
Ethical Leadership and Business	Insights on technology, equality, and ethics		X
Ethical Use Policy	Explore Salesforce policy on ethical use of our products and services		X
Ethics by Design (Trailhead)	Incorporate ethical design into technology development		X
Explore Salesforce's Culture and Values (Trailhead)	Explore Salesforce's core values		X	X
Follow Accessible Mobile Design Guidelines	Follow best practices to make your designs accessible		X	X
Get Started with Web Accessibility (Trailhead)	Learn the basics of how to make websites and apps accessible			X
How To Run a Consequence Scanning Workshop	Consider all possible outcomes while innovating		X
How We’re Bringing Inclusive Language to Our Products	Understand how Salesforce is replacing noninclusive terms		X
Implementing Data Protection and Privacy	Evaluate data protection and privacy requirements	X
Inclusive Design (Trailhead)	Foster innovation with inclusive design principles		X	X
KPI Spreadsheet Template	Set Key Performance Indicators (KPIs) for your organization	X
Legal Information	Explore Salesforce's Legal Information center	X
LWC Cookie Consent Module	Control user cookie access in Experience Cloud sites	X	X
Privacy Overview	Learn about data privacy by region and industry	X
Salesforce Compliance Certifications	Review Saleforce's compliance certifications and attestations	X
Sustainable Design (Trailhead)	Strengthen the relationship between business and society		X
Testing for Web Accessibility (Trailhead)	Utilize automated and manual testing to ensure accessibility			X
The Build With Intention Toolkit	Consider all possible outcomes of your designs		X

Tell us what you think

Help us keep Salesforce Well-Architected relevant to you; take our survey to provide feedback on this content and tell us what you’d like to see next.