Back to Basics: Sharing Is an Architecture Decision

I’ve worked in enough Salesforce orgs to know that one of the most frustrating things a user can encounter is a record they know exists but can’t access.

Sometimes it’s a Case they need to help resolve. Sometimes it’s an Account that belongs to another team. Sometimes it’s a record they could see yesterday but suddenly can’t find today.

And when that happens, the conversation usually starts with something like, “Can we just give them access?”

Seems simple enough, right?

But the answer isn’t always as straightforward as adding someone to a public group or creating another sharing rule. Sometimes the real problem is that we never fully understood how the business needed to work together in the first place.

That’s why sharing is an architecture decision.

We’ve already talked about security in this series, and sharing is certainly part of that conversation. But I think sharing deserves a closer look because it sits at the intersection of security and business operations. It’s not simply about protecting information. It’s about making sure the right people can work together using that information.

Sharing Starts with the Business, Not the Role Hierarchy

When we’re designing a Salesforce solution, it’s tempting to start with the organizational chart. Sales reports to Sales leadership. Service reports to Service leadership. Each team has its own responsibilities, so naturally, we build a role hierarchy that looks something like the company’s reporting structure.

But reporting relationships don’t necessarily tell us who needs access to what.

Consider an Account that has an active sales opportunity, an open support case, and an upcoming renewal. The Sales team needs to understand the opportunity. The Service team needs visibility into the customer’s support history. The Customer Success team needs both to prepare for the renewal.

They may report through entirely different branches of the organization, but they’re all working toward the same customer outcome.

If we design sharing based solely on who reports to whom, we’ve missed something important about how the business actually operates.

Before we start configuring access, we need to understand how people collaborate, what information they need to do their jobs, and where the boundaries between teams really exist.

The role hierarchy is one way to support those requirements. It shouldn’t be the thing that defines them.

Ownership Is More Than a Field on a Record

Every Salesforce record has an owner, whether that’s a user or, for supported objects, a queue. But what does ownership actually mean to the business?

Does the owner represent the person responsible for the customer relationship? The person expected to take the next action? The team accountable for an outcome? Or simply whoever happened to create the record?

Those distinctions matter.

I’ve seen situations where record ownership was used to accomplish several different business objectives at once. Someone needed access to a record, so ownership was changed. Another process needed to route work, so ownership was changed again. Eventually, no one was entirely sure what the Owner field was supposed to represent.

Now imagine trying to build meaningful reporting, automation, or workload management on top of that.

When we use ownership as a workaround for access, we can create problems elsewhere in the system.

A better approach is to define what ownership means for each business process, then design the sharing model to support collaboration without compromising that definition.

Just because someone needs to see or work with a record doesn’t necessarily mean they should own it.

The Cost of “Just Give Them Access”

Sometimes the easiest way to solve a sharing problem is to create another exception.

A user can’t see a record? Add a sharing rule. A team needs access to something outside their usual responsibilities? Add them to another public group. A process encounters an access issue? Maybe we can adjust the permissions or execution context to get it working.

Each decision might seem perfectly reasonable on its own. And sometimes it is.

But what happens when we keep making these decisions without considering the bigger picture?

Over time, an organization can accumulate sharing rules, public groups, exceptions, and elevated permissions that nobody feels comfortable removing because nobody fully understands why they were created.

And this creates a different kind of technical debt.

We often talk about technical debt in terms of poorly designed automation, unnecessary customization, or complicated integrations. But an overly complicated sharing model creates its own maintenance burden. It becomes harder to troubleshoot, harder to explain, and harder to change as the business evolves.

Just because we can solve an access problem with another sharing rule doesn’t mean we should. Sometimes the better question is why we keep needing exceptions in the first place.

Not every exception is a bad thing. Businesses are complicated, and sometimes exceptions are necessary.

The question is whether those exceptions reflect intentional design or whether we’ve simply been solving the same underlying problem one access request at a time.

Too Much Access and Too Little Access Are Both Problems

Security conversations naturally focus on preventing unauthorized access. And for good reason. Sensitive information should only be available to the people who have a legitimate reason to use it.

But there’s another side to that conversation.

When people can’t access the information they need, they find other ways to get their work done.

Maybe they ask a colleague to send them a spreadsheet. Maybe they start maintaining a separate list outside Salesforce. Maybe someone creates a report and distributes it manually every week because the people who need the information can’t see the underlying records.

Suddenly, the carefully designed system of record isn’t really the system of record anymore.

We’ve created fragmented information, duplicate processes, and potentially even more security concerns than we were trying to prevent.

And the opposite can be just as problematic. When access is too broad, people may be exposed to sensitive customer information, internal business details, or records that simply aren’t relevant to their responsibilities.

A good sharing model balances protection with productivity. It gives people appropriate access to the information they need while preserving meaningful boundaries around information they shouldn’t see.

And finding that balance requires understanding the business, not just knowing which Salesforce feature to configure.

Design for Change, Not Just Today’s Organization

Organizations don’t stay the same.

Teams reorganize. Territories change. People take on new responsibilities. Business units merge. New processes introduce collaboration requirements that didn’t exist when the original implementation was designed.

A sharing model that works beautifully on day one can become incredibly difficult to maintain if every organizational change requires a complicated series of manual updates.

This is where I think architects need to challenge themselves.

Are we designing access around stable business concepts, or are we hardcoding today’s organizational structure into the platform?

For example, if access is based on someone’s responsibility for a particular region or customer segment, should we be thinking about how those responsibilities are represented in the data rather than tying everything to specific users?

If collaboration is a regular part of a business process, should that relationship be explicitly modeled instead of managed through one-off exceptions?

Salesforce gives us several ways to support these patterns. The important thing is understanding the pattern we’re trying to support before deciding which feature to use.

There’s no universal right answer. Different organizations have different requirements, and the right solution depends on understanding those requirements.

What matters is that we’re thinking beyond the initial implementation.

Good architecture should accommodate reasonable business change without requiring us to redesign the entire sharing model every time someone moves to a different department.

And Then We Introduce AI

Of course, we can’t talk about architecture these days without talking about AI.

As organizations introduce Agentforce and other AI-powered capabilities into Salesforce, the importance of a well-designed sharing model becomes even more apparent.

Think about an agent that’s expected to help a service representative understand a customer’s situation. It might need to retrieve account information, summarize previous interactions, identify related cases, or recommend next steps.

What happens if the representative doesn’t have access to the records needed to provide that context?

The agent’s response might be incomplete. It might miss an important piece of the customer’s history. And depending on how the agent and its actions are configured, the system might encounter access errors or operate with a different level of access than the person requesting the information.

This is why we can’t assume that AI automatically solves our data access problems, or that every agent execution follows exactly the same security context.

We need to understand which user context our agents and actions operate under, how access is enforced, and whether the information they’re retrieving is appropriate for the task.

A poorly designed sharing model can limit what an agent can accomplish. An overly permissive implementation can introduce entirely different risks.

The same architectural questions we’ve always needed to answer still apply. We just have another consumer of our data to consider.

Questions Worth Asking Before You Build

When I’m thinking through sharing requirements, these are some of the questions I want answered before anyone starts configuring roles, groups, or rules:

• Who needs access to this information, and why?
• What does record ownership represent in this business process?
• Where do teams need to collaborate across organizational boundaries?
• Are there records that require additional protection?
• How should access change when ownership, responsibility, or organizational structure changes?
• Can we explain the sharing model clearly enough that someone else can maintain it?
• How will this model affect automation, integrations, and AI-powered experiences?

None of these questions requires opening Salesforce Setup.

But the answers should influence almost every sharing decision we make once we get there.

Bringing It All Together

When I look at the topics we’ve explored throughout this Back to Basics series, there’s a common thread running through all of them.

Data modeling isn’t just about objects and fields. Data quality isn’t just about validation rules. Security isn’t just about permissions. Context isn’t just about documentation. Governance isn’t just about process. And sharing isn’t just about record visibility.

They’re all architecture decisions because they shape how the business operates and how well the technology can support it.

We can build incredible experiences with automation, analytics, and AI. But those experiences are only as reliable as the foundation underneath them.

And sometimes the most valuable thing an architect can do isn’t introduce another feature or build something new.

It’s ask a better question before we build anything at all.

That’s what going back to basics has always been about.