It Takes About Forty Seconds to Change What a Salesforce Field Means

Setup. Object Manager. Pick a field. Edit the picklist. Save.

No pull request. No review step. No changelog that anyone downstream will ever read. A Salesforce org is a production database whose schema is edited through a settings page, often by several people, often on a live system, and the platform is deliberately built to make that easy. That is a genuine strength — it is why the business can move without filing a ticket — and it is also the root of a very specific class of pain that we built the CoreModels Salesforce integration to address.

Where it hurts

Start with picklists, because that is where most teams feel it first. A picklist looks like a controlled vocabulary: Status can be Draft, Active, or Closed, and every report, routing rule, and integration downstream is written against those three values. But unless the picklist is explicitly restricted, Salesforce does not enforce the value set. An API client, a data loader, or an enthusiastic admin can put anything in that field. The list of "allowed" values is a suggestion, and the first place you discover the fourth value is usually a broken dashboard or a case that never got routed.

Then there are polymorphic lookups. A single reference field can point at more than one kind of object — an owner that might be a user or might be a group. Every piece of integration code that reads that field has to know this, and most of it was written by someone who assumed one target and moved on. The assumption is invisible until the other target shows up in the data.

Then there is the quietest problem of all: custom fields with no help text. Someone created Invoice__c.Approval_Stage__c three years ago. They have left the company. The field is populated, it is used in two flows, and nobody can say with confidence what the stages mean. The meaning of that field exists only as tribal knowledge — and tribal knowledge does not survive reorganizations, migrations, or handovers to a data team.

Finally, drift compounds. Fields get retyped. Objects get retired. The warehouse sync that copies the org into your analytics stack breaks — or worse, keeps working while silently carrying data whose meaning has shifted. When someone asks "what changed in the org since the last release?", the honest answer in most teams is a shrug, a diff of two metadata exports, and an afternoon of archaeology.

The missing piece is not another backup

None of this is fixed by taking more metadata snapshots. A snapshot tells you what the org is; it cannot tell you what the org is supposed to be. What is missing is a governed statement of meaning that lives outside the org, changes only when a human decides it should, and can be checked against the org's actual state at any time — automatically, repeatedly, and in a form a build pipeline can act on.

That is exactly what the CoreModels Salesforce integration provides. You export sObject describe results yourself — with the Salesforce CLI or any REST client — and upload the JSON. We never hold your Salesforce credentials; there is no live connection to your org. From that one artifact, CoreModels builds a governed model: sObjects become governed Types, fields become Elements that keep their platform-real native types like string(255) and currency(18,2), active picklist values become Taxonomies, lookups become governed references, and inline help text is carried as the field's description.

From then on, the audit does the watching. Every audit compares a fresh describe export against the governed model and reports three things: coverage (which objects and fields exist in the org but are not governed at all), drift (fields removed or retyped, value sets narrowed or widened, objects gone), and conformance — Salesforce-specific hygiene findings. Three of those findings speak directly to the pains above: picklist-unrestricted warns that the platform does not enforce a value set, so the governed taxonomy is the only control there is; polymorphic-reference records that a lookup has multiple possible targets and only the first is governed as a reference; field-no-help flags a custom field whose meaning is documented nowhere.

The audit is machine-readable and CI-ready: an error count greater than zero means a change violates governed meaning, and your pipeline can fail the build before the change reaches anyone downstream. A status badge — green for clean, yellow for warnings, red for errors — makes the current state visible in a README instead of buried in a report nobody opens.

What this changes

The forty-second schema change does not stop being possible, and it shouldn't — the org's agility is the point of the platform. What changes is that the forty-second edit is no longer silent. There is now a governed definition of what Status means, which lookups point where, and which fields carry which types; there is an automated check that notices when the org and that definition disagree; and there is a paper trail that turns "what changed?" from an archaeology project into a query.

Meaning changes still happen — but they happen on purpose, reviewed by a person, instead of accumulating as surprises. That is the whole problem this integration exists to solve: not to slow Salesforce down, but to make sure that when the org's meaning moves, somebody chose it.

The Salesforce quickstart in the CoreModels docs walks through the describe export, the import, and the first audit end to end.