Procedures and Variables

Procedures are ordered workflows containing a series of steps that execute sequentially. They are the core building block for designing data migrations in Precision Bridge.

Working with Procedures

When you open a project created from a template, you'll find one or more pre-configured procedures. For example, the Incident Management template includes a Migrate Incidents procedure with steps for migrating incident data and related records.

Select a procedure to view its steps and configuration.

Procedure Variables

Procedure variables are the input parameters for a procedure. They serve as the initial values that steps can reference and modify during execution.

Viewing and Editing Variables

Select a procedure in the project sidebar
The procedure's input variables are displayed in the procedure configuration panel
Each variable has a name, data type, and default value

Example: Setting an Input Variable

For the Incident Management template, you'll find a variable named IncidentNumber:

Find the IncidentNumber variable in the procedure's input variables
Set its value to an incident number from your source ServiceNow instance (e.g., INC0010001)

Tip: The formula toggle next to the input field controls whether the variable stores the provided value directly or evaluates it as a formula expression. Use the direct value mode for simple string/number inputs.

Adding New Variables

You can add additional input variables to a procedure:

Click the option to add a new input variable
Choose a data type (e.g., String, Integer, List)
Give it a name (e.g., hello)
Assign a default value (e.g., PBv10)

How Variables Flow Through a Procedure

Variables defined at the procedure level provide default initial values
Steps within the procedure can read variable values for use in filters, mappings, and formulas
Steps can update variable values through output variable configurations
Updated values are available to all subsequent steps in the procedure
When a procedure is called from another procedure, input variables can be overridden by the caller

System Variables

In addition to the input variables you define, every procedure carries two system variables that are maintained automatically by the platform. They appear at the top of the Variables panel alongside your own variables, and can be referenced from filters, formulas, and field mappings exactly like any other variable.

Variable	Holds	Updated
`CURRENT_EXECUTION_TIMESTAMP`	Start time of the current procedure run, as a timezone-aware UTC datetime.	Set when each execution begins; stable for the duration of the run.
`LAST_EXECUTION_TIMESTAMP`	Start time of the previous successful run of this procedure, as a timezone-aware UTC datetime.	Updated at the end of each successful run. Empty on the very first run.

Both are persisted with the procedure, so the next scheduled or manual run picks them up automatically. They exist primarily to support incremental (delta) migrations — running a procedure on a schedule and extracting only what has changed since the previous run.

Example: Delta Migration Filter

A Migrate Records step extracting only records changed since the previous run:

[sys_updated_on] > LAST_EXECUTION_TIMESTAMP

No procedure input variable, no Assign Variables step, no external persistence required — the platform writes the new value at the end of each successful run, and the next run reads it back.

Override

You can manually override LAST_EXECUTION_TIMESTAMP for a single run via the Override switch next to the variable in the Variables panel. This is the right mechanism for:

The first run of a delta migration, where LAST_EXECUTION_TIMESTAMP is otherwise empty — pick a starting cutoff.
Re-running from a specific point in time — for example, replaying the last 48 hours after a target-side issue.

The Override switch presents a combobox of past execution start times for the same procedure, plus a Custom Date Time Value option for arbitrary cutoffs. Disable the override after the run so subsequent scheduled runs resume from the automatically-maintained value.

See Migration Strategy — Incremental Migration for the end-to-end pattern and Available Built-in Functions — System Variables for the difference between these variables and datetime.now(timezone.utc).

Next Steps

With your procedure configured, you're almost ready to run your first migration. Review the step configuration:

Field Mapping Basics — understand how source fields map to target fields
Executing a Procedure — run the migration and review results

For a deeper dive into the Migrate Records step (the most important step type), see Migrate Records — Full Guide.