Connection Explorer

The Connection Explorer is the workbench for inspecting a connection's tables and records before — and while — you build migrations against it. Use it to browse the source schema, view a table's relationships as an entity-relationship diagram, query records with the same filter language used in the Migrate Records step, inspect individual records field-by-field (including attachments), and validate that filters and lookups behave as expected.

The explorer is available on every connection. Open it from the Explorer link on the connection's Metadata tab, or follow the Explore Data button on any field-mapping or filter-editing surface.

Layout

The explorer has two panels:

Panel	Purpose
Tables (left)	A searchable tree of every table the connection exposes. Includes both adaptor-discovered tables and any hardcoded metadata tables. Expanding a table reveals its Description and Fields, plus Query and Relationships actions.
Workspace (right)	Shows one of two views for the selected table: the data view (Query Builder over Results) or the Relationships diagram. The Query and Relationships actions in the table tree choose which view is shown.

In the data view, the Query Builder (top) and Results (bottom) panes are independently resizable, and the Query Builder pane auto-sizes to fit the current filter so you keep maximum screen space for results.

Browsing Tables

The table tree on the left lists every table the connection knows about, organised into groups: Saved Views at the top (if any exist — see Saved Views below), then Discovered Tables, then Hardcoded Adaptor Tables. Click a table name to select it as the active table and open the data view; the URL updates so you can bookmark or share a deep link straight to a table.

Expand a table with its chevron to reveal inline detail and per-table actions:

• Description — the table's description from the adaptor metadata.
• Fields — the table's fields, loaded on first expand, with primary-key and display-field markers.
• Query — selects the table and opens the data view (the same as clicking the table name).
• Relationships — opens the table-relationships diagram in the right pane. See Table Relationships below.

If the connection cannot be reached when the explorer opens, the table tree is replaced with a connection-failure card listing the error and offering a Retry action. The retry forces a fresh connection test before re-fetching the table list, so you can fix a credential problem on the connection itself and recover without leaving the page.

For tables with a (hidden) flag in the adaptor metadata, use the search box at the top of the tree to filter the list quickly. The Discovered Tables list is paginated for connections that expose hundreds of tables, with a search box scoped to discovered tables only. Any discovered table that already has one or more saved views also shows a small bookmark indicator with a count on the right edge of its row — clicking it jumps straight to the Saved Views section, filtered to that table.

Building a Query

The Query Builder uses the same Filter component as the Migrate Records step. Four filter modes are available:

• None — fetches every record (subject to the system's defaults — typically the first 100 records on most adaptors).
• Basic — exact-match field = value rows joined with AND. Pick a field, pick a value, repeat. The simplest mode for narrowing down by a single attribute.
• Standard — the full Precision Bridge filter language, including operators (>, <, contains, in, is null, ...), boolean combinators (AND, OR, NOT), and formula-based values. See the Filtering category for the language reference.
• Native — passes a raw query directly to the source system's query engine (for example, a ServiceNow encoded query). Use when the source system supports a query construct PB doesn't translate, or when you want the source to optimise the query natively.

Click Run to execute the query against the connection. The Results panel below populates with whatever the source returned. The initial state shows an empty-state message — the explorer never fetches records until you click Run, so opening the explorer never touches the source system unless you ask it to.

Required Filters

Some endpoints declare required filter parameters — for example, a parent ID for a child-scoped table. When you pick a table whose extract endpoint has required parameters, the Results panel shows an empty-state message listing the missing parameters with Add Filter buttons. Click one to insert the parameter as a Basic filter row pre-populated and ready for a value.

Re-Running After Edits

Edits to the filter don't run automatically — click Run (or Clear to reset) when you want to re-fetch. The Run button mirrors what an actual procedure would do, so what you see here is what you'll get at execution time.

Inspecting Records

Click any row in the Results panel to drill into a single record. The record view shows:

• Fields tab — every field with its raw and formatted value. Long values open in a side detail dialog showing the raw value, formatted value, type label, and any choice mappings the adaptor declares for that field. JSON-string values are pretty-printed automatically. Use the prev/next arrows to walk through records while preserving the current query in the URL.
• Attachments tab — for adaptors that support attachments, lists every file attached to the record with size, MIME type, and a download action. Inline attachments (referenced via field metadata) are surfaced here alongside attachments fetched from a dedicated attachment endpoint.

Table Relationships

The Relationships action opens an entity-relationship diagram for the table in the right pane, in place of the data view. The diagram is read-only and is built entirely from connection metadata — opening it never queries records.

Reading the Diagram

The focal table sits at the centre with all of its columns listed. Each related table — any table the focal table references through a Reference or List field — is drawn as a connected card. Related cards show their primary key only by default; use the chevron in a card's header to expand it to its full column list.

Each column row shows the column name and a metadata summary:

• The type, with a size hint where one applies (for example string(40), choice(12)).
• PK for the primary key and NN for a required (not-null) column.
• FK → target_table for a foreign key, naming the table it references.

Hover a column's metadata to open a panel with the full type name, description, nullability, and — for choice fields — the available or suggested values. A self-reference (a field pointing back at its own table) is shown as a column row with a loop icon and a → this table target rather than a looping edge.

Relationship Notation

Edges use crow's-foot (information-engineering) notation to convey cardinality:

• A Reference field is a many-to-one relationship: many records on the focal side, one on the referenced side.
• A List field is a one-to-many relationship: one record on the focal side, many on the referenced side.

An optional (nullable) foreign key is drawn with a dashed line and an open-circle marker; a required foreign key uses a solid line and a bar marker. Tables that exist mainly to link other tables — where most non-key columns are foreign keys — are drawn with a dashed border and a diamond icon, the convention for an associative (junction) entity.

Diagram Scope

The diagram shows as much of the schema as is useful for the connection size:

• For a connection with 15 or fewer tables, the diagram shows the complete ERD — every table and every relationship — with the table you opened it from highlighted. A Complete ERD badge appears in the header.
• For larger connections, the diagram shows the focal table and the tables it directly references. This keeps the view legible on connections that expose hundreds or thousands of tables.

Interacting with the Diagram

• Recentre — right-click a related table and choose Re-centre on this table to make it the focal table. The selection across the rest of the explorer updates to match, so switching to the data view shows the same table.
• Show data — right-click a table and choose Show data to open that table's data view in a new browser tab.
• Highlight a relationship — click a related table to dim the rest of the diagram and reveal the foreign-key column and referenced primary key on the connecting edge.
• Navigate the canvas — pan, zoom, and use the minimap and controls in the corner. Drag a card to reposition it.

Columns and Layout

The Results DataTable supports the standard DataTable controls:

• Column visibility — toggle individual columns on or off via the column manager popover.
• Column reordering — drag a visible column header to move it. The order is persisted alongside visibility via session storage, so you keep your preferred layout between explorer visits.
• Column dialog for wide tables — when a table has many columns, the manager swaps to a full dialog with Available and Selected panes, drag-to-reorder, search, and bulk move buttons. The default cap on visible columns at any one time is 100; columns past that point are auto-hidden when the explorer loads, and you can promote them via the column dialog.
• Pagination — page size and current-page controls at the foot of the table. The explorer supports unknown-total pagination (next/prev/first only) for sources where the total record count isn't cheap to compute.

Saved Views

A saved view captures the current table, column layout, and optional filter as a named shortcut you can reload with one click. Use saved views to avoid re-running the same search-table → select → run → tweak-columns sequence each time you need to inspect the same slice of data.

What a View Stores

A view records the active table name, the visible columns in their displayed order, and the current query (if any). Reloading a view selects the table, applies the saved column layout, restores the filter into the Query Builder, and auto-runs — so you land back on the same results without an extra click.

Columns absent from a saved view are hidden on reload, regardless of any in-progress column changes. New columns added to the source table (after a metadata refresh) are hidden by default when an older view loads, so a saved view stays a curated snapshot rather than silently widening.

Saving a View

Click the Save button in the data-table controls (next to Refresh and Close). A dialog asks for a name; pick something descriptive (e.g. Open Incidents, My Assignments). The default name is generated from the current table — for tables with punctuation in the name (such as Remedy's HPD:Help Desk) the disallowed characters are stripped automatically, so the default is always valid.

View names must use only letters, digits, spaces, dashes, underscores, and parentheses. Names must be unique within a connection (see overwriting below).

Overwriting an Existing View

If you load a saved view and then refine its columns or filter, clicking Save again pre-fills the dialog with the view's name. Confirming overwrites the existing view in place — useful for iterative refinement.

You can also type any existing view's name into the dialog to overwrite it. The dialog shows an inline warning when the entered name matches an existing view, and the proceed button changes from Save to Overwrite with destructive styling.

Loading and Managing Views

The Saved Views group at the top of the table tree lists every view for the connection. Left-click a row to load it; right-click for Rename and Delete actions (delete prompts for confirmation). The active view is highlighted in the tree while loaded — the underlying table row stays neutral so the highlight doesn't appear in two places at once.

To switch from an active view back to the bare table, click the table's row in the Discovered Tables section — the view deactivates, the filter clears, and the data pane returns to its "Click Run to load records" state, just like a fresh table selection.

URL and Navigation

Loading or saving a view adds a view=<id> parameter to the explorer URL, so reloading the page or sharing the link returns directly to the view. The parameter also threads through record-viewer navigation: clicking a row in a view-driven results table forwards the view id, and the record viewer's Back button returns to the originating view rather than the bare table.

If a view is later deleted but a stale link still references it, the explorer falls back to opening the table named in the URL.

Per-Connection Storage

Saved views are stored on the server, per connection. Anyone using the same connection sees the same set of views. If you want a view that's specific to your workflow, give it a personal name.

Licensing

The explorer only operates against licensed connections. If your subscription does not include the connection's source/target role, the connection is hidden from the explorer's connection picker and the explorer page redirects you back. Trial licences are unrestricted and see every connection.

When to Use the Explorer

• Before building a Migrate Records step: verify the source table has the records you expect, the field names you remember, and the values your filter will need to match.
• While authoring a filter: prototype the filter in the explorer, confirm it returns the right shape, then copy it into the Migrate Records step.
• While debugging a failed migration: spot-check one of the source records that failed to see exactly what PB saw — including the raw value, the formatted value, and any attachment metadata that influenced the failure.
• When validating a custom adaptor: confirm a new endpoint returns the records and fields you wired up, and that field-formatting schemes resolve correctly.
• When learning an unfamiliar schema: open the Relationships diagram to see how a table relates to others before deciding which tables a migration needs to touch.

Related Documentation

• Creating Connections — set up a connection before opening the explorer.
• Filtering — full reference for the filter language used in the Query Builder.
• Step Type: Migrate Records — uses the same filter language and field model.