Workflow data mapping

Workflow data mapping defines how a value leaving one application becomes a value another application can safely use. Field names alone are insufficient: a source field called “date” might mean order placement time, local delivery day or last update, and each needs a different destination and transformation. A reliable mapping documents meaning, format, allowed absence and ownership before automation goes live.

Start with an event and a contract

Choose one trigger, such as “order paid”, and trace its payload to the receiving action. Record each source field, type and example value, plus destination field, transformation, validation rule and missing-value treatment. Record the event identifier and the version of the source and destination contracts. This makes an upstream API change visible before it silently alters downstream work.

Distinguish an event from a current-state record: a customer-updated event may contain only changed fields, while a full customer object may include every current value. Sending an absent field as an empty string can erase data if the destination treats it as an update. Define whether the receiving action creates, replaces or partially updates a record, and test that behaviour.

Account for how the workflow starts

A polling trigger checks a service endpoint at regular intervals; a push trigger subscribes to an endpoint and receives a callback when an event or data is available. Record which trigger supplies data for each mapping, so the mapping follows the payload the workflow receives, not an assumed full record. These trigger types are available in Azure Logic Apps.

Make the object shape explicit

For JSON data, treat an object as a mapping of string keys to values. A JSON Schema can describe an object’s properties and specify a schema for each property, including its type; it can distinguish a number from a string, for example. This documents the expected shape of an input or output object and makes type mismatches visible.

Map at the right API boundary

Identify whether a workflow calls a public API used by client applications or a back-end API used for service-to-service communication. They have different requirements: back-end communication needs attention to network performance, including serialisation speed and payload size. Keeping the mapping focused on fields needed at that boundary avoids carrying unnecessary data between workflow steps.

Preserve time and identity

Record which field supplies the timestamp or identifier and how the workflow trigger uses that value. Detailed guidance on date and timezone formats and normalising identifiers across connected applications is in the sibling articles on those topics.

For retryable events, choose a stable event ID or agreed idempotency key so an interrupted run does not create a second record. A correlation ID helps trace one request through logs but does not by itself make an operation idempotent.

Decide what optional means

Note which fields are optional in the trigger payload, and record where that decision is documented. Handling optional fields in an API payload, including absent, null and empty-string semantics, is covered by the sibling article on that topic.

Record the validation rule reference for each mapped field. Validation of transformed data before sending it onward, including schema, business and destination-rule validation, is covered in depth by a sibling article.

Test the mapping as a process

Use representative payloads: a standard event, missing optional field, null value, invalid type, duplicate delivery, unfamiliar identifier and late update. Compare the outgoing payload with expected values, then check the destination record and error path in a safe test environment. Retain redacted samples and expected outputs so later changes can be reviewed.

When a mapping fails, log enough context to locate the field and event without exposing sensitive payloads unnecessarily. Route the failure to an owner; a silent skip makes a workflow look successful while records diverge. Revisit mappings when either application changes its contract, and keep redacted samples and expected outputs with the mapping record.

Use workflow data operations deliberately

In Power Automate, data operations can create, sort and rearrange data within a cloud flow. Compose can combine inputs into one output; Select and Join can reshape or combine data; Filter array can narrow an array; Parse JSON can make data available for later actions. These operations let a mapping be expressed as a sequence of identifiable steps rather than hidden inside a single expression.