Salesforce export object metadata for a data dictionary

What does exporting Salesforce object metadata mean for a data dictionary?#

It means exporting the definitions behind the records, not the records themselves: which objects exist, what each field is called, its type and size, the values a picklist allows, the help text users saw, and the rules that blocked bad entries. A CRM dataset without that layer forces every buyer to guess what Status = Escalated or a custom field like Tier__c meant.

Salesforce exposes this layer through three official routes that overlap but are not identical. Describe calls return how the org presents each object and field to the API user right now. The Metadata API returns the configuration as XML files, including descriptions and validation rules that describe output does not carry. The Tooling API lets you query metadata as rows, for example one row per field through FieldDefinition.

The data dictionary that ships with the dataset is built from those exports, then trimmed to the fields actually in the delivery. Configuration that only runs the org, such as automation and security settings, stays behind.

Which Salesforce metadata export route returns which details?#

Use describe for the field list and live picklist values, the Metadata API for the descriptive and rule metadata, and the UI API when picklists differ by record type. Schema Builder is for looking, not exporting.

What should the metadata export map keep and leave out?#

Keep the metadata a reader needs to interpret a value in the dataset; leave out the metadata that only operates or secures the org. The map below is the working asset: each need, the route that answers it, the output, and the default keep or exclude call for a licensed CRM dataset.

How do you export field definitions with describe and the Salesforce CLI?#

List the objects, then describe each one in scope and save the JSON. With the Salesforce CLI that is sf sobject list --sobject all to see names, then sf sobject describe --sobject Account --json, repeated for Contact, Opportunity, Case and each custom object in the delivery. Add --use-tooling-api only when you are describing Tooling API objects.

Each field in the output carries the properties a dictionary needs: name, label, type, length, precision, scale, nillable, custom, unique, externalId, calculated and calculatedFormula, referenceTo and relationshipName for lookups, inlineHelpText, restrictedPicklist, and picklistValues. The object level carries recordTypeInfos with each record type's name and ID.

Two describe behaviors decide whether your dictionary is complete. First, the fields array contains only the fields the running user can view, so run the export as a user whose field-level security covers every delivered field and record that user's profile in the manifest. Second, inlineHelpText appears only when at least one field on the object has help text; a missing property means no help text on that object, not a failed export.

If you prefer rows to JSON, the Tooling API exposes FieldDefinition, which gives row-based access to field metadata. sf data query --use-tooling-api with --result-format csv and --output-file writes the result straight to a file you can diff between export runs.

How do you retrieve descriptions, picklist value sets and validation rules with the Metadata API?#

Build a manifest that names the objects and value sets, then retrieve it. sf project generate manifest --from-org <alias> --metadata CustomObject GlobalValueSet StandardValueSet writes a package.xml from what exists in the org; by default it leaves out metadata in managed and unlocked packages, so add --include-packages managed unlocked if a delivered field belongs to an installed package.

Name standard objects explicitly. Salesforce's migration guide says standard objects, and custom fields on them, must be named in package.xml under the CustomObject type to be retrieved, so list Account, Contact, Opportunity and Case by name rather than relying on a wildcard.

Run sf project retrieve start --manifest package.xml from inside a Salesforce DX project. Source format splits each object into folders: objects/Account/fields/Tier__c.field-meta.xml, plus validationRules, recordTypes and businessProcesses folders. Add --target-metadata-dir if you want the original metadata format as a ZIP instead. Each field file holds the label, type, description, inlineHelpText and, for picklists, the valueSet with its values.

Validation rules come back as their own files. Each one holds the formula that returns true when data is invalid and the error message users saw. Those two facts explain gaps and odd defaults in the records: if a rule required Close Reason once Status was Closed, a blank Close Reason on a closed case points to a record created before the rule or by an integration that bypassed it.

How should picklist values, dependencies and record types appear in the dictionary?#

List every value that occurs in the delivered records, not just the values active today, and say for each one whether it is active, which record types allowed it and which controlling value it depends on. That is the part of a CRM data dictionary most exports get wrong.

Inactive values matter because Salesforce keeps a deactivated value on the records that already hold it while hiding it from new selections. A Case export from 2019 to 2026 can therefore contain reasons nobody can pick any more. Pull the full value set from the field metadata, mark inactive values, and count how often each appears in the data.

Record types can narrow the values a user could choose. Salesforce's own developer blog notes that admins restrict picklist values per record type and that the describe-based Apex approach does not reflect that; the UI API resource returns the values for all picklists on one record type in a single request, including dependent hierarchies. Opportunity Stage, Case Status and Lead Status are a special case: their values come from the sales, support or lead process assigned to the record type, which is why the BusinessProcess files belong in the retrieve.

For dependent picklists, describe marks the field with dependentPicklist and names its controllerName, and each picklist entry carries a validFor mapping to the controlling values. Decode it once into a two-column table (controlling value, allowed dependent values) and ship that table instead of the encoded mapping. Standard picklists such as Industry or Lead Source live in StandardValueSet metadata from API version 38.0, and shared custom value sets live in GlobalValueSet files, so retrieve both.

What does a filled data dictionary row look like for Account, Case and Opportunity?#

One row per delivered field, combining describe output, the field XML and a plain-language note. The rows below are illustrative examples from a typical org; your labels, values and rules will differ, and a value list should come from your own export.

Which metadata should not ship with a CRM dataset?#

Leave out anything that describes how the org runs or who can see what, unless it changes the meaning of a delivered field. Profiles and permission sets map the security model; flows and workflow rules encode operating logic; custom settings can hold endpoints and configuration values; email templates are written content with merge fields. None of them help a buyer read a record, and several expose more about the company than the dataset should.

Where automation sets a delivered field, describe the effect in one line in the dictionary instead of shipping the flow. For example: Priority is set to High by automation when Account Tier is Enterprise. That keeps the interpretive fact and drops the implementation.

Review free text in metadata too. Field descriptions and help text sometimes name employees, customers or internal systems, and Salesforce notes that field-level help on objects exposed in an Experience Cloud site is visible to site members, so some of it may already be semi-public. Help text can run up to 510 characters, which is room for more than a label; read it before it ships.

How do you check the dictionary against the exported records?#

Reconcile the dictionary with the delivered files before release. Every column in the files should have a dictionary row, every dictionary row should point to a column, and every picklist value found in the data should appear in the value list.

• 1Field coverage: compare CSV headers with the describe field names for each object; flag fields the export user could not see.
• 2Formula and roll-up fields: Salesforce's Data Export FAQ says these are never included in Data Export files, so mark them as absent from that route or export them through the API.
• 3Picklist drift: count distinct values per picklist column and match them to active and inactive values from metadata; unknown values usually mean a renamed value or an integration writing free text.
• 4Record type coverage: confirm each delivered record type has its allowed-values list.
• 5Version stamp: record the org's API version used for describe, the export date and the manifest file name so the dictionary can be regenerated.

How does this apply when you license the CRM dataset?#

A buyer pays for records they can interpret, and the metadata export is what makes them interpretable. It also limits risk: the dictionary is built from definitions you reviewed, and automation and security configuration stay inside the company.

SourceX runs sourcing, rights review, contracting, data preparation, delivery and payment for businesses licensing operational data to AI developers, and the company approves exactly what is released before anything is shared. The exports on this page run in your own org with Salesforce's standard tools. The first step is a short company assessment, and no data uploads are needed to see if a company qualifies.

Exporting metadata does not settle whether you may license the records. The four permissions are separate questions: access to the org, privacy permission for the people in it, ownership of the records, and contract rights to license them. De-identification alone does not create a right to license.