You will be able to map output fields from one step into the inputs of the next without losing or mixing data.
Mei Ling's flow sends a confirmation email to each parent who fills in an enquiry form. In that email, the "To" box is mapped to the trigger's email field and the greeting line is mapped to the parent name field. Choosing fields like these, so that each piece of data goes to the right place, is the main job when you build a flow.
A common mistake in a first flow is a flow that runs "successfully" but sends data to the wrong place. A parent gets an email that opens "Dear ," with no name, or a phone number lands in the name column of the spreadsheet. The tool still reports success, because the trigger fired and every action ran, even though the data is in the wrong place.
Mapping, or data mapping, is choosing which output fields from earlier steps fill the inputs of a later step. It is the part of the build that decides where each piece of data goes. Most first flows go wrong here, and it is easy to get right once you understand how it works.
Every step produces output when it runs: a set of named fields, each with a value. A form response trigger outputs fields such as response ID, submitted time, parent name, email, phone, child's level and message. An "add row" action outputs the row number and the values it wrote. A "send email" action outputs a message ID.
To map a field in most tools, you click into an input box in a later step and pick from the list of fields that earlier steps produced. The tool inserts a placeholder, and on every run it replaces the placeholder with the real value. When Mei Ling picks the parent name field for her greeting line, each email carries the name of whoever filled in the form that time.
There are two rules for what you can map. First, a step can only use fields from steps that come before it. If you want the sheet's row number in the email, the "add row" step must run before the email step. Second, a field must exist before it can be mapped. If the form does not ask for the child's school, no later step can use the school, however you arrange the steps.
When you set up a trigger, most tools pull in a sample record so you can see the fields while you map. If that sample is a test submission with empty boxes, those fields may not appear in the picker, or may appear empty. You then map only what you can see. When a real enquiry arrives with a field filled in, such as the message, that value has nowhere to go.
Before you map anything, submit the form yourself with every field filled in, as a real parent would. Use a made-up but plausible name, a test email address you control and a full message. Pull that sample into the tool. Every field now shows a value, and you can check that each one lands in the right place. Do this again whenever you add a field to the form, because a new field does not appear in an old sample.
Most fields hold one value: one name, one email, one date. Some hold several values, which makes them a list. An email might arrive with three attachments. An online order might have five order lines, each with a product, quantity and price. A form might let a parent tick several subjects.
If you map a list straight into an input that expects a single value, one of three things usually happens. The tool takes only the first item, joins all the items into one long string, or fails. None of these works if you want one spreadsheet row per order line or one saved file per attachment.
When you spot a field holding several values, add a loop, which some tools call an iterator. A loop takes a list and runs the steps after it once for each item. If five order lines go in, the next step runs five times, once per line. Each tool names and sets up loops differently. The first time you meet a list, search the tool's help pages for "loop", "iterator" or "line items". Module 6 uses a loop when an invoice email arrives with more than one attachment.
Every record should carry a unique ID from the start of the flow to the end. The form response ID is a good choice, because the form creates it and it never changes. Map the ID into the sheet as its own column, put it in the subject or footer of internal emails, and add it to the reminder task.
You use the ID to trace problems. Say a parent tells you they never got the confirmation. Search the sheet for their email address and find the record's ID. Then search the tool's run history for that ID to see exactly what each step did with that record. Without a shared ID you have to match names and timestamps by eye. That is slow, and it fails completely when two parents share a surname. Module 4 uses the same ID to catch duplicates, and Module 7 uses it again for error alerts and logs.
Most mapping mistakes can be prevented by one habit: write down the hand-offs before you build. The hand-offs are the fields each step produces and which later steps use them, and where. List each step of the flow in order. Next to each step, write the fields it produces. For each later step, write which of those fields it uses and where they go, such as the "To" box or the greeting line. Then look for any field a later step needs that no earlier step produces.
In the activity below you will draw this as a table for your own workflow, using the trigger and actions you wrote down in lesson 2.1, Triggers, actions and the steps between them. Any field that a later step needs but no earlier step produces will show up as a gap, and you will see it now rather than after the first real run.
Draw a table with each step of your workflow, the fields it outputs, and which later step uses each field.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).