DataWeave Patterns for Salesforce Integrations: Mapping Without Creating a Maintenance Problem

DataWeave often becomes the real contract boundary in a MuleSoft–Salesforce integration. The goal is not merely to produce valid JSON - it is to make business mapping explicit, testable, and resilient to change.

Map contracts, not entire payloads

Prefer intentional mappings:

%dw 2.0
output application/java
---
payload map (customer) -> {
  Source_Customer_Id__c: customer.id as String,
  Name: customer.displayName,
  BillingCountry: customer.address.country default null,
  Active__c: customer.status == "ACTIVE"
}

This is usually safer than forwarding a source payload shape and hoping field names remain compatible.

Normalize at the boundary

If a source can send "", missing fields, or inconsistent codes, normalize once before Salesforce operations. Downstream logic should not repeatedly rediscover the same source quirks.

Be deliberate about null

There is an important semantic difference between:

field omitted;
field present with null;
empty string;
defaulted value.

Those states can have different update semantics. Encode the intended behavior in the mapping rather than applying blanket null removal everywhere.

Extract reusable domain functions

When multiple flows map the same country codes, identifiers, dates, or status values, centralize the rule in a reusable DataWeave module or function. Reuse business semantics - not giant transformations that couple unrelated APIs.

Separate transport from domain mapping

A useful structure is:

source payload
 → source normalization
 → canonical/domain representation (when justified)
 → Salesforce contract mapping
 → Salesforce Connector

Not every integration needs a canonical model. Introduce one only when it reduces real coupling.

Test edge cases

DataWeave tests should cover nulls, missing values, unexpected enumerations, date/time zones, large strings, Unicode, and partial update payloads - not just the happy path.