Scrapeer
Variables

Track Change Block

Track Change reads a memory key, compares it with the current value, saves the new value, and routes created, changed, or unchanged outcomes.

At a glance

Best for
Detecting changes between runs
Routes
Created, changed, unchanged
Memory scope
Project or schedule
Error handle
Yes

What it does

Track Change is for scheduled or repeated Flows where the previous value matters.

It compares the current value with saved memory and gives the Flow separate outcome handles for first seen, changed, and unchanged values.

Use it when

  • Detect whether a price changed since the last run.
  • Only notify when a scraped value changes.
  • Remember checkpoints across scheduled runs.

Do not use it when

  • You only need a variable during one run.
  • You want to save without comparison; use Save to Memory.
  • The value should not persist across runs.

Settings

Track Change needs a memory key, value, scope/group, and optional first-write behavior.

Memory key

Required: Yes
Variables
Yes
Description
Key used to read and write the remembered value.

Value

Required: Yes
Variables
Yes
Description
Current value to compare and save.

Memory group

Required: No
Variables
Yes
Description
Groups related keys such as prices or seenListings.

Memory scope

Required: No
Variables
No
Description
Project scope or schedule scope for scheduled runs.

First write changed

Required: No
Variables
No
Description
Controls whether a first-time value routes as changed.

Outputs

Track Change exposes comparison metadata and outcome routing.

previousValueany

Remembered value before this run, when it existed.

currentValueany

Current value saved by this run.

statuscreated | changed | unchanged

Outcome used for routing.

Example Flow

Use Track Change after extracting a value and before sending notifications or saving output.

  1. Extract the current value.
  2. Track it against memory.
  3. Run a notification branch only when the value changed.

Errors and fixes

Start with symptoms visible in the editor or Inspector, then check the earliest Block that produced the wrong page state, variable, or output.

Every run looks like the first run.

Check
Check memory key, group, and scope.
Fix
Use stable memory addressing and avoid putting volatile values in the key.

The wrong branch runs on first write.

Check
Check the First write changed setting.
Fix
Set first-write behavior to match your notification logic.

Local and cloud runs

Project and schedule memory are exposed in the UI. Schedule scope should be verified on the runtime used for scheduled Cloud Runs.

Blocks

Understand how Blocks connect and pass state through a Flow.

Runs and outputs

Inspect Block output, errors, and variables after a run.