When There's No Share Table

Module 8 of 8 in the chapter Files, Folders, Reports and Other Data, chapter 12 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: Some objects in Salesforce have no share table at all. How do you secure them?

Everything in chapters 6 to 11 worked by writing rows into a share table. Big objects and external objects don’t have one. A big object holds more rows than the share table could keep up with. An external object doesn’t hold rows at all: it shows data that lives in another system.

So for both, the question is the same: if sharing can’t reach it, what can?

Big objects: permissions only

“A big object stores and manages massive amounts of data on the Salesforce platform.” It’s built for scale: “Hundreds of millions or even billions of records.” Salesforce lists what it’s for: a fuller view of the customer, auditing and tracking, and a historical archive. And Salesforce ships one itself, “FieldHistoryArchive,” which “stores data as part of the Field Audit Trail product” (Big Objects (opens in a new tab), Big Objects Implementation Guide, checked 2026-11-07).

Here’s the security line, in one sentence on the same page: “Big objects support only object and field permissions, not regular or standard sharing rules.”

So there are two locks. Can the user read the object? Which fields can they read? That’s it. If a user can read a big object, they can read every row in it. There’s no owner, no role hierarchy, no rule and no Private default. And since “Features like triggers, flows, processes, and the Salesforce mobile app aren’t supported on big objects,” you can’t build sharing of your own, either.

That changes how you design one. If different people must see different rows, a single big object can’t do it. Split the data into separate big objects, each with its own permission set, or keep the rows people need to share in a normal object and archive only what everyone with access may see.

External objects: the other system’s data

An external object, through Salesforce Connect, looks like a custom object, “except that they map to data stored outside Salesforce in an external data source” (External Objects in Salesforce Connect (opens in a new tab), Salesforce Help, checked 2026-11-07). Nothing is copied. Each time someone opens a record, Salesforce asks the other system.

And sharing doesn’t come with it. Under “Features Not Supported,” the same page lists “Record-level security to manage data access for external objects.” Object and field permissions still decide who can open the object at all. But for which rows, there are two answers, and they work together.

Click to enlarge

In Salesforce: restriction rules

Restriction rules work on external objects; they’re one of the few objects Salesforce lists for them (Set 6, Taking Access Away). In my class I built one on an external object of airports. I love this one because it has user-level criteria. I created a flag that says whether a user is limited to small airports, and if they were, the rule only shows airports that are small airports. It worked very nicely.

That’s the pattern: something about the user, matched to something about the row. But read the fine print (Restriction Rule Considerations (opens in a new tab), Salesforce Help, checked 2026-11-07):

Three adapters only. “Only external objects created using the Salesforce Connect: OData 2.0, OData 4.0, and Cross-Org adapters support restriction rules.” And “External objects created using the Salesforce Connect custom adapter aren’t supported.”
A filter, not a model. “Restriction rules for external objects don’t include organization-wide defaults or sharing mechanisms.”
It can cost money. “Editing or deleting a restriction rule on an external object causes an additional database call, which can result in additional billing when the external data source bills per call.” And for search, “Avoid additional charges by turning off search for external object records.”
No external IDs in the rule. “Using external IDs in record criteria isn’t supported.”

In the other system: whose credentials

Here’s the lock people forget, because it isn’t in Salesforce at all. When Salesforce asks the other system for rows, it has to log in as someone. That’s the external data source’s identity type (IdentityType Enum (opens in a new tab), Apex Reference Guide, checked 2026-11-07):

Named principal. “The credentials in the external data source definition are used to authenticate to the external system, regardless of which user is accessing the external data from your organization.”
Per user. “For queries and searches, the credentials are specific to the current user who invokes the query or search.”
Anonymous. “No credentials are used to authenticate to the external system.”

Read the first one again. With a named principal, every Salesforce user who can open the object sees whatever that one login can see in the other system. The other system’s own security sees one user. If that login is an administrator, so is everyone, as far as the other system can tell. That’s the static dashboard of module 4 again, one running user for everyone, only now it’s someone else’s database.

With per user, the other system checks each person’s own access, and its security travels with the data. The cost is that each user needs their own credentials for that system.

Test knowledge. Know that big objects support only object and field permissions, not sharing rules. Know that external objects don’t support record-level sharing, that restriction rules work on external objects from the OData 2.0, OData 4.0 and cross-org adapters, and not the custom adapter. Know the identity types, named principal and per user, and that with a named principal every user sees what that one login sees. A likely area, not a known question.

What an architect decides here

For each big object: who gets object and field permissions, knowing that’s all of its security; and whether rows that need different audiences belong in it at all.
For each external object: the adapter, and whether a restriction rule is needed and supported.
The identity type for each external data source: per user where the other system’s security should apply; a named principal only with a login limited to what every Salesforce user with access may see.
Whether search is on for external objects, and what each call costs.
Who owns the other system’s security, since part of the answer lives there.

Beyond the exam: what AI changes. An agent that reads an external object reads through the same door as its user: the same object permissions, the same restriction rules, and the same identity type. With a named principal, an agent can pull whatever that one login sees from the other system and put it in an answer. Before an agent gets access to external data, check whose credentials the other system sees. Chapter 20 covers agents.

Explore

Big Objects (opens in a new tab), Big Objects Implementation Guide (checked 2026-11-07)
External Objects in Salesforce Connect (opens in a new tab), Salesforce Help (checked 2026-11-07)
Restriction Rule Considerations (opens in a new tab), Salesforce Help (checked 2026-11-07)
IdentityType Enum (opens in a new tab), Apex Reference Guide (checked 2026-11-07)