Remember
Description
Section titled “Description”Many nodes (a CRM, sending an email, an HTTP call) replace the data with their own response: after them you no longer have the order, lead or appointment you were working on. Inside a loop it is worse, because references to earlier nodes ({{@Node.field}}) do not resolve.
The Remember node solves this in two steps:
- Save, right before the problematic node: it saves the data and lets it through unchanged.
- Restore, right after: it returns what was saved, merged with the node’s response or in its place.
[Loop over appointments] → [Remember: save] → [Send email] → [Remember: restore] → [Mark as sent]Each round of the loop gets back its own data, never another round’s, and what is saved belongs to this workflow.
Configuration
Section titled “Configuration”| Parameter | Type | Required | Description |
|---|---|---|---|
| action | select | Yes | save (the data stays the same) or restore |
| key | text | Yes | Name it is saved under. It must be the same in Save and in Restore (default recordado). You can have several names at once |
| path | text | No | Save only: path to the part of the data to save (for example lead). Empty = all the data |
| uniqueBy | text | No | How to tell each round apart. By default, the loop’s round number (or 0 outside a loop). If you prefer your own field, for example {{key}}, set it the same in Save and in Restore; that field must still exist when restoring |
| mode | select | No | Restore only. merge (default): merges what was saved into the current data and what was saved wins; replace: the data becomes exactly what was saved; under: puts what was saved in a separate field |
| outputKey | text | No | With under: field name (default recordado) |
| deleteAfter | boolean | No | Forget what was saved after restoring it (default yes) |
| onMissing | select | No | If nothing was saved: error (default, stops the run) or continue (goes on with the current data) |
Output
Section titled “Output”Save: the same data that came in, unchanged.
Restore, with merge and this saved data { "clave": "c1", "nombre": "Ana" } after an email node that returned { "status": "sent" }:
{ "status": "sent", "clave": "c1", "nombre": "Ana" }With replace it would be { "clave": "c1", "nombre": "Ana" }; with under, { "status": "sent", "recordado": { "clave": "c1", "nombre": "Ana" } }.
The loop’s internal information (_meta_) is never saved: when restoring, the current round’s is kept.
Usage Examples
Section titled “Usage Examples”Remember an appointment before sending the reminder email
Section titled “Remember an appointment before sending the reminder email”{ "label": "Remember the appointment", "action": "save", "key": "appointment" }{ "label": "Restore the appointment", "action": "restore", "key": "appointment", "mode": "replace" }Afterwards, a data node can save the appointment row with its original fields.
Keep the id a CRM returns
Section titled “Keep the id a CRM returns”{ "label": "Restore the lead", "action": "restore", "key": "lead", "mode": "merge" }The lead’s fields come back and the id the CRM returned is still available. Combine it with a Validator node that requires id and stops the flow if it is missing.
- What is saved lives in the workflow’s memory and is deleted when restored. If the run is interrupted between Save and Restore, a stray item may remain until memory is cleaned.
- If the input data is a list and you use
merge, the result is the saved list. - It does not replace a data store: it is for remembering something during one run, not between runs.
Related Nodes
Section titled “Related Nodes”- setVariable / getVariable (Variables - for single values reused across the workflow)
- validate (Validator - to check what was restored)
- iterator (Iterator - to loop over lists)