Using Variables in Filters

Filter values can reference procedure variables, enabling dynamic, parameterized filters that change based on runtime context.

How Variable Substitution Works

When a filter value references a procedure variable, Precision Bridge replaces the variable reference with the variable's current value at execution time. This means the same procedure can produce different results depending on its input variables.

Syntax

In the filter builder, set the filter value to the variable name. Precision Bridge will resolve it at runtime.

For example, if you have a procedure variable called target_status with value "active":

[status] = target_status

At execution time, this becomes:

[status] = "active"

Common Patterns

Filter by Date Variable

Use a date variable to control the extraction window:

[created_date] > start_date

Where start_date is a procedure variable set to a date value or calculated by a previous step.

Filter by List Variable

Use a list variable with the In operator:

[sys_id] in id_list

Where id_list is populated by a previous Extract Records step — for example, a list of IDs from a parent migration.

Filter by Input Variable

Define input variables on the procedure to make it reusable:

[category] = input_category

When calling this procedure (via Call Procedure step or direct execution), the caller provides the value for input_category.

Incremental Migration Pattern (Delta Migration)

A common use of variable-based filters is incremental — sometimes called delta — migration: extracting only records that have been created or modified since the last run.

Recommended: LAST_EXECUTION_TIMESTAMP

Every procedure has two automatically-maintained system variables that exist specifically for this pattern. They appear at the top of the procedure's Variables panel and require no manual setup:

• LAST_EXECUTION_TIMESTAMP — start time of the previous completed run (UTC, timezone-aware). Empty on the first run.
• CURRENT_EXECUTION_TIMESTAMP — start time of the current run; useful when a step later in the procedure needs the same instant the run began at.

For the common case, reference LAST_EXECUTION_TIMESTAMP directly in the extraction filter:

[sys_updated_on] > LAST_EXECUTION_TIMESTAMP

No procedure input variable, no Assign Variables step, no external persistence. The platform writes the new value at the end of each successful run, and the next run picks it up automatically.

First-Run Handling

LAST_EXECUTION_TIMESTAMP is None on the very first run, which makes the comparison above match no records. Two options:

• Filter with a fallback in a formula filter: [sys_updated_on] > (LAST_EXECUTION_TIMESTAMP or datetime(2000, 1, 1, tzinfo=timezone.utc)) — treats a missing prior run as "everything since 2000". See Formulas in Filters.
• Override for the first run: toggle the Override switch on LAST_EXECUTION_TIMESTAMP in the Variables panel and pick a concrete starting cutoff. Disable the override after the first run so subsequent runs pick up the maintained value.

The override switch is also the right mechanism for one-off re-runs from a specific point in time. The combobox lists past execution start times, plus a Custom Date Time Value option for arbitrary cutoffs.

Custom Input Variable

A procedure input variable (e.g. last_run_date) is still appropriate when the cutoff is sourced from outside the procedure — a target record, a correlation table, a CSV file, or an external orchestrator passing the value in on each call.

1. Add a procedure input variable last_run_date (e.g., default "2024-01-01" for the initial run).
2. Set the filter: [sys_updated_on] > last_run_date.
3. Pass a new last_run_date to the procedure on each run, either by setting it manually or by reading it from a persisted source (a target record, a CSV file, or a table correlation).

This pattern significantly reduces extraction time for large tables where most records haven't changed.

Procedure variables reset to their defaults at the start of every run. Updating last_run_date mid-procedure via an Assign Variables step only affects the current run — the next run reads the default again. For fully automated incremental sync without an external source, prefer LAST_EXECUTION_TIMESTAMP. Otherwise persist the cutoff explicitly: write the run timestamp to a dedicated target record or CSV file at the end of the procedure, and load it back into last_run_date via an Extract Records step at the start of the next run.

Variables in Combined Conditions

Variables can be used in any condition within a combined filter:

[status] = target_status AND [priority] <= max_priority AND [created_date] > start_date

Each variable is resolved independently at runtime.

Notes

• If a variable is None or undefined, the filter condition may not behave as expected. Ensure variables have valid values before execution.
• Variable substitution happens before the query is sent to the source system — the source system sees the resolved value, not the variable reference.
• For more complex dynamic values (e.g., computed dates, transformed strings), use formula expressions instead. See Formulas in Filters.

Related Documentation

• Procedures and Variables — creating and managing procedure variables
• Formulas in Filters — using expressions for computed filter values