--- title: "Standard object or custom object" url: "https://trailassembly.com/standard-vs-custom-object/" topic: "Architecture" published: "2026-09-13T06:30:00+00:00" updated: "2026-10-06T13:54:11+00:00" --- # Standard object or custom object **The short version:** use the standard object when the thing you are modelling is what Salesforce means by that object, even if two thirds of its fields are useless to you. Build a custom object when the standard one carries behaviour you would spend the next two years fighting. The common mistake is going custom to escape clutter, which trades a tidy page layout for a decade of features you have to build yourself. ## What you give up by going custom A custom object gets the platform basics: fields, validation, [record types](https://trailassembly.com/record-types/), sharing, history tracking, flows, triggers, custom report types. What it does not get is everything Salesforce built on top of the standard objects. - **Case machinery.** [Email-to-Case](https://trailassembly.com/email-to-case-threading/), Web-to-Case, escalation rules, entitlements and milestones, Case Teams, [Omni-Channel](https://trailassembly.com/omni-channel-routing/) routing. A custom object called Ticket gets none of it, and every one of those is weeks of work to approximate badly. - **Opportunity machinery.** Products and price books, quotes, forecasting, opportunity splits, stage-to-probability mapping, the sales path. Forecasting in particular is not something you rebuild. - **Lead machinery.** Web-to-Lead, assignment rules, and conversion into Account, Contact and Opportunity in one transaction. - **Standard report types and standard dashboards.** You can create custom report types for a custom object, and you will, for every combination anyone asks about. - **The roadmap.** New Salesforce features land on Account, Contact, Lead, Opportunity and Case first. Einstein scoring, Data Cloud mappings, AppExchange packages, the standard API surface that partners already integrate against. Your custom object is invisible to all of it. That last one is the cost people underestimate. Every release adds capability you never get back. ## What you have to live with on a standard object Standard objects are not free either, and the constraints are permanent in a way custom objects are not. **You cannot delete standard fields.** You can remove them from the layout and make them read-only. They still exist in the API, still appear in reports built by anyone with the right permission, and still confuse integrations that introspect the schema. **You cannot change built-in behaviour.** Opportunity StageName is tied to probability and forecast category. Case Status drives the Closed flag. [Lead conversion](https://trailassembly.com/lead-conversion-field-mapping/) maps fields in a way you can influence but not replace. If your process disagrees with any of that, you lose the argument. **You inherit other people’s automation.** Install three managed packages and Account has triggers you cannot read. On a custom object you own the whole transaction. **The API name is fixed.** You can relabel Account to “Organisation” in the UI. It is still Account in every query, every flow, every integration payload, forever. ## The decision rule Ask one question: would a Salesforce admin joining next year recognise this record as an Account, a Case, an Opportunity? If yes, use the standard object. Unused fields cost you a cluttered field list and nothing else, and you can hide them. If the honest answer is no, build the custom object. A record representing a physical shipment is not an Opportunity. A piece of laboratory equipment is not an Asset in the sense Salesforce means, unless it genuinely is a sold product tracked against a customer. The wrong reason to go custom is “our Cases look nothing like their Cases”. Cases vary enormously between organisations and the object absorbs that fine. The right reason is “our records need a status model that contradicts Closed, and a routing model that contradicts queues”. ## The cases that trip people up **Custom Ticket instead of Case.** Almost always wrong. Six months in, someone asks for inbound email and you are writing an Apex email service. **Custom Deal instead of Opportunity.** Usually wrong, and it is discovered when finance asks for a forecast. **Custom Project instead of Opportunity.** Usually right. Delivery work has a lifecycle, a budget and a team, and none of that maps onto a pipeline. **Person Accounts instead of a custom object for individuals.** A real decision with a real trap: enabling Person Accounts cannot be undone. ## Frequently asked **Do custom objects count against limits differently?** They count against your custom object allocation, which varies by edition, and they use the same data storage per record as standard objects. Standard objects do not consume the custom object allocation. **Can a custom object be the parent of a standard object?** No. Standard objects cannot be the detail side of a custom master-detail relationship. A lookup from a standard object to a custom object is fine. **What if I already built the custom object?** Migrating means new records, new IDs, and rewiring every relationship and integration. Do it early or accept it. **Do custom objects support activities and [field history](https://trailassembly.com/who-changed-this-field/)?** Yes, both, once you tick the boxes at object creation. Activities is easy to forget and awkward to enable later. --- Source: https://trailassembly.com/standard-vs-custom-object/ Trail Assembly — independent Salesforce write-ups.