Use this article to set which CRM fields a matched Blueprint row writes to, choose the right update condition for each one, and decide between a Fallback Value and a Fallback Row for records that don't match.
Once you have the input mapping for your Blueprint set in Step 2 of the Data Logic module, Step 3. Output Mapping is where you specify which CRM field each Blueprint output column should write to, and under what conditions that write should happen.
Getting to Step 3. Output Mapping
- Navigate to Data Integrity > Data Logic.
- Complete 1. Pick Blueprint and 2. Input Mapping.
- Click 3. Output Mapping to expand this step.
The image above shows the Data Integrity nav with Data Logic selected, and the Territory Assignment template's Output Mapping step expanded.
The Output Mapping Fields
Each row in Output Mapping binds one Blueprint column to one CRM field, and defines when that field gets written:
- Blueprint Column — the output column whose value will be written.
- CRM Field — the record field being written to.
- Update Condition — when the write happens (see Update Conditions Reference below).
- Fallback Value — an optional value written when no Blueprint row matches the record at all, subject to the same update condition configured for that field.
Add additional output columns with + Output. Use Test to check your full mapping against a real record before running the template.
The image above shows 3. Output Mapping of the Data Logic module for a Job Title Normalization and Persona Assignment template, with four Blueprint columns mapped to CRM fields— Normalized Title (Always) mapped to Job Title, Persona (Always) mapped to Persona, Seniority (Output Non-Empty) mapped to Seniority, and Department (Field Empty) mapped to Department.
Update Conditions Reference
An update condition controls when a matched row's output value is actually written to the CRM field. Data Logic offers four:
Always writes the Blueprint row's output value unconditionally, on every match. If that output cell is blank, the field is actively cleared — this is a real write of an empty value, not a no-op.
Field Empty writes only if the CRM field currently has no value. Because of that gate, a blank output cell under Field Empty has no observable effect in practice — there's no scenario where it would visibly change anything, since the condition can't fire against a field that already has a value.
Field Non-Empty writes only if the CRM field currently has a value — but it's worth understanding as two separate steps, since its name only describes one of them: a gate (does the CRM field currently have a value?) and a write (whatever the Blueprint row's output cell contains, once that gate is satisfied). The name describes the gate, not a promise about what gets written — a blank output cell still passes through once the gate opens, and erases the existing value. This is a different mechanism from Output Non-Empty, which gates on the Blueprint cell instead of the CRM field.
Output Non-Empty writes only if the matching Blueprint row's output cell itself contains a value. If that cell is blank, the update is skipped entirely, and the existing value is left untouched — this is the one condition that protects a field from being cleared by a blank Blueprint cell.
For the full explanation of how blank cells interact with each of these conditions, including worked examples, see How Blank Cells Are Evaluated in Blueprint Input and Output Columns.
The image above shows the Update Condition dropdown for a Job Title Normalization and Persona Assignment template, open on Normalized Title's row, with all four available conditions listed in the Data Logic module
Fallback Row vs. Fallback Value
When no Blueprint row matches a record, Data Logic needs to know what to do with it. There are two ways to define that behavior, and they work differently:
- A Fallback Value is configured per output field in the Data Logic output mapping. It applies a value to any record that matched no row in the Blueprint, subject to the same update condition configured for that output field.
- A Fallback Row is the last row in the Blueprint CSV with all input columns left blank. When Blank Cell Matches Any is enabled on all input columns, a blank cell matches any value — so this row catches every record that didn't match an earlier row, and is evaluated like any other matched row. Each output cell in the fallback row can hold an independent value, the same way any other Blueprint row works.
| Fallback Value | Fallback Row | |
|---|---|---|
| Where it lives | Data Logic template configuration | Blueprint CSV |
| Respects update conditions | Yes | Yes |
| Versioned with the Blueprint | No | Yes |
| Visible in Blueprint preview | No | Yes |
| Requires Blank Cell Matches Any | No | Yes, to act as a true catch-all |
| Output value can vary per field | No — one fixed value per field | Yes — each output cell is independent |
When to Use a Fallback Value
Use the Data Logic fallback value when you want a simple, self-contained default without modifying the Blueprint — for example, when working with a Blueprint you didn't author, a shared or library Blueprint you can't modify, or when you want to define fallback behavior at the template level without changing the Blueprint itself.
The image above shows a Fallback Value configured directly in Data Logic's Output Mapping, with no changes made to the Blueprint itself. The Normalized SKU column is mapped to the CRM field SKU with a Fallback Value of UNCLASSIFIED — so a record that doesn't match any Blueprint row still receives a value, without requiring a Fallback Row to be added to the Blueprint's own structure. This makes it a good fit when working with a Blueprint you don't want to modify, such as a shared or library Blueprint.
When to Use a Fallback Row
Use a Blueprint fallback row when the Blueprint is collaboratively reviewed or versioned, and you want the fallback logic visible alongside the rest of the rules — in the Blueprint preview, in version history, and reviewable by anyone with access to the Blueprint. A Fallback Row is also preferable when the fallback needs to produce coordinated outputs across multiple fields from a single row, just as any other matched row does.
The image above shows the Blueprint Preview in the Data Logic module for Territory Assignment, with the final row highlighted as the Fallback Row. This row leaves Country, State, and Industry all blank, so with Blank Cell Matches Any enabled on each of those columns, it catches every record that didn't match an earlier row. Its outputs are visible and reviewable alongside the rest of the Blueprint's rows — Region is set to Unassigned, Territory Owner to unassigned-pool@company.com, and Sales Tier to Review — the same coordinated, multi-field output any other matched row produces.
Avoid Using Both for the Same Output Field
If a Fallback Row is present and Blank Cell Matches Any is enabled on all its input columns, every record will match the Fallback Row — the Fallback Value will never fire. Configuring both creates the appearance of a safety net that never activates, which can mislead anyone reviewing the template later.
Next Steps in Configuring Data Logic
With your output mapping configured, the next step is deciding which records Data Logic should evaluate. Continue to Filtering Which Records Data Logic Evaluates.
This article covers one part of the Data Logic configuration. For details on the other settings available in the module, see these related articles:
- Designing a Blueprint CSV
- Generate a Blueprint with AI
- Picking a Blueprint for Your Data Logic Template
- Configuring Data Logic Input Mapping
- How Blank Cells Are Evaluated in Blueprint Input and Output Columns
- Filtering Which Records Data Logic Evaluates
- Testing Data Logic with Test Matching and Near-Miss Detection
Additional Resources
Frequently Asked Questions
- Check out the Data Logic & Blueprints FAQs to find answers to common questions about creating, editing, and applying Data Logic and Blueprints.
Related Help Articles