Every Object Must Earn Its Place

In a system I reviewed, a single invoice generated records across seven Salesforce objects. Based on that system's annual transaction volume, I calculated more than a million records a year.

I was sitting in the design review looking at a highly customized invoice product, built by a certified technical architect. On paper it looked sophisticated. Every concept had its own object. Every relationship felt deliberate. The credential behind it made the room comfortable, which is most of what a credential does in a design review.

Then production gave the real review.

Storage consumption grew. The extra relationships made queries and maintenance more complex. And every change after that had to respect a relationship map that never needed to exist in the first place.

The simpler design is less impressive on a diagram. Shared objects organized by type, with Apex handling the behavior that actually varies. It fits on one page and it bores people. That is usually a good sign.

What changed when the agents showed up

For years the cost of a baroque data model was paid once, by humans, slowly. A new admin spent two weeks learning the maze. After that they had habits, and habits are free.

An agent doesn't build habits.

Unless you hide the schema behind predefined actions, an agent works through that maze on repeated runs that touch an invoice. More objects mean more schema context to load and more relationship decisions to make before it reaches the record the user actually asked about. How much more depends entirely on how the org is built; I'm not going to pretend there's a published benchmark for this, because there isn't. It's an architectural conclusion, not a Salesforce statistic.

But the direction is not really in doubt. Salesforce is pushing more of the platform toward agents; Multi-Agent Orchestration is on the What's New page, currently as a beta capability in the Summer '26 release notes. Whatever the exact numbers turn out to be, the shape of the bill is clear.

That turns yesterday's architecture choice into a recurring operating cost.

Agents will make ornamental complexity expensive.

The catch

Fewer objects aren't automatically better, and I want to be honest about what the simpler design costs.

Moving variation into Apex creates its own responsibility. Tests. Deployment discipline. Clear ownership. Code that somebody who isn't you can maintain in three years. A team that isn't set up for that will trade a bad data model for a worse code problem, and the worse code problem is harder to see coming.

Some domains genuinely need separate objects. Security boundaries are a real reason. So are distinct record lifecycles, and reporting requirements that can't be satisfied by a type field. I have built those and I would build them again.

The rule isn't "use fewer objects." The rule is that each object has to earn its place, and "it felt cleaner in the diagram" is not earning it.

How I actually judge a model now

I stopped judging Salesforce data models by how sophisticated they look in review a long time ago. I judge them by what they do at scale.

The new question I've added is how often somebody has to pay to understand the thing. That somebody used to be a person, once, at onboarding. Now it's also an agent, repeatedly, at runtime. The design that was merely annoying is becoming the design that is metered.

If you want a place to start, take your highest-volume object and count the hops. How many joins does a person, or an agent, traverse to answer the most common question anybody asks about that record? If the answer is more than two, ask what each hop is buying you. Some of them will have a real answer. Some of them exist because a diagram looked better with them.

Build the shortest honest path through the data.