The God Object: One Custom Object to Rule Them All
“Created one custom object with 200 fields to handle every use case. It handled none of them well.”
What Happened
A client wanted to track Projects, Invoices, and Timesheets. I thought 'they're all related, I'll use one object with a Record Type for each.' Built a Work_Item__c object with 200+ custom fields. Project fields were blank on Invoices. Invoice fields were blank on Timesheets. Page layouts were a mess. Reports required constant filtering. Sharing rules couldn't differentiate between types. Validation rules needed Record Type checks on every rule. It was an unmaintainable monster.
The Wrong Way
// One object to rule them all: // Work_Item__c (Record Types: Project, Invoice, Timesheet) // // Fields (200+): // Project_Start_Date__c (blank on Invoices) // Project_End_Date__c (blank on Invoices) // Invoice_Amount__c (blank on Projects) // Invoice_Due_Date__c (blank on Projects) // Hours_Worked__c (blank on Projects & Invoices) // Hourly_Rate__c (blank on Projects & Invoices) // // Every validation rule: IF(RecordType = 'Project', ...) // Every page layout: 70% blank fields // Reporting: filter by Record Type EVERY time
The Right Way
// Separate objects with proper relationships: // // Project__c // - Start_Date__c, End_Date__c, Status__c // - Owner, Budget, etc. // // Invoice__c (Master-Detail → Project__c) // - Amount__c, Due_Date__c, Status__c // - Line items via junction object // // Timesheet__c (Lookup → Project__c) // - Hours_Worked__c, Hourly_Rate__c, Date__c // - Employee lookup // // Each object: clean page layouts, simple validation, // independent sharing rules, focused reports. // Record Types are for variants of the SAME thing, // not entirely different business entities.
The Lesson
Record Types are for variants of the same entity (e.g., Business Account vs Personal Account). If objects have mostly different fields, they're different objects. Don't force them together.
Enjoyed this? Get more like it.
Glen's Musings — AI, investing, and building things. Occasional. Free.
More Architecture Mistakes
5 Process Builders, 3 Flows, 2 Triggers on One Object
Stacked automations from three different consultants over two years. Nobody knew what fired when.
Read moreAnnoyingBuilding Custom Objects When Standard Objects Already Exist
Built a custom Project_Tracker__c object. Turns out Salesforce has a perfectly good Task and Event system.
Read morePainfulHardcoded Config Values Instead of Custom Metadata Types
Hardcoded thresholds, API endpoints, and business rules in Apex. Every change required a deployment.
Read more