Briefly: before you make a structural decision in Salesforce, ask what it costs to undo. Most platform choices are cheap to reverse and a small number are effectively permanent, and the permanent ones are not always the ones that feel big at the time. Enabling a feature takes one click and can never be turned off. Renaming an object takes an afternoon and can be undone in ten minutes.
The four tiers
Free to reverse. Page layouts, list views, reports, most validation rules, most flows. Change them, watch what happens, change them back. Spend no governance effort here — requiring an approval for a list view is how you teach people to route around you.
Reversible with work. Field renames, picklist values in use, record types, sharing rules, permission set structure. Undoing means touching data or re-testing automation, but the path exists and you can estimate it.
Reversible under conditions you will violate. Master-detail to lookup, allowed only when no roll-up summaries exist. Field type changes, allowed only when the data converts. Deactivating a picklist value, easy until forty thousand records use it. These look like tier two from the configuration screen and behave like tier four once the org has been live for a year. The relationship case is covered in master-detail vs lookup.
Permanent. A short list, and worth memorising:
- Person accounts. Enabled once, never disabled. It changes the Account object permanently.
- A managed package namespace. Registered to a Dev Hub forever, and it prefixes every component you ever ship.
- Multi-currency. Enabled, never removed.
- State and country picklists. Enabling is a one-way conversion of existing text values.
- Your org’s My Domain name in practical terms, since every integration, bookmark and SSO configuration references it.
- Deleted custom fields after the retention period. The data is gone, not archived.
The question to ask in the design meeting
Not “is this the right decision” — nobody can answer that in month one. Ask: if this turns out wrong in eighteen months, what does fixing it involve? If the answer is a weekend and a data fix, choose quickly and move on. If the answer is “we cannot”, the decision deserves the time, and it deserves someone writing down why you chose what you chose.
This reframes arguments productively. Two people disagreeing about a reversible choice should stop arguing and pick one. Two people disagreeing about a permanent one should keep going until they agree, because the cost of being wrong is asymmetric.
Buying reversibility
Some designs cost more up front and keep options open. They are worth it exactly where the alternative is permanent:
- A lookup with a roll-up maintained in code rather than master-detail, when you are unsure whether the child needs independent sharing later. More work now, no conversion project later.
- An external ID on every object you load into. It makes a re-load idempotent, which turns a botched migration from an incident into a second attempt.
- A feature flag in custom metadata rather than deleting the old path. The old code stays, unreferenced, for one release. Removing it later is trivial. Recovering it is not.
- An abstraction over an integration endpoint — a Named Credential rather than a hard-coded URL, so that swapping the system behind it is a configuration change.
What you should not do is buy reversibility everywhere. An abstraction layer over something that will never change is a cost with no matching benefit, and it makes the code harder to read for the people who come after you.
Write the one-way doors down
Keep a page in the org’s documentation listing every irreversible decision made, the date, and the reason. It takes ten minutes per entry and it answers the question every new architect asks in their first month: why is it like this? The absence of that page is why so many orgs get redesigned by someone who did not know a constraint existed.
Frequently asked
Is a sandbox enough to test a one-way door? For behaviour, usually. For consequences at your data volume, no. A Partial Copy sandbox will happily let you enable something and tell you nothing about how it performs on twelve million rows.
Can Salesforce Support undo these? Some, occasionally, at their discretion, with a case and a delay. Never plan on it.
Does this apply to code? Less than you would think. Code is the most reversible thing in the org, provided it is in source control. Data model and org-level settings are where the permanence lives.
