People often refer to their Salesforce configuration as “good” or “bad.” But as Jalal Iftikhar, Director of Business Systems at Intercom, asks, what exactly does “good” or “bad'' mean? Can anyone define it in technical terms? Is your bad the same as my bad?
‍
It turns out, many of us are still puzzling through these questions. Salesforce is the dominant CRM platform today because it is infinitely customizable, which means each of us may have different answers. And with so much depth, so many toggles, and such sprawling potential, an org can quickly grow convoluted. Even well-meaning teams can accidentally configure themselves into a sort of virtual prison.
‍
In this guide, we explore the subtle art of Salesforce configuration, which we define as enabling the business in a way that exceeds those individuals’ expectations, without amassing unsustainable technical debt. Along the way, we hope to answer most of your Salesforce configuration management questions.
‍
No two Salesforce orgs will ever look alike for the simple reason that no two organizations will look exactly alike. Salesforce is great because it’s customizable, and your business applications should conform to and support your unique business. As the business changes, which it will frequently, your Salesforce systems should adapt. If they adapt well, they should actually enable that change, and place you in a position of going to your bosses and saying, “Here’s how we can do that thing you’re hoping to do, using Salesforce.”
That’s why the best way to measure your current Salesforce setup is against your own past performance—not against that of other businesses that do different things. Judge your “good” or your “bad” by how your org allows your business to adapt.
‍
To understand, measure, and manage all that, we recommend nine Salesforce configuration best practices.  

‍

‍

Define what “a good Salesforce configuration” means to you

Get very clear on how you will measure your team’s success as a function of how you make the business team more effective and efficient. If you ever get into measuring what we might call “academic success”—high technical success but poor reviews from those you serve—things can get bad. Your changes may actually make Salesforce less useful, not more.
‍
Measuring your success based on the business’ success is, unfortunately, more complicated than simply looking at revenue. Revenue is a lagging indicator and one your team doesn’t have much control over. You can configure things in ways that are technically perfect and beyond reproach, but if the sales team suffers record turnover and loses most of its deals, there’s not much you can do to compensate. To weight revenue too heavily is, often, to only demoralize your team.
‍
Instead, look for measures that indicate you’re providing sales, marketing, and others everything they need to be successful such as marketing hours saved, irrelevant fields or profiles culled, and the like.
In our eyes, a good Salesforce configuration is:

• A source of efficiency, effectiveness, and innovation for the business
• Manageable with your current team’s size
• Elegantly simple, with few unnecessary parts
• Frequently pruned of unnecessary fields and objects
• Well-documented
  ‍

Never customize when you can more easily configure

Apex code, aka customization, has a valued place in constructing Salesforce orgs. But be careful not to apply it too liberally. As a rule of thumb, try to fix or configure something using a flow first, especially if it’s easily created within the UI or will need to be updated by non-code users.
‍
Standard (non-custom-coded) functionality naturally benefits from Salesforce’s large research and UX teams, who improve them over three release cycles each year. Something you custom code will tend to fall behind, as it’s up to you to keep pace and improve them yourself.
‍
All that said, there are some instances where Apex code can reduce the maintenance burden—unlike standard functionality, you can use inline comments, apply better levels of abstraction, and repeat (and perfect) design partners. But default to standard unless you have a reason to do otherwise.
‍

Note: You aren’t locked into Salesforce’s releases, either. You can use Salesforce sandboxes to beta test releases before rolling them out.
‍

Diagram before you build

Diagrams force you to think through the Salesforce setup logic and change dependencies before you build. This can save a lot of time, especially when working across teams, and especially remotely. Use that diagram as a tool to politely force everyone to think things through. Invariably, having to draw it out will reveal misunderstandings and save you from having to build the thing twice.
‍
Eliya Elon, Global Head of Business Operations & Analytics at IntSights, is a big proponent of software architecture diagrams.
‍
“Draw your architecture. In trying to create it, you’ll probably realize there are gaps in your understanding. When I do this, there’ll be a spot with a big, red, transparent arrow with a big question mark that says, ‘What is the hidden process?’ That’s an area to investigate.”
‍

Note: Miro and Figma are great for this.
‍

Seek out a whole-system view of your business applications

The challenge with configuring Salesforce is that it isn’t an island. Most businesses have 800+ business applications, many of which plug into Salesforce with read/write permissions. That means rather than having to worry about just one cluster of Salesforce orgs and environments, you have to consider a vast constellation of systems which all have their own gravity and mutual influence.
‍
Without understanding your Salesforce configuration in the context of all those other top systems and their configurations, your planning, debugging, and impact analysis will never be complete enough to be reliable. (This is what Salto is built for. Try it for free.)
‍

Practice continuous integration / continuous development (CI/CD)

To our earlier point about how your business applications should evolve with the business, waiting to launch things during release windows can really slow your team down.

We recommend the software development practice of continuously developing and deploying (CI/CD) updates and changes as they arise. This of course requires a systematized (ideally automated) change release process and Salesforce deployment tools. But these will only increase the quality and relevance of your configuration changes.

Enforce strict, accessible naming conventions

Strict naming conventions that are easily understood by the uninitiated will save you an immense amount of pain later on. Naming conventions in Salesforce should be:

• Simple—where possible, use fewer and smaller words
• Sufficient—keep it simple, but not so simple that it ceases to be descriptive
• Consistent—enforce the conventions
• Accessible—new people should be able to understand them at a glance
  

One of the great challenges of Salesforce configuration is that you often don’t know the ideal way to configure something until you’ve launched and tested it. And once you’ve launched it, and users are now comfortable with this way of doing things, you have a change management mess that could involve retraining, reverting to a backup, or migrating data. In almost all cases, you’ll want to ask experienced people to weigh in on those conventions to ensure they scale.

Examples of common conventions:

• Always capitalize the names of fields or custom objects (proper nouns)
• Use formulas, such as “Object name - timing - action”
• Leave descriptions for everything
• Use prefixes in your apex classes to specify their domain (i.e cpq_opportunityTrigger)
  ‍
  

Test rigorously in sandboxes

Never simply deploy to production. Run a Salesforce test through several pre-production environments using your Salesforce sandboxes. Salesforce offers a variety of sandboxes that range in their level of realism, from Dev Sandboxes, which don’t mirror your data, up to Full Sandboxes, which are an exact replica, including customer data.
‍
Now, if you want your tests to extend beyond your Salesforce org, you’ll want to invest in an impact analysis tool that can analyze cross-application dependencies. That is, it should show you how changing a Salesforce field might affect financial reporting downstream in NetSuite or Zuora. Without that visibility, you’ll never be certain, and you’ll have to accept some amount of recurring error.
‍

Keep it simple

The best Salesforce configurations are often exceedingly simple. If you find a change difficult to explain to others, it may be a sign that you don’t yet fully understand it or its implications. Consider developing it more, asking for input, and sleeping on it. This added rigor will save you from creating complex workflows riddled with unnecessary rules that create many moving parts and more technical debt.

Continuously clean up after yourself

Make it a part of your Salesforce configuration management process to periodically—perhaps as often as monthly—run field and object utilization reports and examine whether infrequently used items better not exist. (The big challenge here is of course not just intra-Salesforce org impact analysis, but cross-impact analysis—something that Salto can help with.)
‍
All that Salesforce clutter is more harmful than you think. Abandoned profiles are a security risk. Unnecessary fields and flows can conflict with future development, confuse users, and slow the entire organization—as is often the case with overly strict Salesforce validation rules. And like any sort of cleaning, the more it piles up, the more difficult it becomes to tackle

‍

Your configurations should make the business more agile

Let’s return to the question we opened this guide with—what is a “good” or “bad” Salesforce instance? Ultimately, it’s about how the products you build using Salesforce enable the business. That’s difficult to measure, but its effects should be obvious in those processes growing more effective over time. (And if they grow more complex, they do so for a reason, like meeting SOX compliance).
‍
Your team’s effectiveness should also be obvious in whether you lead or follow the business’ direction—that is, whether you’re seen as a source of strategic innovation or as an order-taker who maintains a difficult-to-configure Salesforce mess.
‍
In top companies using Salesforce, a strong Salesforce configuration management process helps business engineers lead. They’re invited to strategic meetings, consulted on what’s new and what’s possible, and can provide a clear answer to the question, “What does a ‘good’ or ‘bad’ Salesforce setup look like?”—in terms of what it means to them.