Handling Nulls in DataWeave with default

Null and missing values are common in integration payloads. Optional Salesforce fields may not be populated, an upstream API may omit a property, or a source may explicitly send null.

For simple fallback behavior, DataWeave's default keyword keeps transformations concise.

payload.phone default "Not Provided"

The intent is immediately visible: use the incoming value when available; otherwise use the fallback.

Basic Example

Input:

{
  "firstName": "Ravi",
  "middleName": null,
  "lastName": "Shah"
}

Transformation:

%dw 2.0
output application/json
---
{
    firstName: payload.firstName,
    middleName: payload.middleName default "",
    lastName: payload.lastName
}

Output:

{
  "firstName": "Ravi",
  "middleName": "",
  "lastName": "Shah"
}

Missing Fields

default is also useful when a field may not be present.

Input:

{
  "Id": "001A",
  "Name": "Acme"
}

Transformation:

{
    accountId: payload.Id,
    accountName: payload.Name,
    industry: payload.Industry default "Unknown"
}

Output:

{
  "accountId": "001A",
  "accountName": "Acme",
  "industry": "Unknown"
}

This is particularly convenient when converting records from a flexible source contract into a target contract that expects a value.

Defaulting Arrays

A common integration problem is iterating an optional array.

Instead of scattering null checks around the transformation, establish an empty-array fallback:

(payload.contacts default []) map (contact) -> {
    id: contact.Id,
    email: contact.Email
}

If contacts is absent or null, the transformation operates on [] and produces an empty array.

This pattern is often easier to compose with functions such as map, filter, and flatMap.

Defaulting Objects

The same idea applies to optional objects:

var address = payload.address default {}
---
{
    city: address.city default "Unknown",
    country: address.country default "US"
}

An empty object can provide a useful structural fallback when downstream expressions expect object navigation.

default Is Not the Same as "Empty"

Be careful not to treat every undesirable value as null.

For example, an empty string is still a value:

{
  "phone": ""
}

If your business rule says an empty or whitespace-only phone number should also become "Not Provided", express that rule explicitly rather than assuming default is a general data-cleaning operator.

For example:

var phone = payload.phone default ""
---
{
    phone: if (isEmpty(trim(phone))) "Not Provided" else phone
}

The important distinction is semantic:

null / missing value → fallback problem
empty / invalid value → validation or normalization problem

They may produce the same final value, but they represent different input conditions.

When an Explicit if Is Better

Use default when the rule is genuinely "use this fallback when the value is unavailable."

Use an explicit condition when the fallback depends on business logic.

For example:

{
    customerStatus:
        if (payload.isActive == true)
            "ACTIVE"
        else
            "INACTIVE"
}

Trying to force conditional business logic into default can make the transformation harder to understand.

Another example:

{
    discount:
        if ((payload.orderTotal default 0) >= 1000)
            0.10
        else
            0
}

Here default is still useful for safely obtaining orderTotal, while if expresses the actual business decision.

Defaults Should Match the Target Type

Choose a fallback that makes sense for the contract.

name     default ""
contacts default []
metadata default {}
quantity default 0
active   default false

Do not default every missing value to an empty string simply because it avoids nulls. A field's type and business meaning should determine the fallback.

Be Careful with Meaningful Nulls

Sometimes null carries business meaning.

For example, a target contract may distinguish between:

field absent
field = null
field = ""

Or null may intentionally mean "clear the existing target value."

In those cases, automatically replacing null with a default can change the business semantics.

Before adding a fallback, ask:

Is this value actually missing information, or is null itself part of the contract?

A Practical Pattern for Salesforce Transformations

Suppose a Salesforce Account is being transformed for another system:

%dw 2.0
output application/json
---
{
    accountId: payload.Id,
    name: payload.Name,
    industry: payload.Industry default "Unknown",
    phone: payload.Phone default "",
    website: payload.Website default "",
    active: payload.Active__c default false,
    contacts: (payload.Contacts default []) map (contact) -> {
        id: contact.Id,
        email: contact.Email default ""
    }
}

The transformation is easy to scan because default handles straightforward availability fallbacks while the structure remains focused on mapping.

That does not mean these exact defaults are correct for every integration. The target contract should determine whether missing phone numbers should become empty strings, nulls, omitted fields, or validation failures.

Quick Rule

Use default when you can describe the requirement as:

If this value is null or unavailable, use this fallback.

Use explicit conditions when the decision depends on the content or business meaning of the value.

Keeping that distinction clear produces DataWeave code that is both shorter and easier to maintain.