Security Is Decided in the Data Model

The question this module answers: Which security outcomes does the data architect decide?

Who Sees the Gate Code?

Take one delivery at Steve Trucking. Tomorrow at 10 a.m., a crew brings a refrigerator to a Recipient who bought it from Redrock. The Work Order carries the Recipient’s name, phone number, address, and a delivery note: side gate, code 4417, dog in the yard.

Now count who reaches for that record. The crew, on the day of the stop. Coordinators moving tomorrow’s schedule around. Care staff answering “where’s my delivery?” Redrock’s DC manager, in the partner portal. Redrock’s integration, sending status back. The telematics system, updating the arrival time. And soon, an agent that answers the Recipient’s questions in a chat window.

Click to enlarge

Same record. Very different needs. The crew needs the gate code; Redrock’s integration never does. Redrock’s DC manager needs Redrock’s deliveries and must never see Brightwave’s. Telematics needs to write an arrival time and has no reason to read a phone number.

When people talk about Salesforce security, the conversation usually starts with profiles, permission sets, roles, sharing rules and field-level security. Those matter, and I teach a whole course on them. But as a data architect, I want you to start one step earlier. Before anybody opens Setup, ask: where did we put the data? Because by the time we get to permission sets, the data model has already made some of our security decisions for us.

The Data Model Is the Bones

I’ve said it all through this course: the data model is the bones. Security gets built on those bones, and it can only be as clean as they are.

We’ve already made a security decision at Steve Trucking, maybe without calling it one. At Checkpoint 1 we put the Recipient’s details on the Work Order instead of creating a Person Account for every Recipient. We chose that for volume and for deletion: about a million Recipients a year, whose personal data should live only as long as the delivery needs it. But look at what it did for security. Each Work Order belongs to one Retail Partner, so the Recipient’s personal data sits inside one partner’s boundary. If we’d built one shared Recipient record across all three partners, one person record would link Redrock’s deliveries to Brightwave’s, and partner isolation would be fighting the data model instead of following it.

That’s what I mean by “decided in the data model.” Where a field lives, what lives beside it, and how records relate decide which security controls are available and where they can be applied.

Three Kinds of Consumers

For this chapter, think about three kinds of consumers of data. Humans: employees, partner users, customers, administrators. Applications: integrations, middleware, batch jobs, external systems calling the API. And now agents, which retrieve information, reason across it, and invoke actions.

All three need access. They don’t need the same access. That’s the architectural problem.

For every consumer, I want three questions answered:

• Who are you? That’s identity.
• What can you see and do? That’s access.
• What did you actually do? That’s audit.

For a human, the first one is usually easy: someone signs in, and Salesforce knows which user it is. For an application, it’s a design decision: does every integration share one user, or does each get its own? For an agent, it’s a design decision too: does it act as the person talking to it, or as its own user? The depth on identity belongs to the Identity and Access course. But I can’t design data access without the answer, because I can’t decide what to give if I don’t know who, or what, is asking.

Two Kinds of Security: Structural and Record Level

Salesforce controls access in two big layers, and I want you to keep them apart. In my Sharing and Visibility class I describe them as an office with file cabinets.

Structural security gets you into the office. That’s everything about the shape of what you can use: which apps and tabs you get, which objects you can see, create, edit or delete, and which fields on those objects you can read or edit. Profiles, permission sets and permission set groups grant it. Can this person work with Work Orders at all? Can they see the gate code field? That’s structural.

Record-level security decides which file cabinets open. You’re in the HR office, but everyone shouldn’t see every file. Of all the Work Orders in the org, which ones can this person see, and can they edit them? Org-wide defaults, ownership, the role hierarchy, groups and sharing rules decide that. The next module is about the file cabinets.

Click to enlarge

You need both, and the most restrictive wins: edit on the object but read-only on the record means read-only. Now tell the problems apart. Redrock’s DC manager shouldn’t see Brightwave’s deliveries at all: that’s a record-level problem. A care agent can see the delivery but shouldn’t see the gate code: that’s a structural problem, at the field. Different problems, different controls. And if I find a design where most people can see a record but large parts of it must be hidden from different audiences, I start asking whether that object is carrying too many security contexts at once. Sometimes that’s unavoidable. Sometimes it’s the model telling us something.

Hiding a Field Isn’t Securing It

Here’s where good designs leak. Someone says, “Care agents can’t see the gate code. We took it off their page layout.” Or, with Dynamic Forms, “We put a visibility rule on it.”

That keeps it off the screen. It doesn’t keep it from the user. When I teach this, I put it simply: page layouts won’t work, because global search goes right past them, and so do list views and reports. If the user has access to the field, they can add it to a list view and see every gate code in the territory.

Field-level security is the control that actually removes access. Salesforce Help lists where field permissions restrict access: detail and edit pages, related lists, list views, reports, Experience Cloud sites and portals, synchronized and imported data, and the Salesforce APIs, among others. When a page layout and field-level security disagree, “the most restrictive field access settings of the two always applies.”

Click to enlarge

Even field-level security has edges, and I call what leaks through them data bleed:

• Files. Hide every field with field-level security, and the photo of the gate keypad attached to the record is still there for anyone who can see the record.
• Formulas. Salesforce Help warns that roll-up summary and formula fields “can also be visible to users even though they reference fields that your users can’t see.” A helpful formula called Delivery Instructions that strings the note and the gate code together hands the value right back.
• Free text. The coordinator who types “gate 4417” into the Description field to be helpful.

So when you have confidential data, pull it with field-level security, watch the files, and watch everything that copies it.

Test knowledge. Know that page layouts and Dynamic Forms visibility rules don’t secure a field: the field can still appear in list views, reports, global search and the API. Field-level security restricts access across pages, related lists, list views, reports, portals and the API, and when a page layout and field-level security differ, the most restrictive applies. Formula and roll-up summary fields can show values from fields the user can’t see.

The Hard Case: One Field, One Person

Now make it harder. Coordinators and care staff don’t need the gate code at all: leave the field off their permission sets, and the structural layer handles them. The crews are the hard part. Crews at a DC can see the day’s deliveries for their territory, so they can swap stops and cover for each other when a truck breaks down. But the gate code should go only to the crew assigned to that stop.

Look at what each layer can do. The record level decides which Work Orders a crew can see, and it’s doing its job: the crews need those records. But it opens the whole record, with every field the crew is allowed to see, so it can’t hold back one field. The structural layer decides whether crews can see the gate code field at all, and it answers once for every record they can see: grant it, and every crew in the territory sees every gate code; remove it, and the assigned crew can’t see it either.

I’ve run into this exact pattern with clients, as “show this private field only to the assigned rep,” and it’s a classic architect scenario. Each layer does its own job correctly, and neither job is “this one field, only on the deliveries you’re assigned to.” When the user interface and the existing mechanisms don’t work, there’s a very special case: a controlled door.

Nobody gets field-level security on the gate code. Instead, a small Lightning web component sits on the delivery’s page, and behind it, an Apex method that has been deliberately given more access than the user has. When someone opens the page, the method checks one thing, whether this person is on the crew assigned to this delivery, and only then returns the gate code to display. Everyone else sees an empty box.

Click to enlarge

It works, but treat it with respect, because you’ve just written code that makes a security decision:

• The elevated access must be deliberate and narrow. Since Summer ‘26 (more on that below), Apex shares and runs as the user unless the code says otherwise, so this door has to be declared on purpose. Good. Let it read one field, for one check, and nothing else.
• It’s display only. The standard edit page won’t show the component, so if the crew needs to correct the gate code, build that path too, through the same check.
• It must be tested like security, because it is: the assigned crew sees the code; another crew in the same territory, looking at the same delivery, doesn’t; neither does the care agent.

There’s a second way, and it doesn’t need a door at all: move the field. Put the gate code and the delivery note in their own record, a child of the Work Order with its own access, shared only with the assigned crew for the day of the stop. Then the platform’s record-level security does the work. That’s the next idea.

And know where the door has to open. Steve Trucking’s crews work in the Field Service mobile app, often with no signal, and Salesforce’s Mobile and Offline Developer Guide (opens in a new tab) (checked 2026-10-29) is plain about it: “Imperative Apex calls always fail when the client device is offline.” A component wired to Apex can instead “continue to provide cached values from the durable store, if available”, which means the secret is already sitting on the phone. Either way, the door is an online check. Checkpoint 2 comes back to this when it decides where the gate code lives.

Split the Data When the Security Differs

This is a technique I want every data architect to keep in reach. When a coherent group of information has a very different audience from the rest of the record, move it to its own object.

I learned this one the hard way. At a consultancy I ran years ago, we had one employee object, used for both time tracking and HR. One day I searched for a name and found I could see people’s reviews: they were attached to the employee record, and everyone who tracked time could see the employee record. We split it that week: an HR employee object, and a separate resource object that people tracked time against.

Steve Trucking has the same shape. A crew member’s Service Resource is what dispatch schedules: name, skills, territory, truck. But HR also keeps a driver’s license number, a medical certificate, drug-test results, written warnings, and the scanned documents behind them. Put those on the Service Resource and protect each field with field-level security, and you’ll get the fields right and miss the files. Give them their own object, a Crew Member HR Record, and now both layers work for you: only HR has permission to the object, and its records are private. The boundary is built into the data model.

Click to enlarge

The new object gets its own permissions, its own default access, its own sharing, its own files, potentially its own encryption decisions, and its own retention. That’s often cleaner than one big record with field-by-field protection for every audience.

This Isn’t “Always Create Another Object”

Don’t leave this module thinking sensitive field equals new object. That’s not the rule. Another object costs something: another relationship, another query, another security model, reporting across two objects, integrations and automation that now touch two places, and a user experience that has to bring them back together.

If one field has a slightly different audience, field-level security may be exactly right. If a group of fields, with their files, has a substantially different audience, separate storage gets much more interesting. The questions I ask: How different is the audience? How sensitive is the data? How many fields, and are there files? Does it have a different retention life? Do applications or agents need it? And would splitting it make the security model easier to explain and to prove? That last one usually decides it.

Relationships Are Security Architecture

Where data lives matters. So does how it’s related.

Master-detail and lookup aren’t interchangeable from a security point of view. A detail record in a master-detail relationship has no access of its own: who can see it follows the master. A lookup child keeps its own owner and its own sharing. So when we choose between them, we aren’t only deciding roll-ups, delete behavior and whether the parent is required. We’re deciding whether access is inherited or independent.

Sometimes inheritance is exactly what you want. A Work Order Line Item has no meaning outside its delivery: if you can see the delivery, you should see its lines. But hang the Crew Member HR Record off the Service Resource with master-detail, and it inherits dispatch’s access, which is the one thing we split it to avoid. That one needs a lookup and its own private access. The relationship must match the security requirement. That’s why I never choose a relationship from a feature checklist alone. The next module goes into how parents share with children, and how that differs for the account family.

Applications Shouldn’t Get Everything

The same thinking applies to integrations. I’ve seen many architectures where the integration user gets broad access because “the integration needs to work.” Which integration? What does it actually need?

Redrock’s integration sends manifests and receives status. Why would its identity be able to read Brightwave’s deliveries? If it can, partner isolation depends on Redrock’s code behaving, not on our architecture. So give each Retail Partner’s integration its own user, with access to its own partner’s data and nothing else. Salesforce provides a license for exactly this: the Salesforce Integration user license, with the Minimum Access - API Only Integrations profile, which can only sign in through the API, and permission sets that add only what that integration needs.

Salesforce’s own advice is the same: “we recommend creating and configuring one Salesforce user for every integration,” and the profile “enables and also restricts assigned users to operate via API” (Give Integration Users API Only Access (opens in a new tab), checked 2026-10-29). Least privilege doesn’t stop being useful because the consumer doesn’t have a chair and a keyboard.

Code is a consumer too. Apex classes have always been able to run without the user’s sharing (the controlled door above is one deliberate use), and for years, a class that didn’t say either way did exactly that. That changed in Summer ‘26. From API version 67.0, a class with no sharing keyword runs with sharing, and its queries and DML run in user mode; in Salesforce’s words, “bypassing sharing is now a deliberate without sharing declaration.” Existing classes keep their old behavior until they’re saved at the new version. For a data architect, the point is simple: when you review a design, ask what each piece of code is allowed to see, and expect any bypass to be written down and justified.

Neither Should Agents

An agent is useful because it can retrieve information and connect things together. That’s also exactly why we need to be deliberate about what it can reach. If the Recipient’s agent can see every Work Order, every case and every file, it can assemble an answer from pieces no single screen ever showed together. Module 4 deals with that directly.

Here, the data architect’s question is: did I structure the data so the agent can be given only what it needs? The Recipient’s agent needs one delivery. If the gate code and the delivery note live in their own record, it’s easy to give the agent the delivery without them. If they’re mixed into everything, it’s harder.

And one thing I want to be very clear about: a prompt is not a permission set. Suppose the agent’s instructions say, “Never reveal another Recipient’s address,” but the agent’s user can read every Work Order. Have we secured the data? No. We’ve asked nicely. Instructions guide an agent’s behavior inside a boundary; they aren’t the boundary. Remove the access, so the agent never receives what it should never know. Salesforce’s own Help says it plainly about agents: “Context variables tell the agent who the user is but don’t control data access.”

Audit Is the Third Question

As the number of consumers grows, the third question matters more. Someone changed the delivery address on a Work Order the night before the stop, and the refrigerator went to the wrong house. Who changed it? A coordinator? Redrock’s integration? An agent acting on a Recipient’s chat? “Something updated the record” isn’t an answer.

That’s partly why each integration gets its own user, and why an agent’s actions need to be traceable back to the agent, the action it ran and, where it matters, the person it was talking to. Then the platform’s audit tools have something meaningful to record.

The biggest of those tools, Event Monitoring, is a fire hose: logins, API calls, reports run, records viewed. Turning it on doesn’t mean you’re watching. Point the fire hose somewhere before you need it, into an analytics app or a security platform, because the log files aren’t kept forever: with Shield or the Event Monitoring add-on they’re kept for one year by default, and Salesforce says plainly that event log files “aren’t a system of record for user activity.” If the night the address changed is the night you need, you want it already stored somewhere you control.

Don’t Use Sharing to Fix a Bad Data Boundary

Salesforce gives us many ways to grant access, and that’s powerful. But sometimes we make the security model complicated because the data boundary underneath it is wrong.

If two kinds of information have fundamentally different audiences, ask whether they belong on the same record. If a child shouldn’t inherit its parent’s access, ask whether the relationship is right. If an integration only needs a narrow slice, don’t solve it with broad access. If an agent shouldn’t know something, don’t trust a sentence in its instructions.

One of my tests for any architecture is whether I can explain it. Ask, “Where are our crew members’ drug-test results?” I want to answer: “In the Crew Member HR Record. HR can see it. Dispatch can’t. No integration or agent has access.” Compare that with: “They’re spread across fourteen fields on three objects, but don’t worry, we have field-level security, a few permission sets, two sharing rules and a formula that we think is safe.” Maybe that’s sometimes necessary. But I’m suspicious of security that can only be understood through archaeology. Complexity is sometimes required. Accidental complexity isn’t.

Beyond the exam: what AI changes. Agents make the data model’s security decisions more visible, because they retrieve and combine information across many sources, quickly. Treat instructions as behavior guidance, never authorization. Enforce the real boundary through identity, access, the data’s structure, and controlled actions.

What an Architect Decides Here

• Where data lives when different kinds of information have very different audiences.
• Whether field-level security is enough, or a separate object makes a clearer and stronger boundary.
• Which relationships inherit access and which keep it independent.
• What each human, application and agent actually needs to see and change, instead of broad access for convenience.
• How identity, access and audit stay understandable as more automated consumers act on the same data.

Security Starts With the Model

Security isn’t something we sprinkle over the architecture after the data model is finished. The model has already decided where the information lives, what lives together, how records relate, which access is inherited and which can stand alone. Then we add identity, object and field permissions, record access, sharing, encryption and auditing. Those mechanisms matter, and the next module goes through record access. But they all operate on the structure we gave them.

So before asking how do I secure this field?, ask the more architectural question: did I put this data in the right place to secure it well? Sometimes the best security decision happens before anybody opens Setup.

Explore

• Salesforce Help: Field Permissions (opens in a new tab) (where field-level security restricts access; layouts versus field-level security; formula and roll-up fields), checked 2026-11-01.
• Salesforce Help: Agent Execution Context and Data Access by Type (opens in a new tab), checked 2026-11-01.
• Salesforce Developers blog: The Salesforce Developer’s Guide to the Summer ‘26 Release (opens in a new tab) (June 2026; the API 67.0 sharing default), checked 2026-11-01.
• Salesforce Help: Give Integration Users API Only Access (opens in a new tab), checked 2026-11-01.
• Salesforce, Mobile and Offline Developer Guide: Understand Apex Behavior While Offline (opens in a new tab), checked 2026-11-01.
• Salesforce Developers blog: Invoke REST APIs with the Salesforce Integration User and OAuth Client Credentials (opens in a new tab) (February 2024), checked 2026-11-01.
• Salesforce, REST API Developer Guide: Using Event Monitoring (opens in a new tab) (event log file retention), checked 2026-11-01.
• Salesforce Well-Architected: Trust (opens in a new tab), checked 2026-11-01.