Choose the Right Object

🌐 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 5 of 10 in the chapter Salesforce Data Architecture, chapter 3 of the Data Architect course. Each module stands on its own. Previous: Where Does This Data Live? · Next: Fields Are Architecture Too

The question this module answers: What kind of Salesforce object should this business concept become, and what do licenses allow?

One of the easiest things to do in Salesforce is create a custom object. That’s exactly why I think we create too many of them.

You’re in a requirements session and somebody says, “We need to track our distributors.” New custom object: Distributor. Done. Except I want the architect to ask a different question first: what is a distributor? It’s a company. Salesforce already has a pretty good way to represent a company. It’s called an Account. That doesn’t mean the answer is always Account. But if I have to explain why a company isn’t an Account, I want a better reason than “the business calls them distributors.”

This is where chapter 2’s logical model meets the platform, and my starting position is simple: if the business concept is a clean fit for the intended purpose of a standard object, start there.

Start With Meaning

Even when something deserves to be an object, it doesn’t automatically deserve to be a custom object. Ask what the thing actually represents. A business or organization of any form? Start with Account. A person who works with that organization? Contact. Something a customer owns or has bought? Asset. Something you’re trying to sell? Now Opportunity belongs in the conversation.

That’s why we looked to the mothership first, in module 2. Those models don’t fit every business, but we shouldn’t ignore them because building our own feels cleaner. Before New Custom Object, ask how Salesforce models this concept, what has been built around that model, and what you’d give up by replacing it.

The Clean-Fit Test

My test is one question: does this business concept cleanly fit the intended purpose of the standard object? If it does, my bias is toward the standard object.

A distributor is a company we have a relationship with, so Account is a clean fit. I don’t mind that users call one company a distributor, another a supplier, another a retail partner and another a customer. Those are business roles, and they don’t need four physical objects. Different business names don’t automatically mean different data structures. A type, a record type or a relationship can carry the difference.

The test works in the other direction too. In chapter 1 I left you with a question: a customer’s business has many delivery locations. Should each location be an Account, or a custom object?

An Account gives you a lot. You get the address fields, and everything that already expects an Account address: reports, maps, integrations. But you also get the overhead: a lot of fields, sharing, hierarchy, ownership, everything that hangs off an Account, and most of it isn’t relevant to a separate address. You’d be carrying a lot of heavy things you won’t use, just for an alternative address.

A custom object, a child of the Account, can be lightweight: just the address fields, a place we deliver to, with its own lifecycle that I can control independently.

So it’s a balance: the weight you take on against the value you get. If all I need is an address with its own lifecycle, that’s where I go custom.

Same with sub-issues on a case. If each sub-issue really is a case, worked by an agent, with its own status and service level, nest them with the Parent Case from module 2. But if it’s just a checklist item nobody works as a case, a full case carries a lot it will never use, and a simple custom child may weigh less. Not because custom is cleaner. Because the meaning is different, or the weight is wrong.

Standard Objects Come With Baggage

When you choose a standard object, you’re choosing more than its fields. You’re choosing something Salesforce’s products already understand: reporting, automation, built-in relationships, product features, AppExchange packages, and whatever Salesforce builds next. That can be enormously valuable.

Standard objects also come with opinions: existing behavior, relationships, security considerations, sometimes license requirements, and features you don’t need. So “always use standard objects” isn’t my rule. I don’t have an “always” rule. I have a bias: use the standard object when the meaning is a clean fit and the platform behavior around it helps the design rather than fights it. If I spend five years making Opportunity behave like something that isn’t a sales opportunity, I haven’t gained anything by staying standard. I’ve just made the wrong compromise in the other direction.

Asset Is a Good Example

Asset is one of the standard objects people overlook. The simplest way I can put it: it’s a thing the customer has. Maybe they bought it from us, maybe not. I still care about a competitor’s product sitting at my customer’s site, because I’m servicing it, or trying to replace it, or I need to understand their installed base. If I create Customer_Product__c without looking at Asset first, I’ve skipped an architectural question. Asset doesn’t automatically win, but it deserves to be evaluated.

Person Accounts: When Is the Person the Account?

In module 2 we met person accounts: an account and a contact in one record, for customers who are individuals. Now the decision.

My position: for B2C, it’s hard to do without them. So much comes out of the box with Accounts and Contacts that the cost and overhead are worth it. And there is a cost: about twice the storage of a business account, a switch you can’t turn off, and some external licenses can’t use them. Partner Community can’t be used with person accounts (Experience Cloud User Licenses (opens in a new tab)). So the question isn’t “do we have people in our database?” Every org has people. It’s “is the person actually the account in this business?” A Contact being a person doesn’t make it a person account. The business relationship does.

Click to enlarge

Now Let Me Complicate Everything: Licensing

So far: find the concept, look for the cleanest standard fit, go custom when the meaning doesn’t fit. Now the architect’s follow-up: who needs to use it? You can design a beautiful model and then discover half the people who need the data aren’t licensed for the objects you chose. Licenses are part of the data model.

Three Internal Licenses

Start with your own people. Inside the company, there are three license types I want every architect to know cold, because they drive what each user can see and do, and so what your data model can count on.

Sales Cloud (now Agentforce Sales). These users have the full Salesforce user license: standard CRM objects, and any standard or custom app. That’s leads, opportunities and forecasts on top of accounts and contacts, and even cases: a sales rep can see a customer’s open cases before a call. Creating and running campaigns takes one more piece, the Marketing User feature license.

Service Cloud (now Agentforce Service). The same Salesforce user license, set up for service. Cases are at the center, worked in the Service Console: the Service Cloud User feature license is what opens the Salesforce Console for Service. This is where service-level agreements live, through entitlement management and milestones, and where Knowledge comes in, which most editions buy as an add-on.

Platform (Salesforce Platform). For people who need your custom apps, not the CRM. They get accounts, contacts, reports, dashboards, documents and every custom app in the org. What they don’t get: forecasts, leads, campaigns and opportunities. It costs less, which is exactly why so many large custom apps run on it, and exactly why it can catch your data model out.

	Sales Cloud	Service Cloud	Platform
User license	Salesforce	Salesforce	Salesforce Platform
Built for	Selling	Supporting customers	Custom apps
Accounts, contacts	Yes	Yes	Yes
Leads, opportunities, forecasts	Yes	Yes	No
Cases	Yes, to see a customer’s cases	At the center, in the Service Console	No
Service-level agreements	No	Yes, entitlements and milestones	No
Custom objects and apps	Yes	Yes	Yes

Read the table the way an architect does. If a big group of users is on Platform, any design that puts their work on an Opportunity is broken before it starts. If executives need SLA numbers, the license they’re on decides whether they can see them. These three types drive behavior.

Click to enlarge

When the License Decides the Object

Opportunity is the casualty I’ve run into most. You saw it in the table: Platform users don’t get it (Standard User Licenses (opens in a new tab)), and Customer Community users can’t work with it either. So the requirement looks like an Opportunity, someone says “let’s use Opportunity,” and then I ask who needs access. If a big population is on Platform or Customer Community licenses, the license isn’t a procurement detail any more. It’s an architectural constraint, and it usually pushes the design toward a custom object.

It works upward too. In class I ask: the CEO wants pretty dashboards; Sales license or Service? A Sales user can see the sales objects and even cases, so for sales dashboards and open-case counts, Sales is fine. But the moment the executive wants SLA KPIs (how long until a case breaches its service level), that data sits in entitlements and milestones, and entitlement management needs Agentforce Service, formerly Service Cloud (Supported Editions for Service Features (opens in a new tab)). Now you’re upgrading the executives’ licenses. Listen to the business requirement, and know which license sits under the data it needs.

The Stadium

I think of licenses as seats in a stadium. Everybody’s watching the same game. If I buy the expensive seats in the middle, I can see both teams up close. If I’m up in the corner in the bleachers, the seats aren’t cushioned and I’m watching through binoculars.

That’s the external licenses, for people outside the company: customers and partners logging in to an Experience Cloud site. There are three I want you to know.

Customer Community: the bleachers. Built for large numbers of external users who need cases and knowledge: a customer checking on their support case. The seats cost about half as much and can go to enormous numbers of users. What do you lose up there? Reports, dashboards, and the share table: the role-based sharing the higher tiers get. It does work with person accounts.

Customer Community Plus: about halfway down. Salesforce describes it as the license for external users who need reports and dashboards and standard sharing: a customer who manages other people’s access, or needs to see their numbers.

Partner Community: closer still, for business-to-business, with access to sales data. Partners work leads and opportunities: they register deals, and they run campaigns with you. That’s the external seat that reaches the sales objects. One catch: it can’t be used with person accounts (Experience Cloud User Licenses (opens in a new tab)).

Click to enlarge

The mistake is designing as though everyone has the expensive ticket, then discovering at implementation that most of your users can’t get into the section where you put their data. Then you have three choices: buy different seats, move the experience, or redesign the model. All three are architecture.

How They Pay Changes the Design

There’s another question people forget: how will these users log in? External licenses come in two shapes. Member-based: you pay per user, which suits 500 partners who log in every day. Login-based: you buy a number of logins per month, which suits five million customers who log in a few times a year. Logging in more than once on the same day still counts as one login (Experience Cloud User Licenses (opens in a new tab)).

So when somebody says “we’re building a customer portal,” my next question isn’t which template. It’s: who are the customers, how many, how often do they come, what data do they need, and what are they allowed to do with it?

When the License Shapes the Model

Sometimes the license doesn’t just pick the object; it bends the whole model. Some platform licenses limit users to one custom app of up to ten custom objects (Lightning Platform – One App, for example; Standard User Licenses (opens in a new tab)).

On an early project, for a large professional-services and construction company, we had to build something like LinkedIn for the whole workforce: everyone’s jobs, skills, certifications, languages and projects, so they could find the bridge builder certified in a given country. Without a limit, I’d have built a user-job, user-skill, user-certification, user-language and user-project object, plus reference lists of certifications and projects. Under a ten-object license, and told not to burn them all, that wasn’t possible. So it became name-that-tune: how few objects can I build this with? The answer was two. One reference object, with a record type for each kind of list (job, skill, certification, language, project), and one user attribute object, with matching record types, pointing at it.

It wasn’t the optimal model. It was a pain to report on, and I’d have preferred it cleaner. But that’s what the license allowed. I call these Swiss army knife objects: keep the pattern in your back pocket, and when the limits leave no room, break glass and go to record-type separation. Just know what you’re trading. Different permissions per record type can force you to split the object anyway.

People Aren’t the Only Users Any More

One more licensing question has become important: what about the things that aren’t people? Integrations have identities. Agents have identities. Salesforce now has a Salesforce Integration license for system-to-system integrations: API-only, not for humans, with five included in each Enterprise, Unlimited and Performance Edition org (Standard User Licenses (opens in a new tab)). So don’t just ask which users need access. Ask which identities need access: a person, a customer, a partner, an integration, an agent. And then what each one needs to see and do.

Beyond the exam: what AI changes. As agents become another consumer and creator of data, object choice and licensing aren’t only about human screens. Know which identity the agent runs as, what that identity can reach, and whether the model puts the data it needs behind an object or permission it can’t use.

Steve Trucking: An Easy One and a Hard One

Steve Trucking works with Retail Partners. What is a Retail Partner? A business. Easy: Account. I don’t create Retail_Partner__c because somebody used the word “partner.”

Now the Recipient, the person receiving the refrigerator. Contact? Person account? Something else? A million new Recipients a year, who are the Retail Partners’ customers, not ours. That’s exactly the kind of question where I don’t want to jump to an object before I understand the relationship, the access and the scale. We’ll decide it at the Part 1 checkpoint.

What an Architect Decides Here

• Whether a business concept cleanly fits the intended purpose of a standard object, or whether its meaning or weight is different.
• Whether different business labels are different entities or just different roles of the same one.
• Whether every person, external user, integration and agent that needs the data can reach the chosen object under the planned licenses.
• How the population and login pattern (member-based or login-based) shape the license and the model.
• When a license limit justifies a less-than-optimal model, and what that trade costs in reporting and permissions.

The point isn’t that standard objects are good and custom objects are bad. It’s that the choice has consequences, and sometimes it isn’t decided by the noun at all, but by the people, and the machines, who need to use it.

Explore

• Salesforce Help, Standard User Licenses (opens in a new tab), checked 2026-10-02, re-checked 2026-10-12: Platform users aren’t entitled to forecasts, leads, campaigns and opportunities; one custom app of up to 10 custom objects; five Salesforce Integration licenses in each Enterprise Edition org.
• Salesforce Help, Experience Cloud User Licenses (opens in a new tab), checked 2026-10-02, re-checked 2026-10-12: Partner Community can’t be used with person accounts; Customer Community Plus for reports, dashboards and standard sharing; several logins in a day count as one.
• Salesforce Help, Supported Editions for Service Features (opens in a new tab), checked 2026-10-02, re-checked 2026-10-12: service-level agreements (entitlement management) with Agentforce Service; Knowledge an additional cost in most editions.
• Salesforce Help, Available Feature Licenses (opens in a new tab), checked 2026-10-12: Service Cloud User, “Access the Salesforce Console for Service”; Marketing User for creating and managing campaigns.