Skip to main content
Data mapping is the step that reshapes a record from one system’s structure into another’s, and checks it is valid, as the record moves between your app and a customer’s connected app. Two systems rarely agree on field names, formats, or required values, so a record read from one side usually needs work before it can be written to the other. This is the Native angle on a capability the Platform provides. You decide what each field should become and which records to reject; the Platform’s data-mapper node and other workflow nodes do the reshaping inside a workflow.

​
Why mapping is needed

A record almost never crosses systems unchanged. Mapping closes three gaps.
  • Field names differ. Your app’s full_name is the connected app’s firstname and lastname. Mapping renames and splits fields to match the destination.
  • Formats differ. Dates, currencies, and enums are encoded differently on each side. Mapping transforms a value into the shape the destination expects.
  • Records can be invalid. A missing email or a malformed ID should not reach the destination. Validation catches a bad record before it is written.

​
Map field to field

When two systems hold the same data under different field names, let your customer line the fields up instead of hard-coding the match. Each customer’s app is configured differently, so the mapping belongs to them. Collect the mapping with a Map v2 Dataslot in the connector’s Connect Portal. The customer matches each of their fields to the field your integration expects, for example their HubSpot contact properties to your contact schema. The saved mapping is stored on the linked account as an object keyed by left-hand value to right-hand value. Inside a workflow, the data-mapper node applies that saved mapping to records as they pass through, so each customer’s records are reshaped according to their own configuration.
Use a Map v2 Dataslot whenever the correct field pairing varies by customer. Hard-code a mapping only when it is the same for everyone.

​
Transform values

When a value needs to change shape rather than just change name, transform it in the workflow. Reformat a date, split a name, convert a currency, or restructure a nested payload into the flat shape the destination action expects. The Platform provides nodes for this inside a workflow:
  • Transform reshapes a payload declaratively, for example mapping an array of source records into the destination’s field names.
  • Custom Code handles logic a declarative transform cannot express, such as conditional formatting or lookups.
This page does not re-document those nodes. See Workflows overview for how to build and connect them.

​
Validate before you write

Check records on the way to the destination so a bad record never reaches the connected app. Validation is the difference between rejecting one malformed record and writing corrupt data into a customer’s system.
  • Required fields are present. Reject a record missing a value the destination action requires.
  • Formats are correct. Confirm an email is a valid address and an ID matches the expected pattern before you write.
  • Values are in range. Drop or flag records whose values fall outside what the destination accepts.
Validate before a write action runs. Write actions make real changes in the customer’s app, so an invalid record that slips through is written, not caught.

​
See also

Data Mapper node

Apply a saved Map v2 mapping to records inside a workflow.

Dataslots

Collect a per-customer field mapping with a Map v2 Dataslot.

Read and write data

Execute the read and write actions that mapping sits between.

Two-way sync recipe

See mapping in a full sync build.