Ownership and Lifecycle

🌐 Also in 28 languages

Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Image generated with AI

Module 8 of 10 in the chapter Salesforce Data Architecture, chapter 3 of the Data Architect course. Each module stands on its own. Previous: Relationships Have Consequences · Next: Keeping Data Consistent

The question this module answers: Who owns the record, and what happens to it throughout its life?

When I look at a data model, I don’t just want to know what the objects are and how they connect. I want to know what happens to the records over time. Who creates them? Who owns them? Who can reassign them? What happens when the business relationship changes, when they’re no longer active? Should they ever be deleted, and how long do we keep them? None of that shows up on an ERD, the entity relationship diagram: the boxes and lines of chapter 2’s data model. All of it is data architecture. And on Salesforce, ownership is where the data model and the security model run into each other.

Ownership Is More Than a Name in a Field

Admins see Owner on a record and read it as a label: Bart owns this account, Lisa owns that case. It can mean that. But on Salesforce, ownership is also a platform mechanism. On objects that have an owner, the owner drives who can see the record through the role hierarchy, sharing rules, queues and reassignment. So when I ask “who owns this record?” I’m not asking whose name goes on the page. I’m asking what security and lifecycle behavior we’re attaching to it. The owner can be a user, or for some objects, custom objects, cases and leads among them, a queue, and either way the owner gets full access to the record (Understanding Sharing (opens in a new tab)).

That’s why I separate business responsibility from record ownership. Sometimes they’re the same person. Sometimes they’re not. If the business says a dispatcher is responsible for a delivery, that doesn’t automatically make the dispatcher the owner. Responsibility can live in its own field while ownership is set to support security and scale. Don’t let the two get confused just because both use the word “owner.”

The Share Table: Where Ownership Becomes Access

Some people don’t even know what the share table is. Every data architect should.

Most of the sharing for a record is kept in a related share object, Salesforce’s version of an access control list (Understanding Sharing (opens in a new tab)). Account has AccountShare, Contact has ContactShare, and a custom object gets its own: Truck__c has Truck__Share (Sharing a Record Using Apex (opens in a new tab)). Each row in it says four things:

• Which record: the parent ID.
• Who: a user, or a group (a public group, a role’s group, a territory).
• How much: Read, Edit, or All (full access).
• Why: the row cause. Owner for the owner, Rule for a sharing rule, Manual for a manual share, Team, the implicit causes Salesforce adds between an account and its children, and reasons a developer defines for Apex sharing.

In class I open Workbench and query the share table while I share a record, and you watch the rows appear and disappear. When somebody asks “why can this person see that?”, the answer is often sitting in a row, with its reason.

But not everything is in it. The organization-wide default isn’t a row. The role hierarchy isn’t stored there either: access for the people above the owner is worked out when it’s needed. And View All, Modify All, View All Data and Modify All Data skip the share table completely (Sharing a Record Using Apex (opens in a new tab)). As I put it in class: check View All and you’ve bypassed the share table.

Salesforce also shares some records for you, because of how they’re related. This is implicit sharing, and it works between an account and its children. If you can see a contact, case or opportunity, you can also read the account it belongs to. And the account owner gets access to the account’s contacts, cases and opportunities, at a level set by the owner’s role (Implicit Sharing (opens in a new tab)). In recent releases Salesforce works out some of that child access when it’s needed instead of storing it as rows, so don’t be surprised when a query of the share table doesn’t show it. I’m only giving you a hint here; the details are in Relationships and Built-In Sharing.

One more exception, for when you have a lot of external users. High-volume community users, the Customer Community licences built for thousands to millions of customers, have no role, can’t be in public groups, and can’t be given records through sharing rules or manual shares (About High-Volume Community or Site Users (opens in a new tab); Sharing Rule Considerations (opens in a new tab)). For them, the share table isn’t the answer: they get to records through sharing sets, which match a record’s account or contact to the user’s own. It’s one of the reasons those licences scale. The Sharing and Visibility course covers it in Sharing with External Users.

And remember module 7: a detail object has no share object at all. Its access comes from the master’s share object and the Sharing Setting on the master-detail field.

Why does a data architect care? Because ownership is written into this table. Every owner change, every new sharing rule, every user moving roles or groups means Salesforce adding and removing rows. At a few thousand records nobody notices. At ten million, with one user owning most of them, that’s the recalculation we’ll meet in a moment.

Test knowledge. A custom object’s share object is named Object__Share, like Truck__Share. A detail object has no share object: its access comes from the master. And when a record’s owner changes, its manual shares are removed, while Apex sharing with a developer’s own reason stays.

This is where the data model hands off to the security model, and I teach the rest in the Sharing and Visibility Architect course: Steve’s 22 Ways to Share a Record, Org-Wide Defaults, Ownership, Queues and the Role Hierarchy, Relationships and Built-In Sharing for the implicit shares, and Programmatic Sharing and Secure Code for Apex sharing reasons. In this course, chapter 12 brings it together for humans, applications and agents.

Sometimes Ownership Is Inherited

In the last module we saw that a master-detail child has no owner of its own; it follows its parent. That’s often exactly right. Does the business need a different owner for every item on a delivery? No. The delivery owns the lifecycle and the item belongs to it. This is why relationship design and ownership design happen together: when you chose master-detail, you’d already made part of the ownership decision.

Who Owns Records That Systems Create?

Now it gets interesting. A person creates an account, and maybe they become the owner. But an ERP sends 100,000 transactions overnight. Who owns those? The integration user? A queue? A regional owner worked out from the data? A system account nobody has thought about in five years? And now agents create records too.

My position: it depends on whether ownership matters for sharing. The integration user, or the agent user, is a valid user, and it can own the records. If ownership drives access in that object (through the role hierarchy or sharing rules), assign the records to the right owner: a real user, a queue, or a dedicated owner user. If it doesn’t, keeping the system user as owner may be the better choice, because then the audit trail leads straight back to whatever created the record.

Either way, decide it on purpose. An integration account that owns everything has quietly become part of your security architecture, and someone needs to know what happens if it’s ever deactivated.

Ownership Can Become a Scale Problem

Distribution matters too. Ten million records spread across thousands of owners is one shape. Ten million records owned by one user is a very different one. Salesforce calls it ownership data skew when a single user owns more than 10,000 records of an object (Ownership Data Skew (opens in a new tab)). It usually happens when someone parks everything on one user or queue: all the unassigned leads on a placeholder user, every integration record on the integration user. It’s harmless until that user moves in the role hierarchy, or in or out of a group a sharing rule depends on. Then Salesforce has to adjust a huge number of sharing entries, and you get long-running recalculations.

The guidance is practical. Spread ownership across more users where you can. If one user must own a lot, keep them out of the role hierarchy; if they need a role, put them in their own role at the top and don’t move them, and keep them out of public groups that sharing rules use (Ownership Data Skew (opens in a new tab)). The same thinking applies to the parent with too many children from the last module, parent-child skew.

So distribution is part of the physical model. Don’t just ask how many records; ask how they’re distributed. It’s another version of the Number of Zeros: not only how many zeros, but where the zeros are concentrated. Part 2 goes deep into skew; here I want you to see it coming. The Sharing and Visibility course picks it up again in Sharing at Scale.

The “Default Owner” Becomes Architecture

Here’s a pattern I see all the time. Nobody knows who should own something, so someone says, “Just assign them all to the integration user,” or “create a generic user called System.” Maybe that’s right. But don’t do it by accident. A temporary default has a habit of becoming permanent: two years later every record belongs to integration@company.com, nobody remembers why, and changing it is a project. That’s chapter 1’s Reversibility Test: before you give a million records to one owner, ask what it takes to change that later.

Reassignment Is a Lifecycle Event

Owners change. Reps leave, territories move, teams reorganize, regions get rebalanced. What depends on the owner: sharing, automation, reports, queues, escalations, integrations? If changing the owner changes who can see the record, reassignment isn’t admin cleanup. It’s a security event, and at a million records it’s an operational one too. Watch the share table when it happens: manual shares are removed when the owner changes, while Apex sharing with a developer’s own reason survives the change (Understanding Sharing (opens in a new tab)). In class I share a record with someone, change the owner, and the person loses access. The room is always surprised.

And remember that ownership isn’t the same as access. The owner isn’t the only person who needs to see a record, and Salesforce has many ways to grant access: the role hierarchy, sharing rules, teams, territories, manual and programmatic sharing. The Sharing and Visibility course goes deep on those, starting with Steve’s 22 Ways to Share a Record. The architect’s point is simpler: don’t use ownership to solve every access problem. If you’re moving owners around just so someone can see a record, you’re probably solving the wrong problem.

Creation Is Only the Beginning

A lot of data modeling stops at creation: the fields, the object, the relationship, done. But the record may live for ten years. It gets updated, changes owners, changes status and relationships, goes inactive, becomes history, may need archiving, and someday maybe deletion. Architecture isn’t just how the record is born. It’s what happens from birth to death.

Click to enlarge

Don’t Delete Just Because Something Is Old

A Retail Partner stops sending work. Delete the account? Not automatically: its deliveries, claims and billing history still matter. A truck is retired. Delete it, along with its delivery history and damage claims? The thing may no longer be active, but its data still is. So I separate inactive from gone. A retired truck can stay in the model; a former employee can still appear in audit history. The architecture has to keep the facts that matter after the operational relationship ends.

Retention Is a Business Requirement

The other side: keeping everything forever isn’t architecture either. Storage grows, reports slow down, search gets noisier, and privacy law may say some data has to go. So I want an explicit answer to how long do we keep this? “Salesforce keeps it” isn’t a retention policy.

And mostly, this is a question about transactional data. Reference data, the products, the service types, the distribution centers, doesn’t get huge, and other records point to it, so it usually stays. Customer data is in between: there may come a day when you end-of-life a customer, especially when you’re holding personal data and the reason for keeping it runs out. But the volume is in the transactions: the deliveries, the orders, the cases, the appointments, created every day, forever. That’s what grows to hundreds of millions of rows, and that’s where retention has to be explicit: maybe two years of operational data in the org, seven years of financial records somewhere, ninety days for some photos. Those are business rules, and if nobody has asked, the architect should.

I’ve said it in class for years: if you’re not archiving today, are you ever going to archive? “We’ll deal with it later” has a way of becoming an emergency project at three hundred million records. Part 2 has a whole module on archiving and purging, built on the same question.

Steve Trucking: Who Owns a Delivery?

A delivery is created from the Retail Partner’s manifest, by an integration, about 3,300 times a day. Who owns it? Not the Retail Partner; that’s a business relationship. Not the Recipient. The crew executes it, but should the record change owner every time crews swap trucks? The dispatcher? The distribution center? A queue? The integration user that created it?

Now apply this module, starting with the question that decides it: does ownership drive anyone’s access to deliveries? At Steve Trucking it doesn’t. Dispatchers see the deliveries for their distribution center, crews see the ones on their routes, and each retailer sees its own in the partner portal. None of that depends on who owns the record; it comes from the distribution center, the route and the partner.

So my answer: the integration user owns the deliveries. It’s a good example of a system user owning records on purpose:

• The audit trail is honest. Every delivery’s owner says where it came from: the manifest integration.
• Access comes from sharing, not ownership. Criteria-based sharing rules on the distribution center give each DC’s team its deliveries; partners reach theirs through the portal.
• Skew is designed out. At 3,300 a day, the integration user passes 10,000 deliveries in three days, so it’s ownership skew from day one, and that’s fine if we plan for it. The integration user has no role, so nothing above it in a hierarchy has to be recalculated, and it stays out of the public groups our sharing rules use.
• Nobody reassigns deliveries. Crews swap trucks and dispatchers change shifts, and the owner never moves, so there’s no reassignment storm and no manual shares to lose.

And write down what happens if that user is ever deactivated or replaced, because it now owns millions of records. That’s the decision the next team will need to find.

Beyond the exam: what AI changes. Agents create and change records at machine speed. If an agent creates 100,000 records under its own user, “we’ll fix the owner later” becomes skew, a sharing recalculation and a cleanup project. Decide the agent’s ownership rule before it goes live, using the same question: does ownership matter for sharing here?

What an Architect Decides Here

• Whether ownership represents business responsibility, a security mechanism, or both, and where responsibility lives if not in Owner.
• Whether records need their own owner or should inherit it from a parent.
• Who owns records that integrations and agents create, depending on whether ownership drives sharing.
• How ownership is distributed, and how to avoid ownership skew when one user must own a lot.
• When records go inactive, when they’re archived, how long they’re kept, and when deletion is right.

When you look at a physical model, don’t just ask where the data is stored. Ask who owns it today, who might own it tomorrow, and what happens when we no longer need it. Next: even with the right object, fields, relationships and owner, the data still has to stay trustworthy.

Explore

• Apex Developer Guide, Understanding Sharing (opens in a new tab), checked 2026-10-13: owners (a user, or a queue for custom objects, cases and leads) get full access; most sharing lives in a related sharing object; the role hierarchy is derived at runtime; manual shares are removed when the owner changes, Apex managed sharing is kept; the row cause values.
• Apex Developer Guide, Sharing a Record Using Apex (opens in a new tab), checked 2026-10-13: AccountShare, MyCustomObject__Share; detail objects have no sharing object; what the share object doesn’t track (OWD, role hierarchy, View All and Modify All).
• Salesforce Help, Implicit Sharing (opens in a new tab), checked 2026-10-13: access between an account and its contacts, cases and opportunities.
• Salesforce Help, About High-Volume Community or Site Users (opens in a new tab) and Sharing Rule Considerations (opens in a new tab), checked 2026-10-13: no roles, no sharing rules or manual shares; sharing sets instead.
• Sharing and Visibility Architect course: Steve’s 22 Ways to Share a Record, Org-Wide Defaults, Ownership, Queues and the Role Hierarchy, Relationships and Built-In Sharing, Programmatic Sharing and Secure Code, Sharing with External Users, Sharing at Scale.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (opens in a new tab) and Parent-Child Data Skew (opens in a new tab), checked 2026-10-02.