Back to Basics: Security Is an Architecture Decision

The story is built. The automation works. The custom object is ready. The Flow has been tested. Everything looks great. Then someone asks, “Who should actually have permission to use this?”

Suddenly we’re adding object permissions to a permission set, realizing there isn’t a permission set at all, or discovering that the easiest option is to add another permission to a profile that’s already assigned to hundreds of users. I’ve seen the same thing happen when it’s time to put a change set together and someone realizes that while all of the functionality is there, none of the security that allows the right users to access it is.

I’ve witnessed this pattern many times. Security is often one of the last things builders think about when they’re implementing a solution, but the problem can start much earlier than that. Sometimes security is barely discussed during discovery, only to surface later when someone finally asks who should be able to see the data, use the feature, or perform the action we’re designing.

By then, we’ve already made decisions about the solution that may have been different if security had been part of the conversation from the beginning. Security isn’t the list of permissions we add after we’ve built something. It’s one of the requirements that should help shape what we build in the first place.

Security Is an Ecosystem

Part of the problem may be how narrowly we tend to define security in the first place. Ask someone about Salesforce security and there’s a good chance the conversation will start with profiles, permission sets, object permissions, and field-level security. Those things absolutely matter, but they’re only one part of a much larger security architecture.

I think it’s more useful to start with five questions: Who can get in? Under what conditions can they get in? What can they access? What can they do? And how do we know that access is still appropriate?

Who can get in? starts with identity and authentication. Who should have access to Salesforce in the first place? That might include employees, external users, integration identities, or agents. How should each of those identities authenticate, and what controls should be required before we trust that they are who they say they are?

Under what conditions can they get in? asks us to think beyond identity. Should this user be able to log in from anywhere? At any time? How long should their session remain active? Salesforce gives us controls such as login hours, IP restrictions, trusted networks, and session settings that can be just as much a part of our security architecture as a permission set.

What can they access? gets us into the part of Salesforce security most of us immediately recognize. Which objects, fields, and records should be available? What should the ownership and sharing model look like? Which capabilities should be granted through profiles, permission sets, and permission set groups?

Then we need to ask what can they do? Being able to access something isn’t necessarily the same as being able to act on it. We need to consider system permissions, create and edit capabilities, APIs, automation, execution context, administrative capabilities, and increasingly the actions we’re making available to agents.

Finally, how do we know it’s still right? A security model can be perfectly reasonable on the day we design it and completely inappropriate three years later. People change jobs. Integrations are replaced. External users come and go. New capabilities are added. Agents are introduced. Security architecture has to include the monitoring, auditing, and recurring review that tells us whether yesterday’s access still makes sense today.

Those questions apply whether the actor is an employee, a customer logging into an Experience Cloud site, an integration, or an agent. The answers will be different, but the architecture exercise is the same.

That’s why security is an ecosystem. Authentication, access conditions, permissions, data visibility, actions, execution context, and monitoring work together. A perfectly designed permission set doesn’t mean much if the person assigned to it shouldn’t still be an active user.

And that means security architecture can’t start and end with “Which permission set do they need?”

Discover Security Before You Design It

Security requirements should be part of discovery, not something we figure out after the solution has already been designed.

Imagine you’re in a workshop and someone tells you that customer service representatives need the ability to issue refunds. It’s easy to document the process and move on: CSR opens the record, enters the refund, submits it, done.

But that’s only the functional requirement.

Does every customer service representative need to issue refunds? Are contractors included? Is there a dollar limit? Does a larger refund require approval? What customer information does someone need to see in order to process it? Are there fields they don’t need? Can they perform this action from anywhere? Are these employees working defined shifts? Does anyone outside the company participate in the process? Will an integration or agent eventually need to perform the same action?

Suddenly, a simple functional requirement has uncovered questions about identity, access conditions, data visibility, actions, and automation. That’s why those conversations need to happen while we’re discovering the process, not after we’ve already built it.

In a brand-new org, discovery gives us the opportunity to design those controls intentionally. We can identify business personas, establish baseline access, separate additional capabilities, and decide how internal users, external users, integrations, and agents should interact with the platform before access begins accumulating.

Discovery in a twelve-year-old org looks a little different. Instead of only asking “Who needs access?”, we’re also asking “Who has access today, why do they have it, and is that still true?”

The goal isn’t to immediately start taking things away. First, understand the business personas and the access they actually require. Then compare required access to actual access. That gap is where a lot of security debt lives.

Least Privilege Requires Granularity

One of the most important security principles is also one of the simplest: give someone or something the access it needs to do its job, and no more.

That’s the principle of least privilege.

It’s easy to think about least privilege at the object or field level. Maybe a user only needs Read access instead of Edit. Maybe they need access to five fields instead of twenty. Those are good questions, but least privilege applies across the entire security ecosystem.

Maybe a user doesn’t need API access. Maybe a particular job function has no business logging into Salesforce outside of defined working hours. Maybe an external user needs access to three pieces of their own information, not the internal customer record behind them. Maybe an integration only needs to read and update two objects instead of having broad access across the org.

Least privilege asks us to limit access to what is actually necessary. Granularity is what makes that possible.

Profiles, permission sets, and permission set groups are an obvious example. In an org that’s been around for a while, it’s common to find a broadly assigned profile that has accumulated more and more access over time. One project needs a new object, another needs a system permission, another needs access to a feature, and the easiest solution is to keep adding those permissions to the profile everyone already has. Eventually, the profile stops representing baseline access and starts representing the accumulation of everything anyone in that group has ever needed.

A more granular model allows us to keep baseline access small, grant specific capabilities intentionally through permission sets, and organize those capabilities into meaningful personas with permission set groups. But the same thinking applies everywhere else in the ecosystem. We can restrict when someone logs in, limit what an integration can access, give external users only the data required for their experience, and design every layer around what is actually necessary.

The question isn’t just “Can this user see this field?”

It’s “What is the minimum access this person or system needs to accomplish its purpose?”

Agents Raise the Stakes

That question becomes even more important as we introduce agents.

For years, overly broad permissions might have meant that a user technically had access to something they didn’t really need. That was already a security problem. In an agentic environment, we also have to consider what else may be able to act with that access.

Consider an employee agent operating in the context of an end user. If that user has accumulated access to objects, fields, records, or actions they don’t actually need, we’ve potentially expanded what the agent can access or act upon as well. Years of saying “just give them access” can suddenly become much more visible when something other than the human user can work with those capabilities.

The same principle applies to service agents and other autonomous experiences. We shouldn’t start by asking what access we can give an agent so we don’t run into permission problems. We should start with the agent’s purpose and ask what minimum set of data and actions it needs to accomplish that purpose.

An agent designed for one narrow business process shouldn’t automatically get access to the whole shebang.

Agents don’t make the old security principles obsolete. They make principles like least privilege and intentional access design even more important.

Security Can Shape the Architecture

Security doesn’t simply sit on top of the architecture after we’ve designed everything else. Sometimes security requirements change the solution itself.

Imagine you’re designing a new custom object related to an existing record. Should records on that object always inherit access from the parent, or should they have their own ownership and sharing model? That requirement can influence something as fundamental as whether the relationship should be master-detail or lookup.

We’ll dig much deeper into that when we talk about why sharing is an architecture decision, but the important point here is that you can’t always design the data model first and figure out security later.

The same principle extends beyond the data model. Authentication requirements can influence an Experience Cloud design. Least privilege can influence how you divide integration responsibilities and identities. Execution-context requirements can change how you build automation. Security requirements around an agent can affect which actions you expose to it in the first place.

We’re not securing a finished architecture. We’re allowing security requirements to help determine the architecture.

What About the 12-Year-Old Org?

Of course, it’s much easier to say “design security from the beginning” when you’re standing in a brand-new org. Most architects don’t always get that luxury.

Sometimes you inherit the twelve-year-old org with 47 permission sets whose names don’t make sense anymore, profiles that have been around since the original implementation, an integration user created in 2017 that nobody is completely sure is still being used, and a permission set called Temporary_Access that was created four years ago.

Welcome to architecture.

The answer isn’t to rip everything apart and start over. It’s to understand the current state and improve it intentionally.

Salesforce provides built-in tools in Setup that can help you get started, including Health Check and Portal Health Check. These can help surface configuration decisions that deserve attention and remind us about security controls that may be easy to overlook.

But a health check isn’t the same thing as a security architecture review. A setting can meet a recommended baseline while the broader access model still doesn’t make sense for the business. A health check can’t tell you why Bob in Operations still has a permission from a project six years ago, whether an integration still needs access to fifteen objects, or whether the 400 people assigned to a permission set actually need everything it contains.

That’s where the architectural work begins.

Start by understanding your users and personas. Compare what they need to what they actually have. Look at profiles, permission sets, permission set groups, powerful system permissions, sensitive data access, record access, login and session controls, integrations, connected applications, API access, automation execution context, external users, and agents. Review inactive or unnecessary access and look at the monitoring and auditing capabilities you already have available.

That’s a lot. And that’s exactly why “we need to clean up security” can sit in a backlog forever.

You Don’t Have to Fix It All at Once

A security review doesn’t have to become a six-month project before you can make anything better.

Maybe this sprint you identify everyone with the most powerful system permissions and validate whether they still need them. Next sprint, review your integration users and what each integration can actually access. Next month, look at your profiles and identify capabilities that could be separated into more intentional permission sets. After that, review inactive users, connected applications, external access, login and session settings, or agent permissions.

You can also make security part of the work you’re already doing. When a new story enters a sprint, include security requirements in its acceptance criteria. When you build a new integration, document the minimum access it requires. When you introduce an agent action, ask what data and capabilities that action exposes. When someone’s job changes, don’t only ask what new access they need. Ask what old access they no longer need.

Over time, those smaller decisions start reducing the gap between required access and actual access.

The right cadence will be different for every organization. Maybe your team reviews a slice of security debt every sprint. Maybe you schedule a focused review monthly or quarterly. Maybe a comprehensive architecture review happens annually. The important thing is that security isn’t something you configure once and assume will stay correct forever.

Businesses change. People change roles. Integrations get retired. New applications are connected. New features are implemented. Agents are introduced. Access accumulates.

So perhaps the Back to Basics question for this one isn’t “Is our security configured correctly?”

It’s:

When was the last time we checked?