DLO-to-DMO mapping

Last updated: October 29, 2026, 17:27 (UTC+1).

Runtime verified

Verification scope: Live-org reads and the explicitly described bounded operations were tested. The operation-specific limitations still apply; this badge does not verify untested writes or general CRUD support.

Back to Data Cloud with Salesforce CLI. Start with its setup, placeholders and safety guidance before running these examples.

DLO-to-DMO mapping — ObjectSourceTargetMap.

This is the definition that connects fields in a DLO to fields in a DMO. Both objects must already exist with matching fields, primary keys and key qualifiers.

Supplied workflows for DLO-to-DMO mapping
Retrieve	Create	Update	Delete
Yes	Partial	Partial	?

Yes: a usable scoped workflow is supplied. Partial: a usable bounded, combined or incomplete asynchronous workflow is supplied. Neither means universal capability. No: proven unavailable in an explicit scope. ?: unknown, untested or no usable workflow supplied. Neither No nor ? displays method icons. means dedicated CLI commands; means API-led requests or facades, even when invoked through the CLI. Two icons identify alternatives, not equivalent coverage. Read each operation's prerequisites and limits. An available operation tab may explain an illustrative mechanism without supplying a usable summary workflow.

Retrieve

CLI — Available: Retrieve the mapping XML using its actual metadata member name.
API — Unknown: No API mapping retrieval workflow is supplied.
sf-plugin-data — Unknown: Not implemented in this guide; no workflow is supplied.

CLI

sf project retrieve start --metadata ObjectSourceTargetMap:CustomerMapping --target-org SOURCE_ALIAS --api-version 65.0 --wait 5 --json

The response points to force-app/main/default/objectSourceTargetMaps/CustomerMapping.objectSourceTargetMap-meta.xml. Use the actual metadata member name from your org, not a name guessed from the source and target objects.

An independent exact-name standard Metadata API 65 retrieve was reverified on October 29, 2026 for one retained mapping in one source org. The separately retrieved XML matched the exported definition byte for byte in a configured package source directory. This is source-only definition evidence: it does not establish primary-key or key-qualifier compatibility, prerequisite readiness, cross-org portability or operational deployment. No target calls, writes or processing were performed in this check; it does not requalify the bounded write examples below.

Create

CLI — Available: Complete mapping between existing custom objects; formulas, filters and processing-free creation are not established.
API — Unknown: No API mapping creation workflow is supplied.
sf-plugin-data — Unknown: Not implemented in this guide; no workflow is supplied.

CLI

Start with a complete retrieved mapping file at force-app/main/default/objectSourceTargetMaps/CustomerMapping.objectSourceTargetMap-meta.xml. For example, one field pair looks like this:

<ObjectSourceTargetMap xmlns="http://soap.sforce.com/2006/04/metadata">
  <creationType>Custom</creationType>
  <fieldSourceTargetMaps>
    <creationType>Custom</creationType>
    <filterApplied>false</filterApplied>
    <filterOperationType>Equal</filterOperationType>
    <isSourceFormula>false</isSourceFormula>
    <sourceField>CustomerSource__dll.Id__c</sourceField>
    <targetField>Customer__dlm.Id__c</targetField>
  </fieldSourceTargetMaps>
  <!-- Other retrieved field pairs omitted. -->
  <masterLabel>Customer Mapping</masterLabel>
  <sourceObjectName>CustomerSource__dll</sourceObjectName>
  <targetObjectName>Customer__dlm</targetObjectName>
</ObjectSourceTargetMap>

Keep all field pairs in the real file. Once you have checked the existing custom objects and confirmed that this mapping does not already exist:

sf project deploy start --metadata ObjectSourceTargetMap:CustomerMapping --target-org TARGET_ALIAS --api-version 65.0 --test-level NoTestRun --wait 5 --json

{ "status": 0, "result": { "success": true, "status": "Succeeded", "files": [{ "fullName": "CustomerMapping", "type": "ObjectSourceTargetMap", "state": "Created" }] } }

Read the mapping back and compare the source, target and every runtime field pair. Salesforce can generate system qualifier pairs such as KQ_Id__c that were not in the XML; do not add guessed pairs yourself. This example does not cover arbitrary formulas or filters, and it does not guarantee that mapping creation performs no internal processing.

Update

CLI — Available: Label-only update; retargeting, field removal and formula/filter updates are not verified.
API — Unknown: No API mapping update workflow is supplied.
sf-plugin-data — Unknown: Not implemented in this guide; no workflow is supplied.

CLI

The verified change is the label only. Edit masterLabel in the complete file, leaving all pairs and object references alone:

<masterLabel>Customer Mapping Updated</masterLabel>

Then deploy it:

sf project deploy start --metadata ObjectSourceTargetMap:CustomerMapping --target-org TARGET_ALIAS --api-version 65.0 --test-level NoTestRun --wait 5 --json

The file entry can report Changed; sending the same file again can report Unchanged. These are separate invocations, and neither proves that Salesforce performed no internal work. Read back the label and pairs. Retargeting, field removal and formula/filter updates have not been verified.

Delete

Standalone mapping deletion is not supported by this example. It can fail with an internal server error or a restriction on removing the sole mapping. Deleting an empty, owned parent DMO can remove its sole owned mapping, as described above; do not delete an arbitrary parent as a workaround.

CLI — Blocked: Standalone mapping deletion can fail with an internal error or sole-mapping removal restriction.
API — Unknown: No standalone API mapping deletion workflow is supplied; parent-deletion observations are not a recipe.
sf-plugin-data — Unknown: Not implemented in this guide; no workflow is supplied.