The Assigned-Rep Field

Module 5 of 6 in the chapter Object and Field Security: What Users Can Touch, chapter 4 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: When a requirement can’t be met out of the box, how do you take it apart layer by layer, and build a solution that holds?

This module is different from the others in this chapter. It doesn’t teach one feature. It teaches what to do when a requirement can’t be met out of the box: how you take it apart layer by layer, and how you may end up with a hybrid, a solution built from several layers that each do one job.

Here’s the requirement. I’ve run into it at a client, and I still give it to every class.

The requirement. An account has a field called Special Access. It’s sensitive: think of it as truly HIPAA-level or PII data. The account also has an Assigned Rep, a lookup to a user. The business says: only the assigned rep sees Special Access. Every other rep can still see the account. They just can’t see that one field.

Try it yourself before you read on. Who can solve it for me? What are your choices?

Chapter 1, module 3 sketched the answer. This module works it through, one layer at a time. Each layer ends the same way: what it solves, where it leaks, and why you need the next one.

Why it’s hard

Most field requirements are a yes or no: does this kind of user have the field, or not? That’s field-level security, from module 2, and it’s straightforward.

This one isn’t a yes or no. It depends on the record. On one account, Maria is the assigned rep and should see the field; on the next account, she isn’t, and shouldn’t. Field-level security can’t do that, because it’s about the field on every record the user can see. And you can’t hide the whole account, because the reps who aren’t assigned still need it.

So the requirement is: the assigned rep needs the field, and the other reps still need record access.

Click to enlarge

Layer 1, out of the box: field-level security

Start with what Salesforce gives you, the base level control from module 2: give the field only to the permission sets that need it, Read for those who view it, Read and Edit for those who change it. If the rule were “account managers see Special Access, reps don’t,” you’d be done.

But the rule here is “the assigned rep on this account.” Every rep might be the assigned rep on some account. So every rep would need the field, and then every rep sees it on every account.

What it solves: who has the field at all. Where it leaks: it can’t tell one account from the next. So it’s necessary, but not enough. Keep it, and add a layer.

Layer 2, on the page: conditional visibility

The answer I usually get first is a visibility filter, and it’s a good answer. In Dynamic Forms, show Special Access only when the current user is the assigned rep. That works on the page.

But here’s the problem, from modules 3 and 4. To show the field at all, you have to give users field-level access to it, even the ones the filter hides it from. Once they have field access, they can come along, take a list view and add that field. You can’t stop them. It’s in reports, in dashboards, in global search. You can keep it off the screen, but you can’t keep it out of the other ways in.

So conditional visibility is fine for convenience, knowing that it still shows up in list views, reports and search.

What it solves: the page. Where it leaks: everywhere else. It’s not the answer for a field that truly has to be secured. Out of the box has run out, so the next layer is one you build.

Layer 3, in code: lock it down, and show it on purpose

If the field truly needs to stay on the account and be locked down, there’s one way I know to do it. Don’t grant the field-level security at all. Nobody but the admins has the field. Then build a small Lightning web component (LWC) for the account page. The LWC is the screen; the reading happens in Apex. The LWC calls a method in an Apex class: “Lightning web components can import methods from Apex classes,” and call them (Call Apex Methods (opens in a new tab), Lightning Web Components Developer Guide, checked 2026-11-01). That Apex reads Special Access on the user’s behalf, checks whether the current user is the assigned rep, and only then returns the value for the LWC to show.

Because no rep has the field, it isn’t in list views. It isn’t in reports or dashboards. It isn’t in search. It only appears in that LWC, for that one person, on that record.

Two things make this work, and both are deliberate.

• The Apex has to ask for system mode, on purpose. Since Summer ‘26, Apex database operations in code saved at API version 67.0 or later run in user mode by default: they “enforce the sharing rules, field-level security, and object permissions of the current user.” A query for a field the rep can’t see now fails to read it unless the code says otherwise, with WITH SYSTEM_MODE on the query or AccessLevel.SYSTEM_MODE on a Database method. Salesforce’s own words for why: “Database operations bypass object- and field-level security settings only if you explicitly set them to run in system mode. This requirement promotes intentionality” (Summer ‘26 release notes: Database Operations Run in User Mode by Default, Not System Mode (opens in a new tab), checked 2026-11-01). That’s good for this pattern: the one exception is written in the code where a reviewer can see it.
• The check belongs in the Apex, not the page. The Apex decides who sees the value, not the LWC and not the page. If the check is wrong, the value leaks, so test it as an assigned rep, as an unassigned rep, and as a user with no access to the account.

Click to enlarge

Test knowledge. Know the assigned-rep pattern: one sensitive field, visible only to one user, on a record other users can see. Field-level security alone can’t do it, and a visibility filter leaks through list views, reports and search. The locked-down answer is no field-level security, and an LWC whose Apex reads the field in system mode on purpose and checks the user. Know the modeling alternative too: a lookup child with a Private default owned by the assigned rep works; a master-detail child, Controlled by Parent, doesn’t. It’s a pattern architects meet again and again, in real orgs and on the architect journey. A likely area, not a known question.

Display is easy; edit is the work

Here’s the catch with Layer 3. A display LWC like this works great. Editing is harder. In my experience, a custom LWC doesn’t drop into the standard new and edit screens, so the rep can’t change Special Access in the normal edit window.

So you build editing too. The usual answer is to put the whole field in its own small edit LWC off to the side of the page: private fields, blank for everyone else, and for the assigned rep, the value and an edit button. Its Apex saves the change, in system mode on purpose, and only after checking the user again.

It’s more work, and that’s the point. The protection sits in the security layer, where it can be reviewed and tested, not on the page layout, where it can be bypassed.

In class I’ve said I wish Salesforce gave us a way to elevate a Dynamic Forms field, to say “show this field to this person on this record, without granting the field.” It doesn’t. So the LWC, and its Apex, is the tool.

Click to enlarge

Layer 3, another way, in the data model: a record of its own

There’s another way to build the third layer, and it’s a modeling answer, not a code answer. Take Special Access off the account and put it on a record of its own, a child of the account. Then protect that record with sharing, not field-level security. Whether it works depends on one decision: the kind of relationship.

A master-detail child doesn’t help. A detail record’s org-wide default is Controlled by Parent: “Users can perform actions (such as view, edit, delete) on a record on the detail side of a master-detail relationship if they can perform the same action on all associated master records” (Set Your Internal Organization-Wide Sharing Defaults (opens in a new tab), Salesforce Help, checked 2026-11-01). Every rep who can see the account can see its Special Access record. You’re back where you started.

A lookup child, with its own sharing, can. Give the child object its own org-wide default of Private: “Only users who are granted access by ownership, permissions, role hierarchy, manual sharing, or sharing rules can access the records” (same page). Make the assigned rep the owner of the account’s Special Access record. Now only the assigned rep can see it, and because it’s protected by sharing, it doesn’t show up for anyone else in list views, reports or search. There’s no LWC or Apex to build for display or edit: the assigned rep just opens the record.

Two catches.

• The role hierarchy. Under a Private default, the owner’s managers above them in the role hierarchy can see the record too. For a custom object, you can turn Grant Access Using Hierarchies off; for standard objects, Salesforce says it “can’t be modified” (Controlling Access Using the Role Hierarchy (opens in a new tab), checked 2026-11-01, chapter 1). Decide whether managers should see it, and set it on purpose.
• Keeping it in step. When the account’s assigned rep changes, the child record’s owner has to change with it. That’s automation you build and test.

So the choice is code or modeling. The LWC keeps the field on the account and puts the rule in Apex. The child record moves the field to its own object and puts the rule in sharing. Both work, if they’re built right. Part 2 of the course covers the mechanics: org-wide defaults, the role hierarchy, and how relationships share.

Click to enlarge

The answer is a hybrid

Look at what actually solves the requirement. It isn’t one feature. It’s layers, each doing one job.

• In code: field-level security takes Special Access away from every rep (Layer 1, used to take away rather than grant). A display LWC and an edit LWC put it on the account page for the assigned rep. Their Apex reads and saves in system mode on purpose, and checks the user every time (Layer 3). Tests cover the assigned rep, an unassigned rep, and a user with no access to the account.
• In the data model: field-level security still decides who can have the field at all. A lookup child with a Private default holds it, the assigned rep owns the record, Grant Access Using Hierarchies is set on purpose, and automation keeps the owner in step with the account.

Layer 2 isn’t in either answer. It’s still useful for convenience on the page, but it was never going to hold the secret.

Click to enlarge

Layer by layer: the method

This is how I take apart any requirement that out of the box can’t meet, in sharing or anywhere else.

1. State the requirement in the business’s words, and the constraint that makes it hard. Here: one person sees the field, and everyone else still sees the record.
2. Try out of the box first. Field-level security, sharing, the page. Most requirements stop here.
3. Find where it leaks. List views, reports, search, the API, files, managers in the role hierarchy.
4. Add the next layer, and only that layer: the page, then code or the data model.
5. Stop when it holds, and test it as every kind of user.
6. Write down why each layer is there, so the next person doesn’t take one away.

Choosing

• “Some kinds of users, never others”: Layer 1. Field-level security, nothing else.
• “Show it here, now, for convenience”: Layer 2, on top of Layer 1.
• “Only this person, on this record, and it truly must be secret”: a hybrid. Layer 1 takes the field away, and Layer 3 shows it on purpose: an LWC whose Apex runs in system mode on purpose, display and edit both built and tested.
• Or, for the same rule, Layer 3 in the data model: a lookup child with a Private default and the assigned rep as owner. Never a master-detail child.

What an architect decides here

• Whether a requirement can be met out of the box, and if not, which layer is added next and why.
• Whether a sensitive field’s rule is a yes or no by user, or depends on the record.
• For a record-dependent rule, whether the field truly must be secret, or convenience is enough.
• Who reviews code that runs in system mode, and that every such query is there on purpose.
• How the assigned rep edits the value, and how that’s tested.
• Whether the rule lives in code (an LWC and its Apex) or in sharing (a record of its own), and, for a record of its own, its relationship, its default, its owner and the role hierarchy setting.
• How the test plan covers the assigned rep, an unassigned rep, and a user with no access to the record.

Beyond the exam: what AI changes. A locked-down field is only as locked as every piece of code that reads it in system mode. If an agent action reuses that LWC’s Apex, the agent can read the field for anyone who asks it, unless the action checks the user the same way. When you add system-mode code, add a note for every future caller: who is allowed to see what this returns. Chapter 20 covers agents.

Explore

• Set Your Internal Organization-Wide Sharing Defaults (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Summer ‘26 release notes: Database Operations Run in User Mode by Default, Not System Mode (opens in a new tab), Salesforce (checked 2026-11-01)
• Call Apex Methods (opens in a new tab), Lightning Web Components Developer Guide (checked 2026-11-01)
• Controlling Access Using the Role Hierarchy (opens in a new tab), Salesforce Help (checked 2026-11-01)