Chapter 3: Exploring Core Features
Status workflow, notation types, transformation logic, indicators, source groups, and navigating a large map.
Chapter 2 covered a small, clean map—a handful of tables, a handful of mappings, one reviewer. Real projects are larger. A healthcare migration might span two hundred target tables and involve a business analyst team, a client SME group, and a developer reading finished mappings months later. The features in this chapter are what make Bridger useful at that scale: a status system that enforces review discipline, a notation framework that keeps every kind of annotation organized, tools for scoping work and grouping complex sources, and navigation aids for working efficiently in a large mapping set.
The Bottom of the Workspace
Before diving in, it helps to name the panes that appear throughout this chapter. The bottom of the workspace is divided into three properties areas, each tied to a panel above it. Below the source tree is the source properties pane; below the target tree is the target properties pane. Each shows a schema information area at the top—name, data type, description, and so on—with a Notations card and an Indicators card below it. Both panes follow selection in their respective trees: click a table or column above and the pane updates to reflect it.
Below the mappings panel is the mapping detail pane. It shows the notations attached to the selected mapping as a row of tabs, with a + tab at the right end for adding new ones. All three panes are covered in full at the end of this chapter in The Bottom Panes in Depth; the names and concepts introduced here are sufficient context for the sections that follow.
The Status Workflow
Every mapping has a status. You saw this briefly in Chapter 2—a status icon sits at the left of each mapping row, and clicking it opens a dropdown. This section covers the full status system: what the statuses mean, how they flow, and what happens when a mapping is approved.
The Default Statuses
A new workbook ships with seven preconfigured statuses. Their colors are visible at a glance in the mappings panel, making the overall health of a project readable without opening individual rows.
| Status | Color | Meaning |
|---|---|---|
| New | White | Created but not yet documented |
| Ready for SME Review | Yellow | Analyst work complete; awaiting internal review |
| Ready for Client Review | Orange | Internal review complete; awaiting client approval |
| Approved by Client | Green | Client has approved; mapping is locked |
| Question/Issue | Red | An open question or blocker has been raised |
| Reopened After Approval | Blue | Previously approved; reopened due to schema or requirement change |
| AI Generated | Purple | Created by AI; not yet human-reviewed |
Status codes are fully configurable in the Configuration area. Teams with different review structures—fewer tiers, additional approval stages, different naming conventions—can modify the defaults to match their workflow.
Status Progression
The expected forward path through review is linear:
New → Ready for SME Review → Ready for Client Review → Approved by Client
Two lateral transitions are normal and expected. Any mapping can move to Question/Issue when a blocker is identified—the convention is to document the question in a Mapping Note before changing the status. An approved mapping can move to Reopened After Approval when schema changes, requirement revisions, or conversion testing findings invalidate the prior approval; this status makes it explicit that something previously signed off has been disturbed and needs fresh review.
The underlying principle is that the migration team documents what should happen, and stakeholders decide what will happen. Status workflow enforces that discipline. For the full methodology rationale, including guidance on running effective review sessions and managing the approval cycle, see the documentation resources at bridger-dma.com.
Approval and Locking
When a mapping reaches Approved by Client, it is locked. All edits are blocked except status changes, which still require confirmation. This prevents accidental modification of formally approved work. If a locked mapping genuinely needs to change—because the target schema changed, or a business rule was revised—the correct step is to set it to Reopened After Approval, make the updates, and walk it back through the review cycle.
Notation Types
Transformation logic is the one notation every mapping requires. But a mapping can carry much more than its logic: open questions, design decisions, validation queries, table-level context, and change history. Bridger organizes all of this through notation types—a configurable set of annotation categories, each with its own format and scope.
The [+] Tab Pattern
When you click a mapping in the mappings panel, the mapping detail pane shows notation tabs for that mapping. A + tab sits at the right end of the row. Click it to add a notation: a dropdown lists the notation types available for the current selection. Choose a type and a new tab appears with an editor appropriate for that format. The + tab stays at the end of the row as tabs accumulate; a mapping can carry multiple notations of different types.
Notation Scope
Not every notation type applies everywhere. Scope determines where a notation type can be attached: to a mapping, to a table, or to a column. When you use the + tab on a mapping, you see the types scoped to mappings. When you access notations through the Notations card in the source or target properties pane, you see the types scoped to the selected table or column. This keeps annotations where they belong—a note about a column's known data quality issues lives on the column, not repeated on every mapping that references it.
Default Notation Types
The following types ship with every new workbook. Each has one of three formats: Text for free-form prose, Code for structured pseudocode, and SQL for validation queries. The editor adapts to the format.
| Type | Format | Scope | Purpose |
|---|---|---|---|
| Transformation Logic | Code | Mappings | The transformation rule—what the conversion program does with this field |
| Mapping Note | Text | Mappings | Supplementary context, rationale, or background for a specific mapping |
| New Row Logic | Code | Target Tables | Logic for determining when a new row should be created |
| Table Note | Text | Tables | Context applicable to the entire table—volumes, relationships, known issues |
| Column Note | Text | Columns | Context applicable to a specific column regardless of how it is mapped |
| Historical Pattern | Text | All levels | Change history—what a mapping used to be and why it changed |
| Test Case: MINUS Query | SQL | Mappings | Validation SQL comparing source and target datasets using MINUS or EXCEPT |
| Test Case: Count Reconciliation | SQL | Mappings | Count-based comparison between source and target |
| Test Case: Default Value Check | SQL | Mappings | Verification that default values were applied correctly |
| Test Case: Manual Review | SQL | Mappings | Documentation for validation checks requiring human judgment |
Notation types are configurable in the Configuration area. Teams can rename types, change their format, add new types, or remove types that don't apply to their engagement.
Transformation Logic in Depth
Transformation logic is the authoritative specification for a mapping: it is what conversion developers code from and what reviewers approve. Chapter 2 showed how to create a transformation logic notation; this section covers the tools that make writing and maintaining logic efficient across a large mapping set.
Logic Templates
Rather than writing transformation logic from scratch each time, Bridger provides a template library. With a transformation logic notation open, right-click in the content area to open the context menu. It presents a two-level cascading list: three top-level categories, each expanding to the individual templates within it. Select any template and its content is inserted at the cursor position. Because insertion is cursor-based, you can build composite logic by positioning the cursor and inserting a second template beneath the first—a validation routine followed by a Case/Switch, for example—combining piece parts rather than writing from scratch each time. Where a template includes a default value field, it is pre-populated automatically from the template definition.
The template library lives in the Configuration area, where you can modify existing templates, add project-specific patterns, and remove templates that don't apply.
Common Functions and Exception Codes
The same context menu provides quick access to common function names and exception codes. Rather than remembering the exact spelling of IsValidDate or the code BADSSN, you can insert them from the menu. This keeps logic consistent across the project—an inconsistently spelled function name or exception code is invisible to automated analysis and harder to search.
Indicators
Indicators are metadata flags attached to tables or columns. Unlike status, which tracks where a mapping stands in the review workflow, indicators track characteristics of the data itself—scope, dependencies, and business priority. They are set independently of mapping work and apply whether or not a table or column has mappings attached to it.
The Default Indicators
Three indicators ship with every new workbook.
| Indicator | Values | Purpose |
|---|---|---|
| Required for Conversion | Yes / No / N/A | Is this table or column in scope for the current conversion phase? |
| Dependent on Configuration | Yes / No / N/A | Does the mapping depend on target system configuration that may not be finalized? |
| Required by Client | Yes / No / N/A | Has the client explicitly identified this as a priority requirement? |
Required for Conversion is the scope management indicator. Setting a table or column to No keeps it visible in the project without treating it as active work—useful for deferred phases or columns present in the schema but excluded from the current conversion. Dependent on Configuration flags items that cannot be finalized until target system setup is complete; these should not be submitted for approval prematurely. Required by Client identifies business-critical items that need early attention in the mapping schedule.
Indicators are configurable. Custom indicators can be defined with any value list and scoped to table level, column level, or both.
Setting Indicators
For an individual item, select a table or column in either tree panel and view its Indicators card in the properties pane. The card shows all defined indicators and their current values; click any value to change it.
For multiple items at once, select the tables or columns you want to update—hold Shift or Ctrl to extend the selection—then right-click and choose Set Indicators. The dialog presents each indicator with a value picker. Any indicator you change is applied to all selected items; indicators you leave unchanged are not overwritten. This makes it practical to scope an entire set of tables or flag a group of columns as client-required in one operation.
Source Groups
Most mappings have a single source column. Sometimes, though, a target column's value can only be derived from multiple source columns together—a full mailing label assembled from name and address columns across different source tables, or a classification code that depends on several columns evaluated as a set. Source Groups make this multi-column dependency explicit in the mapping structure, rather than forcing the analyst to pick one column as the nominal source and bury the rest in notes.
Creating a Source Group
In the source tree panel, select the columns that should form the group—hold Ctrl to select multiple columns. Right-click and choose Create Source Group…. Give the group a name. The group is created and appears in the SOURCE_GROUPS special table in the source panel.
To map a Source Group to a target column, drag it from the SOURCE_GROUPS table just as you would drag a regular column. The resulting mapping uses the group as its source endpoint. The transformation logic for that mapping should document how the grouped columns combine to produce the target value—which column drives the primary value, which contribute conditional logic, and what happens when any member column is null.
Member Resolution
Expanding a group node in the SOURCE_GROUPS table shows its member columns. Each member retains its original table and column identity; the group is a named reference to the collection, not a copy of the data. If the source schema is updated and a member column's definition changes, the group reflects that change automatically.
Deleting a Source Group
Right-click a group in the SOURCE_GROUPS table and choose Delete. If the group is used in any mappings, Bridger asks for confirmation and deletes those mappings along with the group. Reassign any mappings you want to preserve to a different source endpoint before deleting the group.
Navigating a Large Map
A project with hundreds of mappings across dozens of tables requires more than scrolling. The mapping filter dialog and the Show Mappings shortcut are the two primary tools for getting quickly to the rows you care about.
The Mapping Filter Dialog
The mapping filter lets you narrow the mappings panel to a subset of rows based on criteria you specify. Open it from the mappings panel toolbar. The dialog is modal—set your criteria and apply; the mappings panel updates to show only the matching rows. Filter criteria include source and target table names, mapping status, and indicator values, and can be combined: all mappings at New status with Required by Client set to Yes, for example.
To clear an active filter quickly, click the struck-through filter icon in the mappings panel toolbar, next to the filter button. You can also reopen the dialog and reset the criteria there.
Show Mappings
When you want to jump straight to the mappings for a specific table or column, right-click it in the source or target tree panel and choose Show Mappings. The mappings panel filters to show only the mappings involving that item. This is faster than opening the filter dialog when you're already navigating the schema trees and want to follow a specific column's mapping thread.
The Bottom Panes in Depth
Three panes run across the bottom of the workspace. Understanding how they work together makes everything else in Bridger faster to navigate.
Source and Target Properties Panes
The source properties pane sits below the source tree; the target properties pane sits below the target tree. Both have the same structure and behave identically—only the data they show differs.
When a table is selected in the tree above, the pane shows the table's name, database, schema, and description. Two cards appear below: the Notations card, showing any table-level notations attached to that table (Table Note, New Row Logic on target tables, Historical Pattern), and the Indicators card, showing the current indicator values with controls to change them.
When a column is selected, the schema information area expands to include data type, length, precision, scale, nullable flag, and default value. The same Notations and Indicators cards appear below, now reflecting the selected column's annotations and values.
Both panes follow selection continuously—click through the tree and the pane updates with each click. The pane does not scroll the tree to the selected item; it simply reflects whatever is currently selected above it.
Mapping Detail Pane
The mapping detail pane sits below the mappings panel and shows the notations for the selected mapping as a row of tabs. Each tab represents one notation; clicking a tab opens its content in the editor below. The + tab at the right end of the row adds a new notation: clicking it presents the notation types available for mappings, and selecting one opens a new tab with the appropriate editor.
The format of the editor adapts to the notation type—a plain text area for Mapping Notes, a code editor for Transformation Logic, and an SQL editor for test case notations.
The pane also displays additional mapping metadata: the target column's default value rendered in SQL-ready format, and—when the mapping is in an approved state—the approval date.
What's Next
You now have the full toolkit for working at scale: a status system that enforces review discipline, notations organized by type and scope, transformation logic with templates and a consistent exception vocabulary, indicators for tracking scope and priority, source groups for multi-column derivations, and navigation tools for a large mapping set. Chapter 4: Automating Your Workflow builds on this foundation with auto-mapping rules, column reordering, and bulk update operations that reduce repetitive work on large schemas.