Blank Salesforce project
Govern your Salesforce org from one describe export — CoreModels never touches the org.
Govern the org whose schema can change in forty seconds from Setup.
A Salesforce org is a production database whose schema is edited through a settings page. Describe APIs already expose the truth of that schema. Teams still copy fields into warehouses and CDPs by hand, then discover picklist changes when a load fails or, worse, when it does not.
CoreModels imports the object model, including picklists as taxonomies. Object-model governance recipes focus on the objects that actually leave the org. Generate-back and the CI gate give integrations a reviewed baseline the next Setup click cannot silently invalidate.
The platform stays easy for admins. Downstream meaning stops being an accident of the last save.
Recipes
Recipes for Salesforce
Govern your Salesforce org from one describe export — CoreModels never touches the org.
Fail the build before the org forgets what it means.
Zero to first audit: your org as a governed model from one describe export.
Governed model in, Metadata-API CustomObject XML out — deployed only by you.
It takes forty seconds to change what a field means. Make the meaning governed.
Uses
Articles that explain the gap, then point at the recipe that closes it.
Setup. Object Manager. Pick a field. Edit the picklist. Save.
Recipe: Salesforce object-model governance
Outcomes"Has anything in the org drifted from what we agreed?"
Recipe: First governed Salesforce import
GovernanceA governance tool pointed at your CRM is asking for a lot of trust. Your Salesforce org holds the pipeline, the customer list, and the revenue numbers; any tool that wants to "govern" it should have to say, precisely, what it will and will not do. So before we describe what the CoreModels Salesforce integration does, here is what it refuses to do — because the trust story is the product.
Recipe: Object scaffolds back to Salesforce
EcosystemTrace one entity through a typical stack. *Account* starts life as an sObject in a Salesforce org. A sync pipeline copies it into the warehouse, where it becomes a table. A transformation layer reshapes it into curated models. An event stream carries account changes to other services under a registered schema. Four systems, four technical dialects — and one business meaning that no single system owns.
Recipe: Salesforce object-model governance
AgentsAsk an AI agent to write an integration against your Salesforce org — a validation script, a sync mapping, a report definition — and watch what it does with `Status__c`. It will guess. It has seen ten thousand orgs' worth of training data, so the guess will be fluent: plausible picklist values, a plausible type, a plausible relationship to `Account`. Fluent, plausible, and wrong, because your org is not the average org. It is fifteen years of customization, custom objects, repurposed standard fields, and picklists whose real values live in a settings page the agent has never seen.
QuickstartSomewhere in your org, last quarter, somebody edited a picklist. Nobody remembers who, the field history doesn't say why, and the report that broke three weeks later never mentioned it at all. Salesforce makes schema change wonderfully easy — and makes *remembering what the schema is supposed to mean* entirely your problem.
Recipe: Blank Salesforce project · First governed Salesforce import
APIBefore writing a single call, it pays to see the whole map. The Salesforce integration in CoreModels (vendor key `salesforce`) is small enough to hold in your head: the seven core per-vendor verbs on the interactive HTTP surface, two on the machine-to-machine surface, one artifact, and two roles. The connector declares all three capabilities — **Import, Audit, Generate** — so every verb below is live for Salesforce; nothing in this reference is aspirational.
MCPWatch an agent handle a governance request end to end. A data engineer types: *"Here's this week's describe export — check whether the Salesforce org still matches the governed model, and summarize anything that changed."* The agent calls one tool, reads back structured findings plus a ready-made markdown report, and answers with specifics: which object, which field, which severity. No dashboard visit, no memorized route, no guessing.
AutomationSchema governance that lives in a wiki dies in a wiki. The only governance that survives contact with a delivery team is the kind wired into the pipeline — a check that runs on every change, fails loudly when meaning breaks, and costs nothing to keep passing. This article wires that check up for Salesforce with CoreModels: a CI job that audits a fresh describe export against the governed model, a one-line pass/fail contract, a status badge, a rolling evidence trail, and the two mechanisms that cover what CI cannot see.
Recipe: CI Drift Gate for Salesforce
Deep diveA drift audit is only as trustworthy as the mapping underneath it. If an import flattens your org into undifferentiated strings, the audit can only ever tell you undifferentiated things. So this article opens the hood on the CoreModels Salesforce connector: what each describe property becomes in the governed graph, which platform semantics survive the crossing, which are approximated — and how every approximation is declared rather than hidden.
Recipe: Object scaffolds back to Salesforce