Quick Take: Over the past six months, Salesforce has been identifying and replacing certain technical terms across its products as part of a strategy to make its technology more inclusive. While these changes are still underway, Salesforce is sharing an update and key learnings as part of its larger ethics and equality efforts.

Language matters. The technical language companies choose to use in codebases and technical content have the power to drive inclusion or reinforce harmful biases. Given the power of language, we believe companies have a responsibility to ensure the language they use is respectful, inclusive, and free of bias, and to consider how to operationalize this in their products. 

One way to drive positive change in products is through the intentional use of technical terms to be more inclusive. In September 2020, we published How We’re Bringing Inclusive Language to Our Products to help our teams, partners, and customers understand the value of inclusion in technical content and code. We also shared how Salesforce was beginning to put the inclusive product language process into action through engaging our Employee Resource Groups and forming a repeatable review process in partnership with Salesforce’s Office of Equality.

Inclusion is like caring for your teeth. There is no finish line. No matter how well you clean your teeth today, over time they require more care.

Kat Holmes, SVP, Product Design and UX, Salesforce

Creating inclusive technology is an ongoing journey. Today, in the spirit of transparency and accountability, we’re sharing how we’ve worked to put our learnings into action over the last six months.

How we spot exclusion in our technical language

Content warning: The following content in this article will necessarily engage with noninclusive language that can be emotionally and intellectually challenging.

Exclusion can manifest in technical terms and content as cultural insensitivity or bias, and may unintentionally reinforce historical and institutional racism. Here are a few examples we’ve had to assess on our journey toward more inclusive technical language, and our learnings:

Avoid using color to make value judgments. Language that uses white and black or brown as metaphors for good/positive or bad/negative can reinforce implicit bias, anti-Blackness, and other forms of racism.

1. We are now using “allowlist” and “blocklist” instead of “whitelist” and “blacklist.” 
2. We are now using “blockout” and “reduced availability” instead of “blackout” and “brownout.” 

While there are many terms that use color to convey value, we’re challenging our employees and developers to think of other terms that convey the same meaning without needing to rely on color as a metaphor. 

For example, in machine learning, “white box” conveys an explainable model and “black box” is used to express an opaque or unexplainable model. Because these terms rely on color as a metaphor and can perpetuate stereotypes, we encourage developers to replace them with more inclusive terms.

Avoid perpetuating bias and harm. Language that builds on systemic biases causes harm by reinforcing those value judgments and creating negative impacts on underrepresented populations and their allies. 

For example, words like “master” and “slave” had been widely used for decades to describe server or database relationships. However, the use of “slave” in technical terminology normalizes the concept of chattel slavery and racial hierarchies, and perpetuates harm on Black people. While parts of the tech industry are now moving away from this pairing, it’s not always a simple process. 

At Salesforce, we found that the term “master” — used on its own, not accompanied by the term “slave” — is deeply embedded in our codebase and widely used in our technical content. And, we realized that when not coupled with “slave,” there are specific uses of “master” that may not be harmful, like when it is used to describe someone who has attained expert-level knowledge in a field of study (e.g., “master’s degree”).

1. We have replaced customer-facing, non-API instances of “slave” in our core content repositories. And, we’re continuing to replace customer-facing and internal instances of the term in our codebase. In alignment with our peers, we suggest using “secondary” or “follower” in its place.
2. The term “master,” when not used in relation to “slave,” is a bit more nuanced — a one-rule-fits-all approach is not possible given the many use cases and deeply ingrained use of the term in our codebases. So, we’ve offered various replacement options based on the usage of the term.

Open Image Modal

Image Modal

These are just a handful of examples of the terminology decisions we’ve made. We continue to review terms submitted by employees and take a systematic and principles-based approach to decision-making. Our Inclusive Marketing Principles provide a deeper look into our thought process around inclusive product language.

Using technology to make our products more inclusive

As a trusted digital partner to our customers, we are very aware of the role technology can play in making the world a better, more inclusive place. We’ve turned to a few technologies that have helped us scale our inclusive technical language work and ensure our principles are being put into practice time and time again.

1. In partnership with our Security team, we’ve enhanced an internal tool to scan, prioritize, and ultimately assign noninclusive terms to be replaced by engineers. Fully implemented, this tool will allow us to automate the identification process and give us real-time visibility on our progress.
2. We’re leveraging Acrolinx to help scale internal awareness and language updates in our technical content. The tool checks technical content against our list of noninclusive terms, notifies users when a noninclusive term is used, then suggests an inclusive alternative. Ultimately, the tool allows us to easily fix existing content and keeps our writers from reproducing deprecated, harmful language on an ongoing basis.

The Salesforce community of ISVs and system integrators are also partners on inclusive technical language. Salesforce’s AppExchange Technical Enablement Team has successfully deployed a plug-in to find and encourage our partners to use inclusive language in their code, and provide general technical enablement best practices along the way.

Many of our most successful AppExchange partners use the ISV Technical Enablement Plugin to help guide their development. It provides targeted enablement and best practices based on the application’s metadata while exposing applicable ISV Partner Alerts. Finding non-inclusive language within code and the user-facing text was a natural extension of the original vision.

— Stuart Bernstein, Senior Director, ISV Technical Evangelism, Salesforce

Our journey doesn’t end here. We know that creating inclusive products requires ongoing learning, investment, and intentionality. We are continuing to invest in tooling to scale our inclusive technical language efforts as part of our work developing technology that is a force for good and inclusive of all. 

We will continue to share our progress in the hopes that we’ll inspire our customers, partners, and communities to ask how their own workplaces can incorporate inclusive technical language principles into their technical content and code.

Learn more about our journey: Salesforce.com/EthicalandHumaneUse.