Back to Basics: Governance Is an Architecture Decision

You can design the most beautiful Salesforce architecture in the world. Your data model makes sense, your security is thoughtfully designed, your automations are organized, and everything has a purpose.

And then people start using it.

Someone needs a new field. Another team wants to automate a process. A business stakeholder requests a change that seems simple enough. Everyone is trying to do the right thing, and each individual request probably makes perfect sense.

Fast forward a couple of years, and suddenly you have three fields that mean essentially the same thing, a handful of Flows nobody wants to touch, and a permission model that requires a detective to figure out.

What happened? Probably not one catastrophic architectural decision. More likely, hundreds of small decisions made without a shared understanding of how the platform was supposed to evolve.

That’s where governance comes in.

Throughout this Back to Basics series, we’ve talked about designing systems intentionally. But good architecture isn’t something we build once and walk away from. It needs to survive new requirements, new teams, changing priorities, and the inevitable “Can we just add one little thing?”

Good architecture establishes the foundation. Good governance ensures that foundation continues to support the business as it grows and changes.

What Is Governance, Really?

Let’s start by getting something out of the way. Governance doesn’t have to mean endless meetings, complicated approval processes, or a committee that takes three weeks to decide whether you’re allowed to create a checkbox. If that’s what comes to mind when you hear the word governance, I can understand why you might not be particularly excited about it.

At its core, governance is the framework of people, processes, and standards that guides how decisions are made, changes are introduced, and accountability is maintained throughout the life of a system.

In Salesforce, that means answering questions like:

• Who gets to make decisions about how the platform is designed?
• What standards do we follow when building something new?
• How do we evaluate changes before implementing them?
• Who owns a particular process, capability, or piece of data?
• How do we know when an existing approach needs to change?

Notice that none of those questions requires a formal committee. Governance is about making decisions intentionally and consistently, and the structure you put around those decisions should help your team, not get in its way.

And here’s something I think is particularly important: governance isn’t about protecting Salesforce from the business. It’s about making sure Salesforce continues to serve the business.

Governance vs. Operations: Direction and Execution

One of the distinctions worth making is the difference between governing a Salesforce platform and operating it. These two responsibilities are closely connected, but they aren’t quite the same thing.

Governance establishes the direction. It defines the principles, expectations, and decision-making processes that guide how the platform evolves. Operations is the day-to-day work of keeping everything running. It’s building solutions, maintaining configurations, troubleshooting issues, deploying changes, and supporting the people who rely on the platform.

For example, governance might establish a standard that custom fields need meaningful descriptions, consistent naming conventions, and clearly identified business owners. Operations puts that standard into practice when new fields are created and ensures those details remain accurate over time.

In a smaller Salesforce team, the same administrator might be responsible for both. That’s perfectly fine! We’re talking about different responsibilities, not necessarily different job titles.

Here’s how I like to think about the relationship:

Governance without operations is a collection of policies nobody follows. Operations without governance can become a collection of well-intentioned changes that slowly undermine the architecture.

You need both, and each should inform the other. Operational experience helps identify where governance is needed, while governance provides the consistency that makes day-to-day work more manageable.

This connects to something we explored in Context Is an Architecture Decision. Documenting why a field, Flow, or integration exists is valuable, but someone also needs to establish that expectation and make sure it continues to happen. Otherwise, good documentation becomes something one enthusiastic team member did a few years ago, and everyone else promptly forgot about.

Governance Starts with Decisions, Not Committees

Let’s look at a very ordinary Salesforce request. A sales team needs a new custom field on Account to capture a customer classification.

Seems simple enough, right?

From an operational perspective, the work is pretty straightforward. Create the field, configure the appropriate access, add it to the relevant pages, test it, and deploy. But before we start clicking around in Setup, there are a few other questions worth asking.

Does this classification already exist somewhere? Is it something the business has defined consistently, or does “Strategic Customer” mean something different depending on which department you ask? Who owns that definition? Will the field be used in reports, automations, integrations, or other business processes? Should we be using an existing global value set?

Maybe the answers are simple. Maybe the sales operations lead and the Salesforce admin can work through them in five minutes.

Great! That’s governance.

The point isn’t to make creating a field difficult. The point is to make sure we’re creating the right field, in the right place, for the right reason.

Think back to our earlier articles, Modeling the Business, Not the Software and Data Quality Is an Architecture Decision. Both emphasized the importance of understanding business meaning before making technical decisions. Governance helps make that understanding part of the way we work, rather than something we remember to do only when we have extra time.

And sometimes the most valuable architectural decision is deciding not to build something new.

Governance Should Grow with Your Org

One of the biggest misconceptions about governance is that it has to look the same everywhere. It doesn’t.

A Salesforce org supporting 30 users with one administrator doesn’t need the same governance structure as a global enterprise with dozens of teams, multiple integrations, and a dedicated release management function. But both need governance.

In a small org, it might be as simple as agreeing on naming conventions, identifying who can approve changes, keeping a record of important decisions, and making sure someone understands the business impact before building something new.

As the organization grows, those informal agreements might need to become documented standards. You may introduce more structured release processes, clearer ownership boundaries, regular architecture discussions, or a consistent way of evaluating competing requests.

At the enterprise level, governance often requires coordination across teams and departments. Architecture review boards, Centers of Excellence, formal decision records, and cross-functional planning may become necessary to keep everyone moving in the same direction.

The important thing is that complexity should drive the level of governance, not the other way around. I’ve seen teams get so caught up in creating the perfect process that the process itself becomes harder to manage than the platform it’s supposed to support.

We don’t need a twelve-step approval process for every checkbox. We also probably shouldn’t let five independent teams design their own approaches to customer data without talking to one another.

There’s a balance.

And just like the security considerations we discussed earlier in this series, governance should evolve as the organization matures. What works today may not be enough two years from now, and what made sense two years ago may no longer be necessary.

The goal isn’t more governance. It’s the right amount of governance.

When Governance Is Missing

The tricky thing about missing governance is that its effects often aren’t immediately obvious. The new field works. The automation runs. The integration successfully sends data somewhere. Everyone moves on to the next request.

Individually, everything looks fine.

But over time, the cracks start showing. One department creates a new object because it doesn’t realize another team already has something similar. Two automations end up updating the same field for different reasons. A permission set gets cloned because nobody is quite sure what the existing one does. A field is repurposed, and suddenly a report that worked perfectly yesterday starts returning questionable results.

Sound familiar?

These aren’t always examples of bad development. Often, they’re examples of people making reasonable decisions with incomplete information. We can have talented administrators, developers, and architects working on a platform and still end up with a mess if nobody is looking at the bigger picture.

Over time, the consequences touch nearly every architectural concern we’ve discussed in this series. Data models become inconsistent. Data quality suffers. Security gets harder to understand. The context behind existing functionality disappears.

And eventually, changes that should be simple become surprisingly complicated.

That’s architectural drift. Not necessarily because anyone deliberately ignored the architecture, but because there wasn’t a consistent way to carry architectural decisions forward.

Governance helps us recognize that drift before it becomes the next giant cleanup project.

Building Governance into Everyday Decisions

So how do we actually get started?

If you’re reading this and thinking your Salesforce org doesn’t have a governance program, don’t immediately schedule a recurring three-hour architecture review meeting. Please.

Start with the decisions your team is already making.

Identify who owns what. Someone should be able to tell you who owns an important business process, who is accountable for the quality of critical data, and who has the authority to approve meaningful changes. If nobody knows, that’s probably a good place to begin.

Establish a few useful standards. Naming conventions, field descriptions, automation design principles, and basic security expectations can go a long way. They don’t need to be perfect, but they should be understood and used consistently.

Make the reasoning visible. When you make an important architectural decision, capture why you made it. What alternatives did you consider? What business need were you addressing? What constraints influenced the approach? You don’t need a novel for every decision. Sometimes a few sentences are enough to save someone hours of investigation later.

Consider the downstream impact. Before implementing a change, ask what else might depend on the functionality you’re modifying. Reports, integrations, automations, user access, and even AI agents may rely on decisions that aren’t immediately visible from the page you’re working on.

Revisit your standards. Governance isn’t a set of rules you write once and put on a shelf. Business needs change. Salesforce capabilities change. Teams learn better ways of doing things. A healthy governance process should make room for those changes rather than treating every existing decision as permanent.

And perhaps most importantly, make it easy for people to do the right thing. If following your governance process requires twelve approvals, three spreadsheets, and a mysterious person nobody can find on Teams, people will eventually find ways around it.

Good governance should reduce friction and uncertainty, not create more of it.

Governance Is an Architecture Decision

As we get closer to the end of this Back to Basics series, I’ve been thinking about how all these topics fit together.

We’ve talked about why data models should reflect the business rather than the software. Why data quality needs to be considered when we design solutions, not after we’ve deployed them. Why security is about more than assigning permissions. And why the context behind our configurations matters just as much as the configurations themselves.

But none of those decisions happens just once. Data models evolve. Business definitions change. Security requirements grow more complicated. Teams change, and the reasoning behind an implementation can get lost along the way.

Governance is what connects those decisions across time.

It gives us a way to maintain the architectural principles we’ve established while still allowing the platform to grow, adapt, and serve new business needs.

We’re not trying to build a Salesforce org that never changes. Quite the opposite. We’re trying to build one that can change without becoming increasingly difficult to understand, maintain, or trust.

Good governance doesn’t mean saying no to every new idea. Sometimes it means asking a few better questions before saying yes. And sometimes those few questions are what keep today’s simple request from becoming tomorrow’s architectural headache.

Good architecture establishes the foundation. Good governance helps us keep building on it.