--- title: "I built four Account record types yesterday and deleted them this morning" description: "Record types are for process. Customer kind is an attribute. The test that sent four Account record types to the bin while three on Opportunity stayed — and the two deploy errors either choice hands you." source: "https://noconaconsulting.com/blog/record-types-vs-picklists/" --- # I built four Account record types yesterday and deleted them this morning _Build log · Doorvana · Garage door manufacturing & service_ Record types are for process. Customer kind is an attribute. The test that sent four Account record types to the bin while three on Opportunity stayed — and the two deploy errors either choice hands you. Nocona Consulting · September 22, 2026 · 7 min read Yesterday I built the Account layer for [Doorvana](https://noconaconsulting.com/work): four record types — Builder, Residential, Commercial, Dealer — plus fields and a base permission set. Clean deploy to the sandbox, ten of ten. This morning I deleted all four. Nothing had gone to production, so the reversal cost source edits and nothing else. But the reasoning is the part worth writing down, because “record type or picklist?” comes up on every implementation and it is usually answered by habit. ## What record types actually buy Here is the honest ledger, measured against this specific object rather than in general. | What a record type gives you | Does Account need it? | | --- | --- | | Different page layouts per type | Yes — but Dynamic Forms does it on one layout with visibility rules | | Different picklist values per type | One field only. Thin | | Different business processes | Not applicable — Account has no business process | | Create-permission segmentation by profile | Meaningless at this headcount | One genuine need, and it has a better answer. ## What they were costing Four page layouts to maintain. A `recordTypeVisibilities` entry in every profile and every permission set. Record type assignment on every new user, forever. A record-type-aware path through lead conversion. That last set is not theoretical — the `recordTypeVisibilities` block had already produced a deploy failure the day before, because those elements must be contiguous in the file and appending a second group splits them. force-app/main/default/permissionsets/Doorvana\_Base.permissionset-meta.xml ```diff - - Account.Builder - true - - - Account.Commercial - true - - - Account.Dealer - true - - - Account.Residential - true - ``` Sixteen lines out of one permission set. Multiply by every permission set and profile the org will ever have. ## The argument that settled it A record type is single-valued. The day a production builder also starts buying wholesale product for its own crews, or a commercial general contractor is also a dealer, a record type forces **two Account records for one company**. Duplicate contacts. Split history. Reporting that counts them twice. That is a data problem, and unlike a schema problem it does not unwind. A picklist has exactly the same single-value limit today. The difference is what happens when the limit bites: a picklist is a five-minute swap to capability checkboxes. A record type, once records are assigned to it, is not. Rule of thumb Record types are for **process** — a different way of working the record. Picklists are for **attributes** — a different kind of record. If you cannot name the process that differs, you want a field. I still owe the client one question before this is fully settled: does any account wear two hats _today_? If the answer is yes, Customer Type becomes capability checkboxes rather than a single picklist, and better to know that now than after the migration. ## The same org, the opposite answer This is not an argument against record types. Three of them, on Opportunity, survived the same review without a wobble. _On Account the difference is what a customer is, so it is a field. On Opportunity the difference is how the deal is worked — two genuinely different stage sets — which no picklist can drive. Note that Commercial appears on the left and not the right: a commercial bid runs the New Construction motion, so it is a customer attribute, not a sales process._ Two business processes with genuinely different stage sets. A picklist cannot drive a sales path, cannot change what “open pipeline” means, and cannot give forecasting different categories per stage. That is a process difference, so it earns its record types. Notice where Commercial lands. It is a customer attribute, not an Opportunity type, because a commercial bid runs the New Construction motion and commercial break/fix runs the Service one. Same word, opposite answer, one object apart. ## What replaced them force-app/main/default/objects/Account/fields/Customer\_Type\_\_c.field-meta.xml ```xml Customer_Type__c Picklist true true Customer_Type ``` Two deliberate choices in that file. **Universally required.** This is the part people skip, and it is the whole reason the swap works. The one genuinely useful thing the record type picker gave you was a forced decision at creation time — you cannot make an Account without answering the question. `required` on the field, with no default value, reproduces exactly that. Drop the requirement and you get a picklist that is empty on half your records within a month. **A global value set, not a local one.** `Lead.Customer_Type__c` shares the same set, because lead conversion field mapping requires identical values on both sides. Two local picklists with matching labels will diverge the first time somebody edits one of them; a shared global value set makes that impossible. ## Two deploy errors this hands you A universally required field takes no fieldPermissions entry `Customer_Type__c` is deliberately absent from the permission set’s `fieldPermissions`. A universally required field is always visible and editable regardless of field-level security, and a deploy that tries to set FLS on one is rejected. When that error appears, remove the entry — do not try to fix its values. The second one is the reason the timing mattered. **`RecordType` deletion is not supported by the Metadata API.** There is no destructive-changes entry for it. A deployed record type can only be deactivated in source and then deleted by hand in Setup — and if records are already assigned to it, not even then until they are reassigned. Removing four record types that had only ever touched a sandbox cost nothing. The same decision three months from now, after a data migration, is a project. ## Two dependencies it creates, both hard failures 1. **`Lead.Customer_Type__c` must exist and be mapped** in Setup → Object Manager → Lead → Map Lead Fields, _before the first lead conversion_. A required field on the target object with nothing mapped to it fails every conversion. 2. **The migration must supply a customer-type column.** A blank column does not import partially — it fails the whole load. Both are the predictable cost of making a field required, and both are cheap if you write them down the same day you make the decision. ## The honest caveat Dropping the record types does not collect its own benefit. Until the Account record page is converted to Dynamic Forms — field sections with visibility filters on `Customer_Type__c`, so a Dealer account never renders the builder section — every field shows on every account, and the page is objectively worse than four tailored layouts would have been. That is the actual trade: take a short-term page-layout regression to avoid a long-term data problem that cannot be undone. Worth it here. Worth saying out loud rather than presenting the swap as free. If you are staring at the same decision on your own org, the test is the whole post: name the process that differs. If you cannot, you want a field. - Record types - Object model - Picklists - Lead conversion - Permission sets Disclosure: Doorvana's owner is also a co-owner of Nocona Consulting. This is a real engagement between two separate companies, but not an arm's-length one — and not an independent reference. [More on the work page](https://noconaconsulting.com/work). ## FAQ ### When should you use a Salesforce record type instead of a picklist? Use a record type when the records genuinely run different processes — different sales stages, different page behaviour that Dynamic Forms cannot express, or different create permissions by profile. Use a picklist when the difference is an attribute of the record rather than a different way of working it. The sharpest test is whether a record could ever be two things at once: a record type is single-valued, so a customer that is both a builder and a wholesale dealer would need two records, and that is a data problem that does not unwind later. ### Can a Salesforce record type be deleted? Not through the Metadata API. RecordType deletion is not a supported destructive change, so a deployed record type can only be deactivated in source and then deleted by hand in Setup. That asymmetry is a good reason to be conservative about adding record types in the first place, and a good reason to settle the question before anything reaches production — removing four record types that had only ever been deployed to a sandbox cost nothing but source edits and no record reassignment. ### Why does a Salesforce deploy fail when a permission set sets field-level security on a required field? A universally required field is always visible and editable regardless of field-level security, so Salesforce rejects a deploy that tries to set fieldPermissions on one. If a permission set carries a fieldPermissions entry for a universally required custom field, remove the entry rather than trying to adjust its values — the field does not need it and the deploy cannot succeed with it. ### Can Lead and Account share the same picklist values for lead conversion? Yes, and they should. Put the values in a global value set and point both Lead and Account fields at it. Lead conversion field mapping requires identical values on both sides, so two local picklists with the same labels will drift the first time someone edits one of them. A shared global value set makes drift impossible. ### Do Account record types affect lead conversion? Yes. Record types add a record-type-aware path through conversion that has to be configured and maintained, and a required field on the converted Account will fail every conversion until the matching Lead field exists and is mapped in Setup under Object Manager, Lead, Map Lead Fields. Map the field before the first conversion rather than discovering it on a live lead.