3.2First scenario: trigger → action
The essentials in 30 seconds
- Everything starts with a trigger: an event (new message, new row, submitted form, scheduled time) that starts one or more actions.
- Mapping makes the link: connecting each trigger data item to the right field of the action (sender → Contact, subject → Title).
- Test before activating: run the scenario with real data, check the result, fix, then activate.
Running case — Lina removes a manual entry task
Lina, digitalisation officer in Oran, copies form requests into the tracking database every morning: a tedious entry task and a source of errors. She builds her first scenario: trigger “new form response”, action “create a row in the database”, careful mapping (name → Contact, need → Title, date → Received on). She tests with a real response, checks the created row, fixes one badly mapped field, then activates. Manual entry disappears forever.
This same case returns in the lesson, the diagram, the script and the 48h challenge.
1. Trigger → action, the founding brick
Founding concept: trigger → action. Every automation starts with a trigger: an event in an app (a new message, a new row, a submitted form, a scheduled time). It starts one or more actions in other apps (create a row, send a message, update a record). It is the elementary brick from which everything else follows.
Lina applies it to her case: the form receiving a response triggers the creation of a row in the database, then sending a message to the team. A single event, chained actions.
2. Mapping, test, activation
The key technical move is mapping: linking trigger data to action fields (the message sender → the “Contact” field of the created row). Approximate mapping gives rows with holes or empty messages: map field by field, then reread.
Then test with real data to check that everything flows correctly, then activate the scenario. This first automation is a turning point: you understand you have just removed a manual task forever. The whole of level 3 then enriches this brick (filters, routers, iterators, webhooks).
The automator's turning point
Automate once, never copy again.
🔎 Concrete example — Form → tracking database
Lina builds her first useful automation, step by step.
Trigger: New form response
Action: Create a row in the database
Mapping: name → Contact
need → Title, date → Received on
→ test with a real response, check, activate.Reading: each field of the row comes from a trigger data item.
Lesson: always test before activating.
Section vocabulary
- Trigger
- Event that starts the automation (new message, new row, submitted form, scheduled time).
Simple example: Lina's new form response.
What it is not: a manual action launched by hand.
Reflex: name each scenario by its starting event.
- Action
- Operation executed by the scenario in an app (create, send, update, search).
Simple example: Creating the tracking row then notifying the team.
What it is not: the trigger itself.
Reflex: order the actions: create first, notify second.
- Mapping
- Linking trigger data to action fields (the received name feeds the “Contact” field).
Simple example: Lina links need → Title and date → Received on.
What it is not: leaving the action fields empty or random.
Reflex: reread the mapping field by field before testing.
- Test / run
- Running the scenario with real data to check the result before activation.
Simple example: Lina sends a real test response and checks the created row.
What it is not: activating directly with no check.
Reflex: test with a real event, not an invented example.
- Polling / instant
- Trigger modes: periodic checking (polling, with delay) or real-time (webhook/instant).
Simple example: Lina's form checked every minute in polling.
What it is not: triggering guaranteed within a second in all cases.
Reflex: wait in polling or switch to instant if urgency requires it.
In practice — Building your first scenario
- Choose a simple trigger: “New response to a form” (or “New message received”).
- Add an action: “Create a row in the database” (or “Create a task”).
- Do the mapping: link the name, the need and the date to the fields of the created row.
- Test with a real response, check the created row, fix the mapping if needed, then activate the scenario.
Ready-to-say script — presenting your first scenario (30 s)
“I automated copying the requests: trigger, it is the new form response; action, it is creating the row in the database with the name, need and date mapping. I tested with a real response, checked the row, then activated. No more manual morning entry.”
To say to the team; keep a screenshot of the test row at hand.
Copy-paste template — trigger → action sheet
TRIGGER (event + watched app): _______________
ACTION 1 (create / update where?): _______________
MAPPING (data → field, line by line): _______________
REAL TEST (date + checked result): _______________
ACTIVATED (yes/no): _______________SMB / freelancer
A single form → database scenario is enough to remove the morning entry task, without changing tools.
SME in Oran
Lina adds the team notification after the row creation: two actions for one trigger.
Digital team
Standardise the mapping (identical field naming everywhere) so each scenario stays readable.
Beginner
Start with a form trigger: it is the simplest to test with a real response.
✓ Best practices
- Test with real data before activating.
- Take care with mapping (source → destination).
- Check the run history if there is a problem.
✗ Common pitfalls
- Leaving the scenario as a draft (not activated).
- Forgetting that in polling, triggering has a delay.
- Placing a filter too early that blocks everything.
Key takeaways
- Every automation starts with a trigger (event) that starts actions (operations).
- Mapping links trigger data to action fields.
- Test with real data before activating the scenario.
- This trigger → action brick is the basis of all advanced scenarios.
48h challenge — apply tomorrow
Build 1 form → database scenario, test it with a real response and activate it.
- I can state the trigger → action brick.
- I know how to map data to fields.
- I have tested and activated 1 real scenario.
Frequently asked questions
My scenario does not trigger. What should I check?
The classic causes: 1) the trigger is not configured correctly (wrong connected account, wrong watched mailbox/table); 2) in polling mode, there is a delay (the tool checks every X minutes, not in real time) — wait or use an instant/webhook trigger; 3) the scenario is not activated (left as a draft); 4) a filter placed too early blocks everything. Check the run history: it shows whether the trigger fired and where it gets stuck. Reproducing the event manually (sending a real test response) is the safest way to diagnose.
What happens if the action fails halfway?
The scenario stops in error on the faulty step, and the following steps do not run (the previous ones have already happened — hence the importance of order). You will see the error in the history, with the message returned by the app (insufficient rights, missing required field, quota reached…). For important scenarios, set up error handling (retries, fallback paths, alert) — that is exactly the subject of section 4.5. At the start, the run history and rereading the mapping are enough to fix the vast majority of cases.
What is the elementary brick of every automation?