The 400-Object Org: How Custom Object Sprawl Happens and What to Do About It
Part 2 of 10 in the series: What Your Salesforce Org Says About Your Company
Nobody plans for 400 custom objects. It happens one "quick fix" at a time.
I inherited an org last year with 400 custom objects. I ran my standard audit on the first day: exported the object list from Setup, checked record counts, mapped automations. The results were hard to look at.
312 of those objects had zero records. Not "low usage." Zero. Nobody had ever created a single record in them. They existed because someone asked for them, someone built them, and nobody ever went back to check whether they were being used.
The remaining 88 objects had records, but only 34 were actively referenced in reports, automations, or page layouts. The other 54 were holding historical data that nobody queried. The org's ERD looked like a conspiracy theory wall: lines connecting boxes in every direction with no discernible logic.
The client wanted to rebuild the entire org from scratch. I quoted them the rebuild: $200K-$500K over 12-18 months. Then I quoted the cleanup: $30K-$60K over 8 weeks. They chose the cleanup. Every client chooses the cleanup once they see the numbers side by side.
Why Object Sprawl Happens
Custom object sprawl follows a predictable pattern. Understanding it helps you recognize when it's happening in your own org before it reaches the 400-object stage.
The Stakeholder Request Cycle. A department head asks for a way to track something. The admin builds a custom object. Three months later, a different department head asks for a slightly different tracker. The admin builds another custom object instead of extending the first one, either because the requests came from different teams or because it felt faster to start fresh.
The Consultant Handoff Problem. A consulting firm builds 12 custom objects during a 6-week implementation. They document 3 of them in the project closeout. The rest live in their team's Jira tickets, which the client never sees. When the engagement ends, the knowledge of why those objects exist walks out the door with the consultant. The internal admin inherits objects with no context and no documentation.
The "Just in Case" Object. Someone builds an object for a use case that never materializes. A custom object for tracking vendor performance. A custom object for managing volunteer shifts. A custom object for a program that was cancelled before it launched. The object sits in the schema with zero records, adding noise to the Object Manager and confusion to anyone trying to understand the data model.
The Junction Object Explosion. Many-to-many relationships in Salesforce require junction objects. That's by design. The problem is when every relationship gets a junction object regardless of whether one is needed. I've seen orgs with junction objects connecting two objects that already had a direct lookup relationship. The junction was built because someone didn't know the lookup existed.
The Migration Artifact. Objects created during a data migration to temporarily hold data from a legacy system. "We'll delete it after the migration." Nobody deleted it. Three years later, it's still in the schema, still has the migrated records, and nobody remembers what the original system was.
How to Diagnose Object Sprawl
The audit takes 1-2 hours for a typical org. Here's the step-by-step process.
Step 1: Export Your Object Inventory
Navigate to: Setup → Object Manager
Click the gear icon and look for an option to export the object list. If your edition doesn't support direct export, you can use the Metadata API or a tool like Salesforce Inspector to pull the full list.
For a manual approach: open Object Manager, filter to custom objects only, and start a spreadsheet with columns for Object API Name, Object Label, and any notes you can gather from the object's description field.
Step 2: Check Record Counts
For each custom object, you need the current record count. The fastest method is SOQL.
Open Developer Console (Setup → Developer Console) and run:
SELECT COUNT() FROM [ObjectAPIName]
Do this for every custom object. Yes, it's tedious for 400 objects. For large inventories, you can use the Salesforce REST API to pull record counts programmatically, or use a tool like Salesforce Inspector that shows record counts in the Object Manager view.
Step 3: Check for Active Automations
For each object, check whether any Flows, triggers, or validation rules reference it.
Navigate to: Setup → Object Manager → [Object Name] → Triggers
Check for Apex triggers. Then check Flows:
Navigate to: Setup → Process Automation → Flows
Use the browser search function (Ctrl+F) to search for the object's API name across your Flow list. This is imperfect but catches most references.
For a more thorough check, search your org's metadata for references to each object's API name. Tools like Salesforce Code Analyzer or a simple VS Code search across your project metadata can identify every reference.
Step 4: Categorize Every Object
Put each custom object into one of three categories:
Active: Record count greater than zero AND referenced in Flows, triggers, reports, or page layouts. This object is doing work. Keep it.
Dormant: Record count greater than zero, but not referenced in any automation, report, or page layout. This object holds historical data. Decide whether the data needs to be retained, archived, or migrated to a different object.
Ghost: Record count equals zero. No records have ever been created. This object exists for no current purpose. It was built for a request that either changed, was abandoned, or was fulfilled differently.
Step 5: Calculate Your Ghost Object Ratio
Ghost objects divided by total custom objects = your ratio.
Below 10%: normal. Some objects are created for future use or were recently built and haven't been populated yet.
10-30%: moderate sprawl. Schedule a cleanup to remove or consolidate unnecessary objects.
Above 30%: significant sprawl. Your data model was built reactively. Every new feature is harder to build because the admin has to work around objects that serve no purpose.
78%: that was the nonprofit I mentioned. At that point, the data model itself is the obstacle.
How to Fix Object Sprawl
Ghost objects: delete them. If an object has zero records and no automations, it can be safely removed. Before deleting, check for any lookup relationships pointing to or from the object. Remove those relationships first, then delete the object. Keep a log of what you deleted and why.
Dormant objects: evaluate and archive. If the object has records but nobody uses them, decide: is this data needed for historical reporting? If yes, consider exporting the data to a backup file and archiving the records. If no, and the data has no regulatory retention requirement, you can archive the object.
Active objects: document them. If the object is in use, make sure it has a description field filled in, page layouts are cleaned up, and any related automations are documented. Active objects are your real data model. Everything else is noise.
Consolidation opportunities. Look for objects that do similar things. Two custom objects tracking two slightly different types of activities? Consolidate them into one object with a record type or picklist to distinguish the types. This reduces the number of objects, simplifies the data model, and makes reporting easier.
How to Prevent Future Sprawl
Require a Business Case for Every New Object. Before creating a custom object, answer three questions: What business problem does this solve? Can an existing object solve it with a new record type or field? Who will create and maintain records in this object? If the answer to the third question is "nobody yet," don't build it.
Annual Object Model Review. Once per year, run the full audit described above. Delete ghost objects. Evaluate dormant objects. Keep the data model lean.
Object Naming Conventions. Establish a naming convention that includes the purpose: [Department][Purpose][Type]. For example: "Fundraising_Event_Tracker" is self-documenting. "Custom_Object_47" is not. The name should tell anyone looking at the Object Manager what the object does without opening it.
Object Documentation Standard. Every custom object must have a completed Description field in Setup. The description should include: what the object tracks, who uses it, when it was created, and which team requested it. This takes 30 seconds to fill in during creation and saves hours of investigation later.
Download the Custom Object Audit Template
The companion spreadsheet includes columns for Object API Name, Record Count, Active Automations, Category (auto-calculated), and Recommended Action. Export your object list, fill in the record counts, and the template will categorize every object as Active, Dormant, or Ghost.
Your Ghost Object Ratio appears at the top of the summary tab. That single number tells you how much of your data model is intentional versus accidental.
Download the Custom Object Audit Template below. It's free.
Part 2 of 10 in the series: What Your Salesforce Org Says About Your Company.
