Configuring the Filter

The Filter tab on a Migrate Records step controls which records are extracted from the source table. Without a filter, every record in the source table is extracted. Adding filter conditions lets you target a specific subset of records — for example, only incidents created in the last 30 days, or only active users in a particular department.

Why Use a Filter

Filters are essential for:

• Reducing extraction volume — Avoid pulling millions of records when you only need a subset
• Targeting specific data — Extract only records that meet your migration criteria (e.g., a particular status, date range, or category)
• Incremental migrations — Extract only records that have changed since the last migration run
• Testing — Limit extraction to a handful of records while developing and validating your step configuration

Filter Modes

The Filter tab provides a dropdown to select the filter mode. The available modes are:

None

No filter is applied. All records in the source table are extracted. This is the default. See Filter with No Conditions below for guidance on when this is appropriate.

Basic Filter

A simple key-value equality filter where each condition specifies a field name and an exact match value. All conditions are combined with AND.

Basic filters are primarily used internally by Precision Bridge and for simple CSV filtering. In most cases, the Standard filter provides a better experience — use Basic only when you need a straightforward equality check and don't need operators like contains, greater than, or OR logic.

Standard Filter

The standard filter provides a visual query builder for constructing filter conditions without writing raw query syntax. It is the recommended approach for most use cases.

To build a standard filter:

1. Add a condition — Click the add button to create a new filter condition.
2. Select a field — Choose the source field to filter on from the dropdown. The available fields are determined by the source table's schema.
3. Select an operator — Choose a comparison operator. Common operators include:
   • equals / not equals
   • contains / does not contain
   • starts with / ends with
   • greater than / less than
   • is empty / is not empty
   • in / not in (for matching against a list of values)
4. Enter a value — Provide the comparison value. The value type should match the field type (text, number, date, etc.).

Combining Conditions

Multiple conditions can be combined using logical operators:

• AND — All conditions must be true for a record to be included
• OR — At least one condition must be true for a record to be included

You can group conditions to create complex logic. For example:

([status] = "active" AND [priority] = "1")
OR
([status] = "active" AND [created_on] > date(2025, 1, 1))

Native Filter

The native filter allows you to enter a raw query string in the source system's own query language. This is useful when:

• You need query features not available in the standard builder
• You have an existing query string you want to reuse
• The source system has a specialized query language with advanced capabilities

Common native filter formats:

Source System	Native Filter Syntax	Example
ServiceNow	Encoded query string	active=true^priority=1^ORpriority=2
Jira	JQL (Jira Query Language)	project = PROJ AND status = "In Progress"
Database	SQL WHERE clause	status = 'active' AND created_date > '2025-01-01'

To use a native filter:

1. Switch to the Native filter mode on the Filter tab
2. Enter the raw query string in the text input
3. The query string is passed directly to the source system's API or query engine

Tip: When using native filters, ensure your query syntax is valid for the source system. Precision Bridge does not validate native query syntax — invalid queries will produce an error during extraction.

Testing Your Filter

Before running a full migration, it is good practice to verify that your filter returns the expected records:

1. Prototype in the Connection Explorer. Open the source connection's Connection Explorer, pick the same table, and build the filter in the Query Builder pane. The explorer uses the same filter language as the Migrate Records step, so what you see there is what you'll get during migration.
2. Execute the step with a Limit. On the Filter tab, set a Limit (e.g., 5–10 records) and execute the step end-to-end to validate the filter against the live migration path.
3. Check the record count after execution to confirm the number of extracted records matches your expectations.
4. Review extracted data in the step's execution output to spot-check individual records.

If the filter returns no records or too many records, revisit the filter conditions and verify:

• Field names match the source table schema exactly
• Comparison values are in the correct format (e.g., dates in the expected format)
• Logical operators (AND/OR) are combining conditions as intended

Filter with No Conditions

If you leave the filter empty (no conditions), the step extracts all records from the source table. This is appropriate when:

• You want to migrate the entire table
• The source table is small enough to extract completely
• You are performing a full initial migration rather than an incremental update

For large tables, always consider adding at least a basic filter to limit the extraction scope.

Further Reading

For a comprehensive reference on the filter language, operators, and advanced filtering techniques, see the Introduction to Filters article in the Filtering category.