Configuring Tables

The Tables tab is the starting point for any Migrate Records step. It defines where records are extracted from (source) and where they are loaded into (target). Both the source and target are specified as a combination of a connection and a table on that connection.

Source Configuration

Selecting a Source Connection

The source connection dropdown lists all connections configured in your project. A connection encapsulates the credentials and settings needed to communicate with an external system — for example, a ServiceNow instance, a Jira project, a database server, or a CSV file location.

Choose the connection that points to the system you want to extract data from.

Selecting a Source Table

After selecting a source connection, the source table dropdown is populated with the tables (or entities) available on that connection. What constitutes a "table" depends on the connection type:

Connection Type	What "table" means
ServiceNow	A ServiceNow table (e.g., `incident`, `sys_user`, `cmdb_ci`)
Jira	A Jira issue type within a project
Database	A database table or view
CSV	A CSV file
API	An API endpoint or resource

Select the table that contains the records you want to migrate.

Target Configuration

Selecting a Target Connection

The target connection dropdown works the same way as the source. Select the connection that points to the system where records should be loaded.

The source and target connections can be of different types. For example, you can extract from a CSV file and load into ServiceNow, or extract from Jira and load into a database.

Selecting a Target Table

After selecting a target connection, choose the target table where records will be inserted or updated. The target table's field schema determines which fields are available for mapping on the Fields tab.

How Table Metadata Is Loaded

When you select a connection, Precision Bridge retrieves the available tables and their field schemas from the connection's metadata. This metadata includes:

Table names and display labels
Field names, data types, and constraints
Reference relationships to other tables (where applicable)

The metadata is cached locally after the first retrieval to improve performance. If the underlying system's schema changes (e.g., new fields are added, tables are renamed), the cached metadata may become stale.

Refreshing Table Metadata

To refresh the table metadata for a connection:

Navigate to the connection's configuration page
Use the Refresh Metadata action to re-fetch the schema from the remote system
Return to the Migrate Records step — the updated tables and fields will be available

You should refresh metadata whenever:

New tables or fields have been added to the source or target system
Fields have been renamed, retyped, or removed
The table list in the dropdown does not reflect the current system state

Considerations for Large Tables

When working with source tables that contain a large number of records, keep the following in mind:

Use filters to limit extraction — Rather than extracting all records from a large table, apply a filter on the Filter tab to target only the records you need. This reduces extraction time, memory usage, and API call volume.
Batch sizing — For large target loads, consider adjusting the batch size on the Advanced tab to balance throughput and memory consumption.
Keyset pagination — For very large source tables where offset-based pagination may become unreliable (e.g., when records are added or removed during extraction), enable keyset pagination on the Advanced tab.

When Source and Target Schemas Do Not Match

It is common for source and target tables to have different schemas — different field names, different data types, different numbers of fields, or entirely different structures. This is expected and is handled by the field mappings on the Fields tab.

Field mappings define exactly how each target field is populated, whether by copying a source field, applying a formula, performing a value translation, looking up a related record, or using a constant value. You do not need a one-to-one correspondence between source and target fields.

Common schema mismatch scenarios:

Scenario	How to handle it
Different field names	Create a Source Field mapping from the source field name to the target field name
Different data types	Use a Formula mapping to convert between types (e.g., string to integer)
Target field has no source equivalent	Use a Constant, Formula, or Procedure Variable mapping
Source field has no target equivalent	Omit the mapping for that source field — it will be ignored
Field needs value translation	Use a Match mapping to define value pairs (e.g., priority `1` to `Critical`)
Field references a related record	Use a Lookup or ID mapping to resolve the reference

Tips

Verify your connections are working before configuring tables. If a connection cannot reach the remote system, the table list will be empty or stale.
Start with the source table — selecting the source first allows the wizard (if used) to propose field mappings based on the source schema.
Use descriptive step names that reference the table being migrated (e.g., "Migrate Incidents", "Migrate Users") to keep your procedure readable.