The Salesforce Security Decision Your Data Architect Should Be Making

This is part two of a three-part series on the architectural decisions that decide whether a Salesforce migration compounds value or compounds debt. Part one made the case that the data model decision is the one nobody asks about early enough. This post is about the decision that rides right next to it, and usually loses the fight for attention, because it doesn't look like a data model decision at all.

Here is a pattern worth naming, because it shows up more often than it should. A team gets into year two of their Salesforce org and realizes their sharing model needs rework, not because the security requirements have changed (they rarely do, that fast), but because a relationship choice made quietly in year one is now driving sharing behavior the business has outgrown. When that happens, the fix is rarely a configuration change. It is a data migration: re-parenting records across relationships, rebuilding sharing rules on a live org while users keep working in it. Teams do the work when they have to. They also spend a quarter they had budgeted for new features doing it.

The interesting question is not why that happens. It is why it is preventable, and so often not prevented. The answer is almost always that in the room where the relationship was chosen, sharing was not on the agenda. It was a data modeling conversation. The sharing conversation was scheduled separately, often with the same architect wearing a different hat.

The good news is that Salesforce gives you the tools to get this right on the first pass. The platform's sharing model is one of its most powerful features, and it is wired directly into the data model by design. Understanding that wiring, and using it deliberately, is what turns the relationship choice from a schema detail into an architectural decision that pays off for years.

The decision that doesn't look like a decision

In Oracle, who can see what is a separate concern from how the data is structured. Permissions live in grants and roles. Views filter what users see. Application code enforces the business rules on top. That separation is powerful, but it comes at a cost: security is code you write, maintain, test, and audit, on top of every schema change for the life of the system.

Salesforce took a different path, and it is one of the platform's genuine strengths. Record-level security is declarative and metadata-driven. You do not write code to enforce it. You configure org-wide defaults, role hierarchies, sharing rules, and ownership, and the platform enforces the model consistently across the UI, the API, reports, mobile, and any custom code that respects the sharing keyword. That is a significant reduction in the surface area where security can go wrong, and it is a large part of why Salesforce orgs scale to thousands of users without a dedicated security engineering team.

The design choice that enables that power is the one worth understanding up front: in Salesforce, the sharing model flows through the data model. Object-level access is controlled by profiles and permission sets, which looks familiar enough. Record-level access is shaped by the structure of the objects themselves. Org-wide defaults attach to each object. Ownership attaches to each record. And the relationship type between objects tells the platform how sharing should propagate: master-detail relationships have the child inherit the parent's sharing (which is usually what you want for tightly coupled entities), and lookup relationships give the child its own sharing model (which is usually what you want when the child may need to be shared, restricted, or owned independently).

This is what makes Salesforce security so fast to configure and so durable once it is right. It is also what makes the relationship choice during schema design an architectural decision, not just a data modeling one. Choosing the relationship type is the same act as choosing how the sharing model will behave for that object, permanently. Treated deliberately, it is a two-for-one: you get the data model and the sharing behavior in the same decision. Treated as a schema choice alone, the sharing behavior is still decided, just by default rather than by design.

That is the whole argument for holding both concerns in the same conversation. The platform is already doing the integration work for you. The architect's job is to make sure the integrated decision is the right one the first time.

Why this keeps happening in mid-market

In enterprise, there is usually a named data architect and a named security architect, and if they are good, they argue in the same meetings. In mid-market, where most of the migrations actually live, there is a technical architect. One person. Wearing both hats. Sometimes wearing a third one for integrations.

That is not a problem on its own. A good technical architect can hold both concerns in their head. The problem is that even a good architect, on a compressed timeline, context-switches between hats instead of holding them simultaneously. In the data modeling workshop, the question is "what is the right relationship between these two objects?" and the answer is almost always "whichever one gives us the right behavior for rollup summaries, required fields, and cascade delete." Weeks later, in the security workshop, the question is "how do we make sure the west region cannot see east region data?" and by then the relationships are locked.

The sharing implications of the earlier decision were real. They just never got asked out loud, because the earlier meeting was not a security meeting.

The fix is not hiring a second architect. It is recognizing that in Salesforce, a data modeling workshop is a security workshop, even when it is not on the agenda. The same person can run both conversations, but they have to run them at the same time, on the same whiteboard, with both questions live on the table.

What a concrete example looks like

Take a straightforward scenario. You have Accounts, and you have a custom child object (call it Engagement__c) that tracks every meaningful interaction between a rep and a customer. Notes, commitments, next steps. The kind of object every migration spawns.

The data modeling instinct says: master-detail. It is a true parent-child. An engagement does not exist without its account. Master-detail gives you required parent, cascade delete, rollup summaries to the account, tidy schema.

The sharing instinct says: wait. Master-detail means the engagement inherits the account's sharing. If your org-wide default on Account is Public Read/Write, every rep can see every engagement on every account. If your OWD on Account is Private with sharing rules to open it up, those sharing rules automatically apply to engagements, whether that is what compliance wanted or not.

Lookup flips it. Engagement__c gets its own OWD, its own sharing rules, its own ownership. You can make engagements more restricted than accounts, or less. You lose the tidy cascade and the rollup summaries, but you gain independent control.

Neither answer is wrong in the abstract. They are answers to different questions, and the only way to make the right call is to ask both questions in the same conversation. Will the business ever want to share an account but hide specific engagements? Will compliance ever need to lock down engagement history independent of account access? If the answer to either is "plausibly, in the next five years," you do not want master-detail, even if it looks cleaner on the schema.

This is the part that does not show up in most migration plans: the relationship type you pick on day thirty is a bet on what the business will need on day one thousand. And it is a hard bet to change. Converting master-detail to lookup is doable. Doing it on a live object with tens of thousands of records and dependent sharing rules and automation is the thing that eats the quarter.

The questions to ask while the schema is still on the whiteboard

When the technical architect is designing the data model, these are the questions that belong in the same session, not the security workshop two weeks out.

None of these are security questions. They are all data model questions that happen to determine the security model. That is the whole point.

Back to the premise

The argument of this series is that the most valuable architectural decisions in a Salesforce migration are made in month one, often by people who do not realize how much weight those decisions will carry. Part one was about designing the data model for Salesforce's grain, rather than replicating the legacy schema by default. This part is the same argument at one layer of depth: the relationship choices you make while designing the schema are also the choices that shape your sharing model, your audit posture, and how gracefully the org absorbs the next reorganization.

The data model is not just the shape of your tables. In Salesforce, it is also who can see what, who owns what, and how much of your future flexibility the platform will give you back for free. That is a bigger return on a few well-framed workshops than most migration plans realize, and it is all available in the same few weeks, to the same one person doing the design.

Part three is about the other half of what gets decided in those workshops and paid for in year two: reporting, integration, and scale. The forcing functions that should be design inputs in month one, and almost never are.

Before your next sprint, pull up your object relationship diagram. For every master-detail relationship, ask: is this the right sharing behavior if the business reorganizes in three years? For every lookup, ask: are we using the independent sharing control this gives us, or leaving it on the table? These are the conversations that turn a Salesforce migration into an org that compounds value. They are exactly the conversations Aetrum exists to have.