Early in my Salesforce work, I made a mistake I now see beginners make all the time. A project needed to track companies, so I built a brand-new custom object and proudly called it “Companies.” It worked. It also meant I had thrown away years of Salesforce engineering, because there was already a perfectly good object for exactly that, with reports, automation, and integrations built to expect it. I had reinvented the wheel and made it slightly more square. Let me save you from that.
Two kinds of objects
In Salesforce, every object is either standard or custom.
A standard object comes built into the platform. Account, Contact, Opportunity, Case, Lead, and many more. Salesforce designed these, maintains them, and wires the rest of the ecosystem to work with them automatically. If you have read The Salesforce Object Model, you have already met the Account-Contact-Opportunity backbone. Those are all standard objects.
A custom object is one you create yourself to hold data that no standard object covers. You will know it instantly by its name, because Salesforce adds a __c suffix to the API name of everything custom. An object you build to track, say, equipment inspections might show up internally as Inspection__c. That little __c is the platform’s way of saying “a human added this, it did not come with the box.”
The default should be: reuse
Here is the rule I wish someone had told me on day one. Before you create a custom object, ask whether a standard object already does the job, even imperfectly.
Standard objects are not just convenient. They come pre-wired into reports, security, integrations, mobile, and countless features you would otherwise have to rebuild by hand. Choosing one is choosing years of work you do not have to do.
If you need to track organizations you do business with, that is Account. People, that is Contact. Potential deals, that is Opportunity. Support issues, that is Case. Resist the urge to rename the world. The platform, the documentation, the AppExchange, the next admin who inherits your org, all of them expect a company to live on Account. When you honor that, everything downstream gets easier.
When a custom object is the right call
Reuse is the default, not a religion. Sometimes your business has a concept that genuinely does not map to anything standard. That is exactly what custom objects are for.
A few honest signals that you really do need one:
- The data represents a thing unique to your business that no standard object describes. Property listings, course enrollments, lab samples, vehicle inspections.
- You tried to force it onto a standard object and found yourself ignoring most of that object’s fields while bolting on a dozen of your own.
- The thing has its own lifecycle, its own records, its own reporting needs, and its own relationships.
When those are true, build the custom object with confidence. That is not over-engineering, that is the platform working as designed. The whole point of Salesforce is that you can model your business, not just the generic one Salesforce imagined.
The hidden cost of over-customizing
The trap is not building custom objects. The trap is building too many, too eagerly, before you understand what standard objects already give you.
Every custom object you create is something you now own forever. You build its fields, its page layouts, its security, its automation, its reports. You maintain them as the org grows. You train people on them. And critically, third-party tools and Salesforce’s own newer features will not automatically understand your custom object the way they understand Account or Case. You are off the paved road and into the grass, carrying your own supplies.
I think of it like writing on a whiteboard versus carving into stone. A custom object feels free in the moment, like writing. But once real data and automation depend on it, it hardens into stone. Changing it later, or discovering you should have used a standard object all along, means migrating data and unwinding everything you built on top. Cheap to add, expensive to undo.
A simple test before you build
When the temptation strikes, pause and ask three questions:
- Does a standard object already represent this concept, even loosely?
- If I used that standard object, what would actually break or feel wrong?
- Is that wrongness fundamental, or am I just unfamiliar with the standard object?
More often than you would expect, the honest answer is that the standard object fits fine and you simply had not explored it yet. The discomfort was unfamiliarity, not a real mismatch.
A balanced way to think about it
Good Salesforce design is not “never build custom” and it is not “build whatever feels natural.” It is reaching for standard first, understanding it fully, and then creating custom objects deliberately for the parts of your business that truly are yours alone. The best orgs I have worked in use standard objects for the universal stuff and a handful of well-chosen custom objects for what makes that business distinct. Clean, legible, and kind to whoever comes next.
Your next step
You now have a working instinct: default to reuse, build custom when the business genuinely demands it, and respect that custom objects are a long-term commitment.
To keep building your foundation, go back to The Salesforce Object Model if relationships are still fuzzy, then move on to Fields, Picklists, and Record Types to learn how to shape the data inside whichever objects you choose. The full sequence is in Foundations.