Data between apps

Here's the mental shift that makes automation click: apps don't pass 'an email' — they pass fields. The trigger fires and hands your workflow a structured bundle: from, subject, body, received_at. Every later step picks from that bundle (and from previous steps' outputs) to fill its own inputs: the Sheets 'add row' action asks which field goes in column A, which in B. That picking is called mapping, and mapping is 80% of workflow building.

TRIGGER OUTPUT (Gmail)          MAPPED TO (Sheets: add row)
from                        ->  column B  (customer email)
subject                     ->  column C  (issue summary)
body (first 500 chars)      ->  column D  (details)
received_at                 ->  column A  (timestamp)
(nothing)                   ->  column E  (status - set fixed value: 'new')

Note the last row: not every input comes from the trigger. Fixed
values, lookups, and computed fields are all normal. And nothing
says every trigger field must be used - map what the output needs.

The three format gotchas (you will meet all three)

• Dates. One app emits 2026-07-06T14:32:00Z, another expects 07/06/2026. Platforms ship a formatter/date step for exactly this. Rule: pick one format for anything you control (ISO 2026-07-06 sorts correctly in sheets — use it) and convert at the edges.
• Empty fields. Emails without subjects exist. A mapping that assumes subject is filled produces blank ticket titles — or a crashed step — on the day it isn't. For any field that can be empty, decide the default now: 'if subject is empty, use (no subject)'. Platforms have fallback settings; use them at every optional field.
• One-vs-many. An email with three attachments; an order with five line items. Platforms handle 'many' with loop/iterator constructs — fine, but not week-one material. For now: design triggers so one run = one thing, and know the loop exists for later.