A Week With a Governed Salesforce Org

"Has anything in the org drifted from what we agreed?"

Before governance, answering that question costs a meeting: someone exports metadata, someone else diffs it against a copy from last quarter, and the conversation ends with "probably fine." After governance, the answer is a badge — green, yellow, or red — and a report that names every finding. This article is about the after-state: what a team can actually do, day to day, once its Salesforce org is governed in CoreModels.

Day one: an export and an import

Getting to governed takes one artifact. An admin runs the describe export with the Salesforce CLI — aggregating the sObject describe results for the objects worth governing — and uploads the JSON to CoreModels. No credentials change hands; nobody connects anything to the org.

The import builds the governed model in one pass: sObjects become Types, fields become Elements with their platform-real types (string(255), currency(18,2)), active picklists become Taxonomies, lookups become governed references, and inline help text becomes field descriptions. The response is itemized — how many objects and fields were added, how many already existed and were left untouched, and a lossiness list that states plainly anything the import had to approximate: a currency type carried as a double with its exact platform type preserved in the vendor metadata, or a lookup that points at an object outside the export. The parsed org snapshot is stored alongside the model, which matters later in the week.

Tuesday: a metadata change goes through CI

A developer opens a pull request in the metadata repo that adds a field and reworks a picklist. The pipeline re-exports describes against a sandbox org and calls the CoreModels audit on the machine-to-machine API surface — the one that accepts user API keys, built for exactly this.

The audit compares the fresh export against the governed model and returns counts, coded findings, and a markdown report ready to drop into the job summary. The rule is simple: an error count above zero means the change violates governed meaning, and the build fails. In this case the picklist rework narrowed a governed value set — the audit says so, names the field, and the conversation happens in the PR, before the change ships, instead of in an incident channel afterwards.

Not every finding blocks. A warning that a picklist is unrestricted — meaning Salesforce itself will not enforce the value set — or an informational note that a custom field has no help text shows up in the report without failing the build. The team decides what to gate on; the audit's job is to make the facts impossible to miss.

Thursday: the model changes, not the org

Governance runs in both directions. On Thursday a data steward updates the governed model — a taxonomy gains a value after a review. The question flips: does the org still conform to the model?

Answering it does not require anyone to touch Salesforce. A single re-audit call replays the audit engine over the org snapshot stored at import time, against the current governed model. No fresh export, no credentials, no coordination with the admin team. The run lands in the rolling audit history automatically, so the drift trail stays continuous: every audit and re-audit, with its counts and finding codes, in one timeline.

That history is the team's answer to "when did this start?" — not a guess, but a sequence of recorded runs showing exactly when a finding first appeared.

Friday: meaning flows back to the org

The week's last move is the one teams tend not to expect from a governance tool. The reviewed taxonomy change from Thursday needs to reach the org — and CoreModels generates the starting point: Metadata-API CustomObject XML scaffolds, one file per governed Type, with restricted picklist value sets built from the governed taxonomies, Lookup fields from governed references, required flags from NotNull constraints, and any governed-first fields minted with the __c suffix.

These are review-and-deploy scaffolds. They flow into the org through the team's own change process — the same pull requests, the same deployment tooling, the same approvals. CoreModels never deploys to the org and never holds the credentials that could. The loop closes with a human hand on it, which is exactly where a meaning change belongs.

Before and after

Put the two states side by side. Before: value sets that exist only in a settings page, drift discovered by broken reports, field meaning stored in the memory of whoever created the field, and schema questions answered by metadata archaeology. After: a governed model with platform-real fidelity, a CI gate that fails builds on meaning violations, a one-call re-audit whenever the model moves, a rolling history that timestamps every check, a badge that makes the current state public inside the team, and generated scaffolds that carry reviewed meaning back to the org through your own pipeline.

And one more thing rides along for free: every governed fact — every type, taxonomy value, and reference — is queryable by AI agents over MCP, so the same model that gates your builds also grounds your automation.

None of this slowed the org down. Admins still click, developers still ship, the business still gets its Friday field. What changed is that the org's meaning now has a home outside the org, a guard that never sleeps between exports, and a paper trail that answers questions in seconds. The Salesforce quickstart in the CoreModels docs shows every call in the loop, from first export to first green badge.