# Fairness | Well-Architected Framework

Source: https://architect.salesforce.com/docs/architect/well-architected/guide/fairness.html

> Ensure Salesforce solutions are accessible, non-discriminatory, and transparent with appropriate human oversight of automated decisions.

![Fairness](https://architect.salesforce.com/ns-assets/well-architected/fairness-banner.png)

In Salesforce architectures, fairness means building solutions that serve users equitably through accessible interfaces, bias detection and mitigation, transparent decisions, and ethical governance. Einstein’s predictions influence outcomes that affect customers and employees, which means that architects should be designing systems that produce equitable results across demographic groups while also remaining accessible to users with disabilities.

Salesforce provides platform capabilities that are purpose-built for fairness, and we strive to conform with [WCAG 2.2 AA](https://www.w3.org/TR/WCAG22/). When used correctly, the Salesforce Lightning Design System (SLDS) provides components that are designed to support this goal. Let’s take a closer look at each component.

*   Shield Platform Encryption protects sensitive attributes such as demographic data, and Event Monitoring provides the audit trails that support transparent data handling.
*   The Einstein Trust Layer (ETL) captures a secure audit trail for generative AI prompts and responses for monitoring and compliance purposes.
*   The Experience Cloud includes accessibility controls.
*   The Field Audit Trail provides long-term retention of field-level data-change history, which supports algorithmic accountability when AI decision data is stored in tracked fields.

These capabilities help lower the operational costs of Salesforce fairness practices.

At Salesforce, fairness operates across three dimensions to provide solutions. Inclusive design helps make Lightning Web Components (LWC), Visualforce pages, and Experience Cloud sites fully accessible—featuring seamless keyboard navigation, screen reader compatibility, and cognitive design accommodations. AI fairness practices help Einstein predictions produce equitable outcomes using bias detection, diverse training data, and continuous monitoring. Governance provides the processes and controls to sustain fairness as models evolve and use cases expand.

Neglecting fairness creates compounding risk. Inaccessible Experience Cloud sites may expose organizations to [Americans with Disabilities Act (ADA)](https://www.ada.gov/law-and-regs/) litigation and, for federal agencies and their contractors, [Section 508](https://www.section508.gov/) compliance violations. Depending on the system’s risk classification and emerging algorithmic accountability laws, biased Einstein predictions may violate [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) requirements. Solely automated AI-driven decisions with legal or similarly-significant effects that lack meaningful information about the decision logic may violate [GDPR Article 22](https://gdpr-info.eu/art-22-gdpr/) and [Article 15(1)(h)](https://gdpr-info.eu/art-15-gdpr/) information rights.

Organizations that architect for fairness tend to reduce foreseeable harm to the customers, employees, and communities that are affected by their systems. Fairness failures can cause tangible, material harm to affected individuals—including economic harm, denied opportunities, emotional distress, and reinforcement of systemic discrimination. Regulatory alignment tends to follow from serving affected individuals well.

Use these principles to guide your architectural decisions for fairness on the platform.

*   **Design for Lightning accessibility patterns.** When building, use the Lightning Design System and standard Lightning Web Components that are designed to support WCAG 2.2 AA accessibility whenever possible. When you build with SLDS, you’re leveraging a library where accessibility is a core design principle. SLDS components are vetted for keyboard accessibility and compatibility with assistive technology, and many include an accessibility section with developer tips. If a custom component is required, explicit Accessible Rich Internet Applications ([WAI-ARIA](https://www.w3.org/WAI/standards-guidelines/aria/)) implementation, semantic HTML, and keyboard-navigation patterns must be validated through assistive technology testing.
*   **Reduce and monitor bias with the right tools for each model type.** Validate AI outputs for equitable outcomes across demographic groups before deployment and continuously in production. For predictive models, capture decision data through Einstein Discovery and custom instrumentation and analyze it in CRM Analytics to measure fairness metrics; for generative AI and Agentforce features, use the Einstein Trust Layer (ETL) audit trail of prompts and responses. Document decisions to meet regulatory transparency requirements.
*   **Leverage Shield Platform Encryption for data protection controls.** Use Shield Platform Encryption with deterministic schemes for sensitive attributes that require exact-match queries while also protecting personal data. Route Event Monitoring logs to an external Security Information and Event Management (SIEM) system to support tamper-evident audit trails—when the SIEM enforces write-once storage and access segregation that exceed Salesforce native retention windows for required regulations.
*   **Design review workflows for high-stakes predictions.** Configure approval processes and review mechanisms in Salesforce Flow to ensure that Einstein predictions affecting consequential decisions receive appropriate human review. Use confidence thresholds and business rules to determine when predictions require validation before taking action.
*   **Apply Organization-Wide Defaults (OWD) and Field-Level Security (FLS) for non-discrimination.** Architect data access patterns using OWD and FLS to restrict access by default, and only grant the additional access that each role needs using sharing rules. Avoid granting profiles excessive access that may expose sensitive attributes and enable discriminatory decision-making.
*   **Enable user agency through platform consent.** Use the consent management capabilities in Data 360 or custom consent objects with Field Audit Trail to track granular AI consent per use case. Enable users to opt out of AI-driven features and provide human alternatives (when possible).

Data architecture decisions determine the populations that become visible—and invisible—in Salesforce systems. Poor data quality isn’t solely a technical issue. It becomes a fairness issue when data gaps systematically disadvantage specific demographic groups.

*   **Review required fields for data availability.** When required fields assume information availability that varies across demographics, data completeness becomes discriminatory. Users who can’t provide the required information become invisible in systems that reject incomplete records.
    *   Requiring email addresses excludes populations that don’t have reliable internet access or personal email addresses.
    *   Requiring US Social Security Numbers (SSN) excludes international customers and recent immigrants who haven’t yet been issued an SSN.
    *   Requiring street addresses excludes homeless populations and users with non-traditional addresses.
*   **Audit business justifications for required fields.** For every required field, it’s important to document why the information is mandatory as opposed to optional. If processes can function without certain data via alternative approaches, make those fields optional and design systems to handle missing values gracefully. This helps to ensure that users who can’t provide such data aren’t excluded.

Name fields that follow Western naming conventions (First Name, Last Name) may exclude cultures with different naming practices.

Many cultures use:

*   Single names—or mononyms—without family names
*   Patronymic systems where “last name” changes generationally
*   Multiple given names or family names
*   Names that change based on life events or social context
*   Names where “first” and “last” are culturally meaningless distinctions

Design name architecture using a single, full-name field or a flexible, multi-part structure that accommodates common naming conventions. Avoid making assumptions about name ordering, inheritance patterns, or cultural norms.

Test name architecture using diverse international names to ensure that name fields accept:

*   Single-word names (for example, Sukarno, Cher, and Teller)
*   Long names that exceed common field length limits
*   Names with diacritics, apostrophes, hyphens, and spaces
*   Names with non-Latin scripts (for example, Arabic, Chinese, Cyrillic, and Devanagari)

When name validation rejects a user’s legitimate name, they experience system rejection that’s based upon their cultural identity.

Address validation services are often optimized for US and Western European formats and frequently fail to recognize:

*   International address formats with different field ordering
*   Rural addresses without street names
*   Military addresses (for example, APO and FPO)
*   PO boxes and alternative delivery locations
*   Tribal lands with unique address systems
*   Countries with non-Latin scripts for address components

When address validations reject non-traditional address formats, it prevents account creation, shipping, and service delivery for users whose addresses don’t match validation database expectations.

Here are a few ways to design address validations with accessibility in mind:

*   Implement permissive address validation.
*   Accept free-form address entry when structured validations fail.
*   Store addresses as they’re entered by users instead of forcing users to make invalid corrections.
*   Use address validation for data enrichment and duplication detection, not to validate address formatting.

Instead of blocking data captures upfront, build address verification into fulfillment processes where the accuracy of the address matters operationally.

Universal access assumptions for specific communication channels exclude populations with different technology access or preferences.

Email-only communication excludes:

*   Users without reliable internet access
*   Elderly populations that are less comfortable using email
*   Users in regions where SMS or messaging apps are the primary communication method

Phone-only communication excludes:

*   Users who are deaf and hard-of-hearing
*   Users without phone access or those using shared phones

Design omnichannel communication architecture that allows users to control channel preferences. Store preferred communication methods in Contact records and consistently respect preferences across all outbound communication systems. Provide a variety of communication alternatives instead of assuming that single-channel methods work universally.

Collecting demographic data for fairness monitoring requires careful architecture to prevent misuse.

Collecting and processing demographic data is jurisdiction-dependent and legally restricted (in the EU, GDPR [Article 9](https://gdpr-info.eu/art-9-gdpr/) treats it as special-category data requiring a specific legal basis; in the US, bias monitoring typically relies on voluntary EEO self-identification). Where a lawful basis exists, organizations use demographic data to:

*   Monitor fairness metrics that are stratified by protected groups
*   Detect bias in automation and AI systems
*   Demonstrate regulatory compliance with anti-discrimination requirements

Collecting demographic data creates certain risks:

*   Data may be used for discriminatory purposes if access controls fail
*   Users may distrust collection methods and provide inaccurate data
*   Collection may feel invasive or discriminatory

Architect voluntary self-identification and design demographic data collection using information that’s:

*   Clearly explained with a transparent purpose (for example, fairness monitoring or compliance reporting)
*   Voluntary and includes a “Prefer not to answer” option that’s always available
*   Separated from operational data with strict FLS to prevent inappropriate access
*   Aggregated for reporting and analytics and not linked to individual decisions
*   Monitored via Shield Event Monitoring for access-pattern auditing

It’s important to document in privacy policies exactly how demographic data will and won’t be used. Violating user trust through undisclosed data usage may severely damage credibility, which can be difficult to recover from.

Third-party data enrichment that appends demographic, firmographic, or behavioral data to Salesforce records may introduce bias through:

*   Inaccurate inferences that are based on stereotypes
*   Incomplete coverage with gaps that correlate to demographics
*   Proprietary algorithms that use unknown fairness properties
*   Data that’s sourced from biased historical records

Before implementing data enrichment services, it’s important to audit:

*   Vendor fairness testing and bias mitigation practices
*   Data coverage and accuracy across demographic groups
*   Inference methodologies and features that are used to create predictions
*   Contractual data usage restrictions and retention policies

Keep in mind that once third-party data enters your Salesforce org it may affect decisions, creating vendor-introduced bias that also reflects as a bias in your org.

In Salesforce contexts, accessibility refers to architecting Lightning Web Components, Visualforce pages, and Experience Cloud sites that work for users with disabilities. Standard Lightning components provide baseline accessibility when used correctly; however, custom development and Experience Cloud configuration require explicit accessibility implementation.

Lightning Design System components are designed to support WCAG 2.2 AA conformance when they’re used as designed. Salesforce strives for—but doesn’t certify—full conformance. Deviating from SLDS patterns or building custom components without accessibility consideration creates barriers for users with disabilities.

Standard Lightning Web Components provide built-in accessibility. Components like lightning-input, lightning-combobox, lightning-datatable, and lightning-card automatically include proper ARIA attributes, label associations, keyboard navigation, and focus management. When possible, use standard components rather than building custom alternatives that look similar but may lack the appropriate accessibility infrastructure.

*   **Use semantic HTML in custom Lightning Web Components.** When building custom components, use semantic HTML elements (<header>, <nav>, <main>, <aside>, <article>, <section>) rather than confusingly nested <div> components. Screen readers use semantic structure to convey page organization and enable landmark navigation. Avoid using purely visual markup that strips meaning from content hierarchy.
*   **Implement ARIA in custom components.** Apply ARIA landmarks, roles, and properties when semantic HTML can’t convey interface behavior. Dynamic content updates require aria-live regions that announce changes to screen readers. Custom interactive components need explicit role definitions that match their behavior. Lightning base components handle ARIA automatically; however, custom components require manual ARIA validation via screen reader testing.
*   **Test with assistive technology:** Validate Lightning components using actual screen readers (for example, JAWS and NVDA for Windows, VoiceOver for macOS and iOS, and TalkBack for Android). Based on Deque’s large-scale study, automated tools like axe-core catch approximately 57% of accessibility issues by volume. The remaining issues require manual testing with assistive technology by people who understand screen reader navigation patterns.
*   **Use focus management in Lightning flows.** When modals open, dynamic content loads, or users complete multi-step flows, you should programmatically manage focus to guide keyboard users to new content. Lightning modal and pop-over components provide basic focus management, but complex flows need explicit focus logic to move the focus appropriately as content changes.

Experience Cloud sites serve external users—including customers, partners, and public audiences—who require accessible design that may need to meet ADA, Section 508, and/or [European Accessibility Act](https://eur-lex.europa.eu/eli/dir/2019/882/oj) requirements (depending on jurisdiction, audience, and organization type).

*   **Use accessible templates.** Experience Cloud templates that are built using Lightning Web Runtime (LWR) include baseline accessibility. Standard templates such as Customer Account Portal and Help Center provide WCAG 2.2 AA foundations when they’re configured correctly. Custom templates require explicit accessibility implementation, including semantic markup, keyboard navigation, and screen reader compatibility.
*   **Verify WCAG compliance in theming.** Custom themes and branded sites require color-contrast validation. Experience Builder’s Theme settings control colors, typography, and spacing. Ensure that all text meets 4.5:1 contrast for normal text (under 18pt for regular or under 14pt for bold), and 3:1 for large text (18pt or larger for regular or 14pt or larger for bold) and UI components. Use browser developer tools or online contrast checkers to validate for compliance. Test with browser zoom to 200% to ensure that the text scales without losing content or functionality.
*   **Use keyboard navigation in navigation menus.** Experience Cloud navigation components must support keyboard-only operation without mouse dependency. Users must navigate into and out of dropdown menus, mega menus, and flyout navigation using Tab, Enter, Escape, and Arrow keys without focus traps. Test all navigation paths using only the keyboard to validate accessibility.
*   **Enable form accessibility in Experience Cloud.** Associate labels explicitly with all form inputs using proper label elements or aria-labelledby. On its own, placeholder text fails accessibility requirements because the text vanishes as soon as data entry begins, which leaves screen-reader users without sufficient, persistent context. Lightning input components provide built-in label association when they’re configured using the required label attributes. Custom Visualforce forms require explicit label-input association.
*   **Test Experience Cloud sites using assistive technology.** Before launching public-facing Experience Cloud sites, you must conduct comprehensive accessibility testing using screen readers, keyboard-only navigation, and browser zoom. It’s important to include users with disabilities in usability testing to reveal practical, lived-experience barriers that expert reviews may often miss. Testing only internal Lightning pages without validating external Experience Cloud accessibility leaves public-facing sites vulnerable to accessibility complaints and litigation.
*   **Use alternative text for images and icons.** All informative images, icons, and graphical content in Experience Cloud require alt text. Decorative images use empty alt text (alt=""), which allows screen readers to skip them. Informative images provide meaningful alt text that describes content and function. When you’re writing alt text for icons, focus on the action or purpose of the icon rather than its visual appearance (for example, instead of describing a magnifying glass icon as “magnifying glass,” the alt text should state its functional utility, such as “Search site”). When managing images, the CMS must prompt content authors to enter alt text or explicitly mark the image as decorative (which sets alt=""). This ensures accessibility by preventing missing alt text and forced descriptions for aesthetic images.

Complete keyboard accessibility means that users can access all functionality using their keyboard without requiring mouse or touch interaction at any point.

*   **Use logical focus order in Lightning pages.** Ensure that the focus order follows visual layout and interaction flow. When users press Tab, the visual focus should move through interactive elements in the order that users expect based on visual design. Lightning App Builder and Experience Builder establish focus order based on component placement. Custom components require explicit tabindex management to ensure logical focus progression.
*   **Use visible focus indicators to meet contrast requirements.** Lightning Design System provides focus styles to meet WCAG requirements for most components. Custom components may need enhanced focus indicators to meet the 3:1 contrast requirement against surrounding content. Focus indicators must be clearly visible to allow users with low vision to navigate via keyboard. _Never_ remove focus indicators with CSS (outline: none) without providing alternative visible-focus styling.
*   **Use keyboard-trap mitigations in modals and overlays.** Modal dialogs should trap focus within the modal while it’s open, which prevents keyboard users from reaching obscured background content. The focus trap should release upon modal close and return the focus to the trigger element. Embedded content—including iframes and third-party widgets—mustn’t permanently capture keyboard focus without an escape mechanism.
*   **Use shortcut keys without conflicts.** Lightning provides standard keyboard shortcuts that are documented in Salesforce Help. Custom keyboard shortcuts must be designed to prevent conflicts with standard browser controls and screen-reader navigation commands. In alignment with WCAG success criteria, single-character shortcuts (for example, pressing a single letter or punctuation mark) mustn’t trigger global actions. They must either restrict the activation to when a specific component has active focus, or provide users with a way to turn off or remap the shortcut entirely.

Build accessibility validation into CI/CD pipelines to find structural issues automatically on every deployment rather than treating accessibility as periodic manual audits.

*   **Use sa11y for Lightning Web Component accessibility testing.** Salesforce’s sa11y libraries (the @sa11y/jest package) wrap the axe-core accessibility engine to add a toBeAccessible() matcher for Jest unit tests. Write accessibility tests that validate proper ARIA usage, label associations, contrast ratios, and semantic markup automatically as part of unit testing. Configure builds to fail when critical accessibility issues are detected.
*   **Use Lighthouse CI for Experience Cloud.** Google Lighthouse audits webpage accessibility, including Experience Cloud sites. Integrate Lighthouse CI into deployment pipelines to scan public-facing pages for accessibility issues. Configure score thresholds to require minimum accessibility scores before deployment approvals.
*   **Use the Accessibility Agent, available through the Salesforce DX MCP package.** In MCP-compatible environments or within Agentforce Vibes, it reviews code against WCAG standards, surfaces targeted fixes, and can generate a pull request for an engineer to review, validate, and merge.

Bias has existed in deterministic Salesforce automation long before AI entered the picture. Assignment rules, Flow decisions, validation rules, and territory design encode human judgment that may perpetuate discrimination. Unlike AI bias—which architects scrutinize extensively—automation bias often passes through unexamined because deterministic logic feels objective.

*   **Follow lead and case assignment rules.** Distribute work across sales and service teams. When assignment logic uses criteria that correlates with protected characteristics, automation creates systematic disparities in service quality and opportunity access.
*   **Assignment rules using territory, zip code, or account characteristics** may route high-value opportunities disproportionately to specific teams while routing lower-value work elsewhere. If territory boundaries correlate with customer demographics and compensation structures that differ across territories, assignment automation creates economic discrimination.
*   **Audit assignment rule outcomes regularly.** Calculate assignment distributions across territories and teams that are stratified by customer demographics. If Enterprise accounts are concentrated in specific territories while SMB accounts are distributed elsewhere—and if Enterprise territories receive better compensation or resources—then assignment rules may produce inequitable outcomes that warrant fairness review.
*   **Review omni-channel skill-based routing.** This can affect service quality across customer populations. If routing logic implicitly assumes that certain skills correlate with customer value or problem complexity, then customers may receive different service outcomes based on demographic proxies.

It’s important to monitor the average time-to-handle, first-contact resolutions, and customer satisfaction across routing paths. Disparities may indicate whether certain customer segments systematically receive less experienced agents or fewer routing options.

*   **Review Salesforce Flow automations.** Making approval decisions, eligibility determinations, or access grants may encode discriminatory logic through seemingly innocuous business rules. Certain Flows create indirect discrimination when the criteria correlates with protected characteristics.
*   **Review Flow decisions with fairness in mind.** For every Flow that makes consequential decisions that affect users, it’s important to ask:
    *   What happens to users who don’t fit the typical customer profile?
    *   Do decision criteria correlate with demographic characteristics?
    *   Are exceptions and edge cases handled equitably or do they systematically disadvantage specific groups?

It’s important to document Flow decision logic and fairness considerations in architecture decision records, and subject high-stakes Flows to the same ethics review policies as AI systems.

*   **Review validation rules.** Preventing data entry may exclude valid data from users whose information doesn’t match system assumptions. Validation rules that reject legitimate data create invisible populations. Users whose data doesn’t fit validation patterns can’t engage with certain systems. Validation failures often go unreported because users abandon their requests rather than report technical errors. Here are several common validation bias patterns:
    *   **Name validations** that require Latin characters may exclude names with diacritics and non-Latin scripts.
    *   **Phone number validations** often use US/Western formats, which excludes international numbers and alternative communication methods.
    *   **Address validations** fail to recognize non-standard addresses (for example, PO boxes, rural routes, tribal lands, and international formats).
    *   **Email validations** that require personal email addresses may create a disadvantage for users who don’t have personal email access.
*   **Test validation rules using diverse data.** Include international addresses, non-Western names, and alternative phone formats in validation testing. When the validation rejects legitimate data, you must expand the validation logic to avoid excluding valid users.

*   **Review sales territory designs.** Customer segmentation strategies and sales territory designs determine resource allocation across customer populations. When territory boundaries or segmentation criteria correlate with demographics that result in unequal resource allocation, that allocation can produce discriminatory outcomes. Territory designs that use geographic boundaries often correlate with racial, ethnic, and economic demographics due to residential segregation patterns. If compensation, staffing levels, or resource investments differ across territories, geography can become a mechanism for discriminatory resource allocation.
*   **Analyze territory demographics before finalizing designs.** Map customer demographics across proposed territory boundaries. When demographic concentrations emerge, evaluate whether the resource allocation is equitable across all territories regardless of demographic composition. If the business justification requires different resource levels across territories (for example, market maturity, competitive intensity, and growth potential), document that justification explicitly and monitor the outcomes to ensure that underserved territories receive adequate investment opportunities to prevent entrenched disparities.

*   **Maintain transparency in automation logic.** Document business rules, assignment criteria, and Flow decision logic in Salesforce Knowledge or architecture decision records. Transparent automation enables fairness to be reviewed in a way that hidden logic prevents.
*   **Regularly audit outcomes.** Schedule quarterly audits to analyze automation outcomes that may be stratified by customer demographics. Keep in mind that disparities trigger investigations and potential remediation.

It’s important to track:

*   Assignment distributions across teams and territories
*   Approval rates for Flows that make eligibility decisions
*   Validation rule rejection rates by data pattern
*   Territory performance and resource allocation
*   **Review high-stakes automation through an ethical lens.** Subject Flows and assignment rules that affect employment, credit, service access, or other consequential outcomes to the same ethics review process as AI systems. Automation bias needs the same level of scrutiny as algorithmic bias.

At Salesforce, AI fairness focuses on using Einstein to validate that predictions produce equitable outcomes across all demographic groups. Einstein Discovery and custom instrumentation capture predictive-model decision data that enables bias detection. CRM Analytics dashboards track fairness metrics. Field Audit Trail and Event Monitoring capture decision data for algorithmic accountability.

Einstein predictions that affect consequential decisions (for example, lead scoring, opportunity forecasting, and customer segmentation) require pre-deployment fairness evaluations that function as a mandatory equivalent step (similar to security reviews).

Analyze all predictive model features for correlation with protected characteristics using statistical methods. Remove or transform proxy features after evaluating whether their predictive value justifies inclusion despite proxy effects.

*   **Audit Salesforce CRM data before training.** Salesforce orgs contain decades of human decisions that are based on historical practices. If past sales teams prioritized certain demographics, then Einstein Lead Scoring learns those patterns and perpetuates them. Before training predictive models on historical data, it’s important to audit that data for demographic representation gaps and measurement inconsistencies across customer segments.
*   **Calculate fairness metrics across demographic groups.** Before deploying predictive models, it’s important to calculate demographic parity, equal opportunity, and disparate impact ratios across protected groups, where you have a lawful basis to collect and process the required demographic data. If Einstein Lead Scoring assigns high scores to Segment A 50% of the time but only 30% of the time to Segment B, then a 60% ratio fails the [four-fifths rule](https://www.ecfr.gov/current/title-29/section-1607.4) (80%) and requires investigation and mitigation. The 80% figure is a screening trigger, not a legal pass/fail line: the four-fifths rule is a US federal rule of thumb for employment selection, and clearing it is not a safe harbor — a statistically significant disparity can warrant scrutiny at higher ratios, and other regimes measure adverse impact differently (EU indirect-discrimination law, for instance, turns on whether a practice creates a “particular disadvantage,” with no fixed threshold). Calibrate investigation thresholds to the jurisdictions and use cases you operate in.
*   **Capture predictive-model decision data for bias detection.** To detect bias in predictive models such as Lead Scoring and Opportunity Scoring, capture decision data through Einstein Discovery and custom instrumentation: store prediction inputs, outputs, and model versions in tracked fields and enable Field Audit Trail. Analyze that data in CRM Analytics to track decision patterns across demographic groups over time, and build dashboards that alert when demographic-parity or equal-opportunity metrics drift beyond acceptable thresholds.
*   **Detect proxy features in predictive models.** Features that correlate with protected characteristics enable indirect discrimination even when protected characteristics are excluded from the models.
    *   Salesforce data commonly contains proxy features:
        *   Territory or zip code (proxies for race, ethnicity, and income).
        *   Account name patterns (proxies for organization size and industry demographics).
        *   Communication activity timing (proxies for time zones, religion, and caregiving responsibilities).
        *   Device type or browser from Activity data (proxies for income level).

When bias is detected in Einstein predictions, you must apply mitigation at the appropriate pipeline stage (based on root cause and technical constraints).

*   **Balance data before model training.** Rebalance Salesforce CRM data through oversampling underrepresented customer segments or undersampling overrepresented segments before training predictive models. Use Data 360 to aggregate data across multiple orgs to ensure diverse training sets. Synthetic data generation may supplement sparse segments while preserving privacy through differential privacy techniques.
*   **Remove proxies in feature engineering.** When proxy features are identified, replace them with alternative features that provide predictive power without demographic correlation. If territory serves as demographic proxy, then consider industry classification or company size as alternatives. If account name patterns correlate with demographics, use firmographic attributes instead.
*   **Adjust thresholds during post-processing.** Adjust the decision thresholds per demographic segment to equalize outcome rates after training models. For employment-related decisions this is prohibited outright: [Title VII](https://www.eeoc.gov/statutes/title-vii-civil-rights-act-1964) (Civil Rights Act of 1991) bars adjusting scores or using different cutoff scores by protected class, and no amount of documented justification makes the practice lawful. Where it is not prohibited, document threshold adjustments with business justification for differential treatment when predictions inform automated decisions.
*   **Retrain models periodically using updated data.** Schedule model retraining quarterly (or when significant data distribution shifts occur). Retraining on fresh data catches emerging bias patterns and corrects any drift from original fairness baselines. Revalidate fairness metrics on every model version before production deployment to ensure that retraining didn’t introduce new biases.

The Einstein Trust Layer captures prompts, responses, and trust signals for generative AI and Agentforce features, supporting transparency and regulatory compliance for generative AI. For predictive models, transparency and decision lineage come from Einstein Discovery and Model Manager, which require custom instrumentation to retain audit data.

Build explainability into Einstein solutions from initial architecture instead of retrofitting explanations onto opaque systems after deployment.

*   **Surface Einstein Discovery explanations at decision points.** Einstein Discovery provides prediction factor explanations that show which variables most influenced specific predictions with directional impact. Architect Lightning components that display these explanations to users at the point of decision rather than requiring navigation to separate CRM Analytics dashboards. When decisions affect users, they need transparency, not abstract model performance metrics.
*   **Layer explanations for different audiences.** Provide explanation depth that’s appropriate to each audience:
    *   **Business users:** “This lead scored high because the annual revenue exceeds $1M and the engagement score is in the top 10%.”
    *   **Technical users:** Supply an Einstein Discovery model card with feature weights, training data characteristics, and validation metrics.
    *   **Customers:** “This recommendation is based on your recent purchases and customers with similar preferences.”
    *   **Auditors:** Provide decision lineage from Einstein Discovery and Model Manager—model version, input values, and the factors that drove the prediction—captured through custom instrumentation.
*   **Communicate confidence appropriately.** Display prediction confidence in user-appropriate terms and avoid raw probability scores that users may misinterpret. Instead of showing “73% confidence,” communicate this using categories (for example, High Confidence, Moderate Confidence, and Needs Review) with explanations of what each confidence level means for decision reliability, as well as what additional reviews will occur.

Maintain comprehensive, immutable audit trails that support accountability, debugging, and regulatory compliance for all AI-driven decisions that affect users.

*   **Capture predictive audit data with the right tools.** Store predictive-model audit data—prediction inputs, outputs, and model versions—in tracked fields with Field Audit Trail enabled. Architect data retention policies to meet regulatory requirements, which vary by industry and jurisdiction:
    *   Financial-services rules set retention per regulation (for example, [FINRA Rule 4511(b)](https://www.finra.org/rules-guidance/rulebooks/finra-rules/4511) sets a default six-year retention period for records that don’t otherwise have a specified retention period under FINRA rules or [SEA Rule 17a-4](https://www.law.cornell.edu/cfr/text/17/240.17a-4)).
    *   Healthcare retention is also governed by specific rules (for example, [HIPAA](https://www.hhs.gov/hipaa/index.html) requires a minimum of six years for compliance documentation; medical-record retention is set by individual state laws) rather than blanket indefinite-retention mandates.
*   **Analyze predictive-model decision data with CRM Analytics.** Build CRM Analytics dashboards on the predictive-model decision data you capture (prediction inputs, outputs, and model versions in tracked fields) to analyze decision patterns, fairness metrics, and model performance over time. Create lenses that show prediction distributions by confidence level, demographic segment, and outcome type. Configure Einstein Discovery stories that identify anomalous patterns that require additional investigation.
*   **Use the Field Audit Trail for long-term retention.** Standard field history tracks changes for 18 months in the UI and up to 24 months via the API. The Field Audit Trail allows you to keep field history indefinitely for custom objects that store AI decision data. It archives history after up to 18 months by default, then retains the archived data until you delete it. Enable Field Audit Trail on objects that contain consent records, override decisions, and bias reports to meet regulatory retention requirements.
*   **Use Event Monitoring for Agentforce interactions.** Event Monitoring captures invocation-level events for Agentforce, such as when actions and flows run. Export Event Monitoring data to an external SIEM—standard Event Log File data via the API, and the Real-Time Event Monitoring subset of events via Platform Events—for storage that exceeds the Salesforce native retention window. Tamper evidence depends on particular SIEM behavior that enforces write-once storage and access segregation. Configure SIEM queries to detect bias patterns across large volumes of Agentforce interactions.
*   **Audit Agentforce conversations with the Einstein Trust Layer.** The Einstein Trust Layer captures the audit trail of Agentforce conversation prompts and responses, stored in Data 360, providing the transcript-level record for transparency and regulatory compliance.

Let’s take a closer look at the Architect transparency capabilities that are positioned for compliance with current and emerging AI regulations across multiple jurisdictions.

*   **EU AI Act transparency requirements.** High-risk AI systems under the [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) require transparency documentation, technical documentation, human oversight capabilities, and accuracy/fairness metrics. The Einstein Trust Layer audit trails and Einstein Discovery model cards provide foundations for these requirements. Document model training data demographics, validation approaches, and known limitations in architecture decision records.
*   **GDPR right to explanation.** The GDPR gives EU data subjects the right to meaningful information about the logic of a decision when that decision is based solely on automated processing and produces legal or similarly-significant effects. This right stems from Articles [15(1)(h)](https://gdpr-info.eu/art-15-gdpr/) and [22(3)](https://gdpr-info.eu/art-22-gdpr/) when read with [Recital 71](https://gdpr-info.eu/recitals/no-71/) and was clarified by the CJEU in [_Dun & Bradstreet (2025)_](https://curia.europa.eu/). Design systems that generate coherent explanations on demand for any historical decision within data subject access request timeframes, which vary (depending on jurisdiction) between 15 and 45 days. The predictive-model decision data you capture—prediction inputs, outputs, model versions, and Einstein Discovery explanation factors—enables you to reconstruct explanations when it’s stored with sufficient retention.
*   **Algorithmic accountability laws.** US state-level algorithmic accountability laws are increasingly requiring impact assessments and transparency reporting for automated decision systems. The predictive-model decision data you capture and CRM Analytics fairness-monitoring dashboards provide the data foundations for these reports. Conduct algorithmic impact assessments before deploying consequential AI as proactive compliance rather than as a reactive response to regulatory inquiries.

OWDs, sharing rules, and Field-Level Security (FLS) shape the data access patterns that determine what information users can review and use to make decisions. Proper configuration prevents discriminatory access to sensitive attributes while also ensuring equitable service.

Design OWDs and Field-Level Security to restrict access by default. For sharing rules, use the principle of least privilege (PoLP) to grant only the additional access that each role legitimately needs, which prevents discriminatory decision-making based on protected characteristics.

*   **Enable restrictive OWD as the default.** Use Private OWDs for objects that contain sensitive customer data, and grant access by role hierarchy and sharing rules. Public Read/Write OWDs make restricting access later disruptive — tightening the default triggers a sharing recalculation and takes effect only after it completes — rather than impossible. Private OWDs with explicit sharing grants create auditable access patterns that support non-discrimination compliance.
*   **Apply Field-Level Security for sensitive attributes.** Hide sensitive fields that contain protected characteristics (for example, ethnicity, religion, and disability status) from users who don’t require access for legitimate business purposes. Configure FLS to remove read access for sensitive fields in most profiles. When these fields are required for specific purposes (for example, diversity reporting and reasonable accommodation), grant minimal access using permission sets with documented business justification.
*   **Design assignment and sharing rules for equitable outcomes.** Use assignment rules, queues, and Omni-Channel routing to distribute work equitably across territories, teams, and service agents. Avoid manual sharing that concentrates high-value opportunities or customers with specific user groups without documented business justification. Configure automatic sharing rules based on objective criteria (for example, industry, geography, and product line) rather than subjective manager discretion, which may enable bias.
*   **Provide permission sets for temporary access.** Grant temporary access to sensitive data via permission sets rather than modifying profiles, which affects all users permanently. When users need access to demographic data for specific projects (for example, diversity analysis and accommodation requests), assign permission sets with documented expirations. Scheduled Flows can revoke permission sets automatically after defined periods.

Use Shield Event Monitoring and reports to detect data access patterns that indicate potential discrimination or bias in data usage.

*   **Use Shield Event Monitoring to audit access to sensitive data.** Use Event Monitoring to capture object-level access events (report exports, API queries, and page views) on objects that contain protected characteristics or sensitive attributes. Configure queries over these events to surface who accessed the object, when, and in what context, and treat anomalous patterns (for example, sudden spikes and access by unexpected users) as triggers for investigation.
*   **Report on sharing rule distributions.** Build reports that analyze how records are distributed across users, teams, and territories. Calculate distribution statistics by customer demographics to ensure that high-value accounts and opportunities are distributed equitably. Identify concentrations where specific user groups receive disproportionate access to valuable records without documented business justification.
*   **Audit CRUD and FLS violations.** Review the Setup Audit Trail for changes to OWD settings, sharing rules, FLS configurations, and permission sets. Unauthorized changes to data access controls may indicate attempts to access sensitive data inappropriately. Use Transaction Security policies to act on high-risk, Real-Time Event Monitoring events (for example, anomalous API activity, suspicious logins, and large report or list-view exports of sensitive data). Since Transaction Security only operates on these runtime events rather than record-level DML or FLS changes, you must rely on the Setup Audit Trail and documented change-management approvals for FLS and sharing changes.

At Salesforce, user agency means that customers and employees retain meaningful control over how AI affects their experience. Salesforce consent management capabilities, Data 360 consent, and custom consent objects enable granular control over AI interactions.

Design consent tracking using Data 360 consent management, Marketing Cloud consent, or custom consent objects that use Field Audit Trail for AI-specific consent requirements.

*   **Enable granular consent per AI use case.** Enable consent per AI use case instead of using a blanket AI consent. Customers may consent to Einstein product recommendations but decline AI-driven credit decisions. Enable Field Audit Trail on Consent objects for long-term retention and meeting regulatory requirements. Design custom Consent objects with fields that track:
    *   Consent Purpose (for example, Einstein Lead Scoring, Einstein Reply Recommendations, and Einstein Recommendation Builder).
    *   Consent Grant Date and Grant Method (for example, web form, API, phone, and email).
    *   Consent Withdrawal Date (if applicable).
    *   Related User or Contact ID.
*   **Use Data 360 consent for personalization.** Use Data 360 consent management for Einstein personalization features. Data 360 ingests and stores consent preferences from upstream systems via connectors that are mapped to the Privacy Data Model, which allows you to use those consent attributes as filter criteria in segmentation and at activation. Map consent attributes to specific AI use cases to enable users to opt out of personalization while also maintaining core services.
*   **Enable Marketing Cloud consent integration.** Integrate Marketing Cloud consent with Einstein Messaging Insights and AI-driven marketing features. Respect Marketing Cloud subscription status and consent in all AI-driven communications.

Provide meaningful opt-outs from AI-driven features with accessible controls that respect user preferences via human alternatives of comparable quality.

*   **Provide accessible opt-outs in profile settings.** Enable users to opt out of AI-driven interactions via accessible preference controls in Experience Cloud profile settings or My Settings in internal apps. Provide clear descriptions of what each opt-out means and the alternative experience users will receive upon opting out. Store preferences in User or Contact records.
*   **Provide persistent preference options across channels.** Store AI preferences in User or Contact records to ensure consistency across channels (for example, web, mobile, phone, and email). Query preferences consistently in all interaction flows to prevent users from needing to repeatedly re-assert preferences in different channels.

Ethical AI governance provides organizational structures that help to ensure that fairness persists as models evolve, data shifts, and use cases expand. Without governance, initial fairness efforts deteriorate as organizational attention shifts.

Establish mandatory documentation and review checkpoints before Einstein deployment. Think of this as a gate that’s as important as security reviews.

*   **Provide model documentation.** Store model documentation in Salesforce using a custom Model object, or Salesforce Files that are attached to Projects to enable searchability and version control. Document every production predictive model using:
    *   Training data demographics and known representation gaps (for customer-trained predictive models such as Einstein Discovery and Prediction Builder).
    *   Pre-deployment fairness metrics that are calculated by demographic group.
    *   Intended use cases and known inappropriate uses.
    *   Bias mitigation strategies that are applied during development.
    *   Fairness-monitoring approach and alert thresholds.
    *   Human oversight requirements and approval workflows.
    *   Review schedules and responsible parties.
    *   Regulatory considerations and compliance positioning.
*   **Enable Pre-deployment fairness gates.** Models that fail any gate testing must not proceed to production. Treat fairness gates with the same rigor as security gates. In other words, they carry the authority to block deployments. Before deploying Einstein predictions to production, you must:
    *   **Review training data audits.** All representation gaps must be analyzed and documented.
    *   **Review fairness metrics** (for example, demographic parity, equal opportunity, and disparate impact must be calculated and confirmed to meet thresholds).
    *   **Review impact assessments.** Evaluate potential harm across affected populations.
    *   **Design with human oversight.** All escalation patterns, approval workflows, and override mechanisms must be appropriately designed and tested.
    *   **Complete a transparency review.** Explanation capabilities must be validated for all decision types.
    *   **Complete documentation.** All required model documentation artifacts must be approved.

Establish review processes for high-stakes AI applications that provide cross-functional oversight and have enforcement authority.

*   **Review board composition.** Include technical experts (for example, architects and data scientists), business stakeholders (for example, product owners and operations personnel), legal counsel, privacy specialists, and representatives from affected communities (when possible). Remember, diverse perspectives surface fairness issues that homogeneous groups often miss.
*   **Review all triggers that require ethics board approval.** Define which AI use cases require ethics review before deployment:
    *   Decisions that affect employment, credit, housing, healthcare, or legal rights.
    *   Automated systems that affect more than 10,000 users or transactions per year.
    *   AI applications that use sensitive personal data, including health, financial, or demographic data.
    *   Novel use cases that don’t have an established organizational precedent.
    *   Systems where potential biases may cause significant harm to individuals or groups.
*   **Review and determine who has the authority to block deployments.** Ethics review boards should have the authority to require changes, impose monitoring conditions, or block deployments that fail to comply with ethical standards. Advisory-only reviews (without enforcement authority) may limit the effectiveness of the governance process. Document all reviews in Salesforce custom objects that track: application name, review date, concerns raised, mitigation requirements, and approval conditions.

Fairness monitoring is an ongoing process that requires continuous attention to detect bias drift as data distributions shift and user populations change.

*   **Create CRM Analytics fairness dashboards.** Build dashboards that track fairness metrics using the predictive-model decision data you capture. Monitor demographic parity, equal opportunity, disparate-impact ratios, and prediction-quality metrics by customer segments. Configure CRM Analytics alerts that trigger when fairness metrics breach defined thresholds and require an investigation.
*   **Enable custom monitoring for fairness signals.** Build custom fairness monitoring to detect signals (for example, sudden changes in decision distributions by demographic group, spikes in bias-related Case records, or degradation in model performance for specific populations).
*   **Schedule fairness audits.** Conduct comprehensive, quarterly fairness audits for high-stakes AI systems (for example, credit, employment, and healthcare), and semi-annual audits for lower-stakes systems (for example, recommendations and personalization). Audits should examine current fairness metrics, review override patterns in approval history, analyze user feedback and bias reports, and validate that governance controls remain effective.
*   **Implement incident response for fairness failures.** Establish clear processes that are documented in Salesforce Knowledge detailing how to respond when bias is detected:
    *   **Immediate:** Assess the severity and scope by querying the predictive-model decision data in CRM Analytics. If the incident is severe, suspend all automated decision-making pending an investigation.
    *   **Short-term:** Implement temporary mitigation strategies (for example, increased human oversight via adjusted confidence thresholds, feature disablement, or complete agent suspension).
    *   **Investigation:** Complete a root cause analysis (RCA) to identify how the bias entered the system or evolved. During the RCA, analyze training data, model versions, and configuration changes via the Field Audit Trail.
    *   **Remediation:** Implement a permanent fix via data correction, model retraining, or process changes.
    *   **Communication:** Notify affected users via Cases, email, or Experience Cloud announcements.
    *   **Prevention:** Process changes to prevent recurrence, and document the prevention methods in runbooks.

Use this checklist during architecture reviews, before production deployment, and periodically for ongoing assessment.

**Data Quality and Representational Fairness**

*   Make fields optional where a process can function without the data, and design downstream processes to handle missing values, so users who cannot provide information (email, SSN, street address) are not excluded.
*   Architect Name fields as a single full-name field or flexible multi-part structure that accepts mononyms, non-Latin scripts, diacritics, and long names, rather than assuming Western first/last ordering.
*   Implement permissive address validation that accepts free-form and international formats, storing addresses as entered rather than blocking record creation on a format mismatch.
*   Store communication-channel preferences in Contact records and support omnichannel alternatives (email, SMS, phone, postal, chat, voice) rather than assuming a single channel reaches all users.
*   Collect demographic data through voluntary self-identification with a “Prefer not to answer” option, stored separately under Private OWD with FLS, aggregated for reporting, and monitored via Shield Event Monitoring.
*   Audit third-party enrichment vendors for fairness testing, demographic coverage, and inference methodology before appending demographic or behavioral data to records.

**Accessibility and Inclusive Design**

*   Use Lightning Design System components, which are designed to support WCAG 2.2 AA accessibility. Keep in mind that Salesforce strives for conformance, but components still require correct usage.
*   Validate custom Lightning Web Components with screen reader testing (for example, JAWS, NVDA, and VoiceOver).
*   Ensure that complete keyboard navigation is present in Lightning pages and Experience Cloud sites without mouse dependency.
*   Verify that contrast ratios meet 4.5:1 for normal text using browser dev tools or contrast checkers.
*   Integrate sa11y or Lighthouse accessibility scanning in CI/CD pipelines that fail builds on critical issues.
*   Test Experience Cloud sites using assistive technology before public launch.
*   Verify auditory feedback by confirming that all dynamic changes (for example, error states, loading spinners, or expanding menus) are clearly announced, and the spoken content matches the visual intent of the UI.

**Fairness in Salesforce Automation**

*   Review assignment and routing rules for correlation with protected characteristics that could concentrate favorable or unfavorable outcomes in specific demographic groups.
*   Audit Flow and process-automation decision logic for bias, documenting business rules and criteria in Salesforce Knowledge or architecture decision records.
*   Evaluate validation rules for rejection rates that disproportionately affect specific data patterns or populations.
*   Analyze territory and segmentation designs for demographic correlation, documenting explicit business justification and monitoring underserved territories for equitable resource allocation.
*   Subject high-stakes Flows and assignment rules (employment, credit, service access) to the same ethics review process as AI systems, and schedule quarterly audits of automation outcomes stratified by demographics.

**AI Fairness and Bias Detection**

*   Audit Salesforce CRM data for demographic representation gaps prior to predictive model training.
*   Calculate demographic parity, equal opportunity, and disparate impact ratios per demographic group before deployment.
*   Implement fairness evaluations as a mandatory deployment gate (think of this as being equivalent to a security review).
*   Build CRM Analytics dashboards that track fairness metrics using predictive-model decision data captured with the Field Audit Trail.
*   Analyze predictive model features for proxy correlation with protected characteristics (for example, territory and account name patterns).
*   Schedule comprehensive, quarterly fairness audits for all high-stakes AI systems.

**Transparency and Auditability**

*   Surface Einstein Discovery prediction explanations at decision points in Lightning components.
*   Configure Einstein Trust Layer audit captures using retention methods that meet regulatory requirements.
*   Enable Field Audit Trail on all custom objects that store AI decision data for long-term retention.
*   Export Event Monitoring data to an external SIEM—Event Log File data via the API, and Real-Time Event Monitoring events via Platform Events—for storage that exceeds native retention, with SIEM-side write-once controls for tamper evidence.
*   Provide user-appropriate confidence communication (for example, High, Moderate, and Low) rather than raw probabilities.

**Human Oversight with Salesforce Automation**

*   Configure confidence-based escalation thresholds in Flow, and route low-confidence predictions to human review.
*   Use Salesforce approval processes for high-stakes decisions that require multi-stage review chains.
*   Integrate Agentforce and Omni-Channel routing to enable seamless escalation to human agents.
*   Provide a persistent “Connect to Human Agent” option in Agentforce interfaces to respect user agency.
*   Require documented rationale and approval history tracking for Agentforce overrides that are captured in custom fields.

**Non-Discrimination with Data Access Controls**

*   Enable Private OWD, and then grant additional access via role hierarchy and sharing rules.
*   Configure Field-Level Security to hide sensitive demographic fields from users who don’t require access.
*   Monitor object-level access events (report exports and API queries) for sensitive data via Shield Event Monitoring, and analyze them for anomalous access patterns.
*   Build reports that analyze sharing rule distributions to ensure equitable record allocation across territories.
*   Review Setup Audit Trail for unauthorized OWD, sharing rule, or FLS configuration changes.

**User Agency and Consent**

*   Design custom Consent objects using Field Audit Trail to track granular, per-use-case AI consent.
*   Integrate Data 360 or Marketing Cloud consent with Einstein personalization and Agentforce features.
*   Store AI preferences in User or Contact records to ensure consistency across channels (for example, web, mobile, and phone).
*   Provide accessible opt-outs in profile settings and human alternatives via Omni-Channel routing.
*   Query consent records in Flow before Einstein predictions or Agentforce engagement affects users.

**Ethical AI Governance**

*   Document all production predictive models, including fairness metrics and mitigation strategies; for customer-trained predictive models (such as Einstein Discovery and Prediction Builder), also document training-data demographics.
*   Establish mandatory pre-deployment fairness gates that block deployment until all fairness criteria are met.
*   Create an AI Ethics Review Board as the enforcement authority for all high-stakes AI applications.
*   Build CRM Analytics dashboards to monitor fairness metrics on a scheduled cadence via CRM Analytics alerts.
*   Define incident response procedures for fairness failures and document the process in Salesforce Knowledge.
*   Schedule quarterly fairness audits that analyze override patterns and user feedback for all high-stakes systems.

[Share your feedback on the Well-Architected Framework.](https://docs.google.com/forms/d/e/1FAIpQLScacjCLn1mSuhkcjsaqqhDZv36Dw1R-LD8QV1k-i5s5mSjeXQ/viewform)