I built four Account record types yesterday and deleted them this morning

Yesterday I built the Account layer for Doorvana: 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.

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.

-    <recordTypeVisibilities>
-        <recordType>Account.Builder</recordType>
-        <visible>true</visible>
-    </recordTypeVisibilities>
-    <recordTypeVisibilities>
-        <recordType>Account.Commercial</recordType>
-        <visible>true</visible>
-    </recordTypeVisibilities>
-    <recordTypeVisibilities>
-        <recordType>Account.Dealer</recordType>
-        <visible>true</visible>
-    </recordTypeVisibilities>
-    <recordTypeVisibilities>
-        <recordType>Account.Residential</recordType>
-        <visible>true</visible>
-    </recordTypeVisibilities>

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.

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.

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

<?xml version="1.0" encoding="UTF-8"?>
<CustomField xmlns="http://soap.sforce.com/2006/04/metadata">
    <fullName>Customer_Type__c</fullName>
    <label>Customer Type</label>
    <type>Picklist</type>
    <required>true</required>
    <valueSet>
        <restricted>true</restricted>
        <valueSetName>Customer_Type</valueSetName>
    </valueSet>
</CustomField>

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

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.