Designing a Blueprint CSV

Once your Blueprint CSV is ready, you can bring it into Insycle in two ways:

1. Upload it directly to Data Logic: navigate to Data Integrity > Data Logic, and under 1. Pick Blueprint, select Create from CSV.
2. Upload it as a standalone Blueprint first: navigate to Data Integrity > Blueprints, and use the upload flow there. You can then select it later from 1. Pick Blueprint > Select Existing in any Data Logic template.

No special formatting is required beyond a standard CSV structure: one header row followed by data rows.

• The first row is the header row. Each column header is the name you'll reference when mapping the Blueprint to your CRM fields in Data Logic.
• Each data row defines one matching condition. When Data Logic evaluates a record, it checks the record against each row from top to bottom and applies the first row for which all input conditions are satisfied. Row order matters — see Row Order and First-Match-Wins below.
• There is no required column order. Input and output columns can appear in any order, but grouping inputs on the left and outputs on the right makes the table easier to read and maintain.

The CSV pictured above shows a Territory Assignment example. Rows 2–3 match US companies by state and industry (California/Tech and New York/Finance), assigning region, owner, tier, and segment accordingly. Row 4 matches all US companies in Texas, regardless of industry, and assigns AMER-Central and Mid-Market with no segment value. Row 5 matches all UK companies, regardless of state or industry, and assigns EMEA, Enterprise, and Strategic.

Column headers are the identifiers Data Logic uses to bind Blueprint columns to CRM fields. A few conventions to follow:

• Use clear, descriptive names. Headers like "Country," "Employee Count," and "Sales Tier" are easier to map and maintain than abbreviated or ambiguous names.
• Include "Input," "Output," the input matching criteria, or the output update condition to help identify each column's purpose.
• When multiple columns map to the same CRM field — the pattern used for OR matching against a single field — differentiate the headers by the matching criteria each column uses. For example, if three columns all map to Job Title with different criteria, name them "Job Title Exact," "Job Title Starts With," and "Job Title Contains." This makes each column's purpose explicit and prevents mapping errors.
• Column headers are case-sensitive when referenced in Data Logic. Use consistent casing across versions of the same Blueprint to avoid remapping after an upload.

In this example, the column headers reflect the CRM field names, with the input row match options and output row update conditions in parentheses (e.g., Attribution Channel (Always)).

The image above shows part of the Blueprint CSV for the Lead Source Harmonization example, with column headers reflecting each column's CRM field name and its matching criteria or update condition in parentheses — Lead Source (Contains), Lead Source Original (Exact), Referrer Domain (Ends With), Normalized Lead Source (Always), Attribution Channel (Always), Original Preserved (Field Non-Empty), and Review Flag (Output Non-Empty).
 

In another example, the column headers specify whether each column is used for input or output mapping, as well as the input row match options (e.g., INPUT Job Title (Contains)).

The image above shows a Blueprint CSV for a Job Title normalization example, with column headers indicating each Blueprint column's role and matching criteria — INPUT Job Title (Exact), INPUT Job Title (Starts With), INPUT Job Title (Contains), and OUTPUT Normalized Title. Each row populates only the input column relevant to its matching criteria, leaving the other two input columns blank.

An input column sets a condition — a value, or range of values, that a record's CRM field must match for a Blueprint row to apply. 

An output column sets a value to write to a CRM field once a row has matched. A single Blueprint row typically has several input columns (all of which must be satisfied, or one of which must be satisfied, depending on whether they're bound to the same or different CRM fields — see OR and AND Matching Patterns below) and one or more output columns that only take effect once that row is selected.

Any column in a Blueprint can be configured as an input, an output, or both — this is determined by how you map the column in Data Logic, not by anything in the CSV itself.

You can configure a column used as an output with an update condition and a fallback value in Data Logic. Update conditions control when the field is written to — for example, only when the field is currently empty, or only when the matching Blueprint row contains a value in that column. Fallback values are written to a field when no Blueprint row matches the record at all.

The image below shows the 3. Output Mapping step in Data Logic, with the Blueprint column Normalized SKU mapped to the CRM field SKU, using the Always update condition and a Fallback Value of UNCLASSIFIED. With Always configured, the SKU field is overwritten with the matched row's output on every match. Fallback Value covers the separate case where a record doesn't match any Blueprint row at all — Always only fires on a match, so without a Fallback Value, an unmatched record's SKU field would be left untouched rather than flagged.

A CRM field can serve as both an input and an output in the same Blueprint. For example, a Job Title column can be used to match records based on their current job title value and, in the same run, write a standardized job title back to the same CRM field — letting Data Logic identify and update a field in a single pass.

The image above shows a Blueprint CSV that maps the same CRM field, Job Title, as both an input and an output. The INPUT Job Title (Exact) column defines the current values to match against, and the OUTPUT Normalized Title column defines the standardized value to write back to that same field once a row matches — for example, a record with a Job Title of CFO is normalized to Chief Financial Officer.

The image above shows the Data Logic input and output mapping that puts the Blueprint pictured above into effect. In 2. Input Mapping, the Blueprint column INPUT Job Title (Exact) maps to the Salesforce field Title using Exact matching with Case Insensitive enabled. In 3. Output Mapping, the Blueprint column OUTPUT Normalized Title is mapped back to that same Title field, using the Always update condition — so a record matched on its current Job Title has that same field overwritten with the normalized title in a single pass.

Row order determines which row applies when a record's data could satisfy more than one row's conditions. Data Logic evaluates rows top to bottom and applies the first row whose conditions are fully satisfied — once a match is found, no further rows are checked, even if a later row would also match. This means you must always place more specific conditions above more general ones. A broad row placed too high in the Blueprint will shadow every more specific row beneath it, since a matching record always resolves against the first row it satisfies and never reaches the rows that follow.

Example: Job Title Normalization

A Blueprint with this structure uses two columns mapped to the same Job Title field — Exact for known titles, and Contains as a broader fallback:

The last row is deliberately broad — it catches any title containing "VP" that wasn't already caught by the four exact matches above it. Row order is what makes this safe: because the exact-match rows for "VP Sales" and "Vice President of Sales" come first, records with those exact titles are normalized precisely before the broader "Contains VP" row ever gets a chance to apply. If you moved the broad row to the top, every title containing "VP" — including "VP Sales" — would match it first, and the two more specific rows below would never be reached.

Example: Employee-count-qualified Industry Segmentation

This Blueprint structure segments Financial Services companies differently depending on size:

This Blueprint segments Financial Services companies into three tiers by size. The first row catches the largest companies using the open-ended 100000+ notation. The second row captures a specific bounded range — 10000-99999 employees — using the same inclusive-lower, exclusive-upper convention covered under Numeric and Date Ranges above.

The third row is the broadest, catching any Financial Services company not matched by the two rows above — including companies with fewer than 10,000 employees, but also companies with no Employees value on record at all. Its Employees column is intentionally left blank, with the Blank Cell Matches Any input match option enabled, so it acts as a true wildcard rather than restricting the row to a particular range. The Tier value here is deliberately "Unclassified" rather than a size-based label like "Emerging" — a blank cell doesn't tell you the company is small, only that it wasn't caught by a more specific row above, which may just as easily mean the data is missing as it does that the company is genuinely smaller. A wildcard catch-all row is a statement about coverage — it guarantees every record reaches some outcome.

Review row order carefully before uploading, especially when your Blueprint mixes broad and narrow conditions.

How multiple input columns in the same row combine depends on whether those columns are bound to the same CRM field or different ones:

• Columns bound to different CRM fields combine as AND. All of them must be satisfied for the row to match. This is the standard pattern for a Blueprint like Territory Assignment, where Country, State, and Industry are three separate inputs that must all match together.
   
• Columns bound to the same CRM field combine as OR. The row matches if any one of them is satisfied. This is how a single Blueprint row can hold several ways of expressing the same match — for example, mapping Job Title (Exact), Job Title (Starts With), and Job Title (Contains) all to the same Job Title field, with each row populating only the column relevant to that row and leaving the others blank.

These two patterns rely on opposite blank-cell behavior, and it's important not to mix them up:

• In an OR pattern (same field, multiple columns), a blank cell in an unused column is skipped natively — no Match Option override is needed, regardless of matching criteria, including Exact.
    Do not enable Blank Cell Matches Any on same-field OR columns — doing so turns that blank cell into a wildcard that's always satisfied, causing the first row to incorrectly match every record regardless of whether its own populated condition is actually met.
   
• In an AND pattern (different fields, same row) where a row is intentionally left sparse to act as a broader catch-all, a blank cell under non-Exact criteria blocks the row entirely unless Blank Cell Matches Any is explicitly enabled on that column. See How Blank Cells Are Evaluated in Blueprint Input and Output Columns for the full explanation of this behavior.

The table below shows how this plays out for two real Blueprints — notice that only the AND pattern's columns need Blank Cell Matches Any enabled in Data Logic once you get to mapping.

Example: Job Title Normalization, same-field OR pattern

This Blueprint uses three input columns — Job Title Exact, Job Title Starts With, and Job Title Contains — all mapped to the same CRM field, Job Title:

• Job Title field, Exact matching, Blank Cell Matches Any match option not enabled — populated on rows matching a known exact title; left blank elsewhere
• Job Title field, Starts With matching, Blank Cell Matches Any match option not enabled — populated on rows matching a title prefix; left blank elsewhere 
• Job Title field, Contains matching, Blank Cell Matches Any match option not enabled — populated on rows matching a broader title fragment; left blank elsewhere

The image above shows a Blueprint CSV using the same-field OR pattern for Job Title normalization. Three input columns — Job Title Exact, Job Title Starts With, and Job Title Contains — all map to the same CRM field, and each row populates only one of the three, leaving the other two blank. For example, row 3 leaves Job Title Exact and Job Title Contains blank and populates only Job Title Starts With with "VP," matching any title beginning with that prefix and normalizing it to "Vice President."

The image above shows the Data Logic input mapping that puts the Blueprint pictured above into effect. All three Blueprint columns — Job Title Exact, Job Title Starts With, and Job Title Contains — are mapped to the same HubSpot field, Job Title, each using its own matching criteria (Exact, Starts With, and Contains, respectively). No Match Options are enabled on any of the three columns. Because these columns share a CRM field, a blank cell in any of them is skipped natively for that row — the row matches based on whichever one column is populated, without needing Blank Cell Matches Any enabled anywhere.

Example: Territory Assignment, different-field AND pattern (sparse rows)

This Blueprint uses three input columns — Country (Exact), State (Exact), and Industry (Contains) — each mapped to a different CRM field:

• Country field, Exact matching, Blank Cell Matches Any match option enabled — populated on rows requiring a specific country; left blank on rows meant to apply across any country
• State field, Exact matching, Blank Cell Matches Any match option enabled — populated on rows requiring a specific state; left blank on rows meant to apply across any state within a matched country
• Industry field, Contains matching, Blank Cell Matches Any match option enabled — populated on rows requiring a specific industry; left blank on rows meant to apply across any industry within a matched country and state

The image above shows the Territory Assignment Blueprint CSV, illustrating the different-field AND pattern with sparse rows. Rows 2 and 3 populate all three input columns — Country, State, and Industry — for a fully specific match. Row 4 leaves Industry blank, matching any US company in Texas regardless of industry. Row 5 leaves both State and Industry blank, matching any UK company regardless of state or industry. Region, Territory Owner, and Sales Tier are assigned on every matched row; Segment is only populated on Rows 2 and 3, since its Output Non-Empty update condition skips writing a value when the Blueprint cell itself is blank.

The image above shows the Data Logic input mapping that puts the Blueprint pictured above into effect. All three Blueprint columns — Country (Exact), State (Exact), and Industry (Contains) — are mapped to their corresponding CRM fields, each with Case Insensitive, Blank Cell Matches Any, and Trim Whitespace enabled. Because these three columns are bound to different CRM fields, they combine as AND — a record must satisfy every populated condition in a row. Blank Cell Matches Any is what allows Rows 4 and 5's blank Industry and State cells to act as true wildcards rather than blocking the row, letting those rows apply broadly across an entire country or state without a separate row for every possible combination.

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.

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.

Two matching criteria — Number Between and Date Between — use a range format with specific formatting rules.

Number Between

Ranges use a hyphen-separated format: 100-1000, 1000-10000. The lower bound is inclusive, and the upper bound is exclusive, so a value of 1000 matches the row 1000-10000, not 100-1000. For open-ended ranges with no upper bound, use the + notation: 3000+ matches any value greater than or equal to 3000.

Date Between

Ranges use a to-separated format: 2026-01-01 to 2026-04-01. The lower bound is inclusive, and the upper bound is exclusive, following the same rule as Number Between. ISO 8601 formats are recommended: yyyy-MM-dd for dates and yyyy-MM-dd'T'HH:mm:ss for datetimes. 

The image above shows the Blueprint Preview in the Data Logic module for Renewal Risk Scoring, illustrating both Date Between and Number Between formatting in the same Blueprint. Contract End Date (Date Between) uses the to-separated format — 2026-01-01 to 2026-04-01 on Row 2, and 2026-04-01 to 2026-07-01 on Row 4 — with each range's lower bound inclusive and upper bound exclusive, so the two ranges tile without overlapping. ARR and Last Login Days (both Number Between) use the hyphen-separated format, such as 50000-100000 and 30-1000, following the same inclusive-lower, exclusive-upper convention.

Other common date formats are also accepted for Date Between, as well as for the other date-matching criteria — Before, After, At or Before, and At or After. See Configuring Data Logic Input Mapping for the full Matching Criteria reference. Data Logic attempts to parse a date value in the following order:

• yyyy-MM-dd
• MM/dd/yyyy
• dd/MM/yyyy
• yyyy/MM/dd
• MM-dd-yyyy
• dd-MM-yyyy
• yyyy-MM-dd'T'HH:mm:ss
• yyyy-MM-dd'T'HH:mm:ss.SSS
• yyyy-MM-dd HH:mm:ss

Because several of these formats are ambiguous with each other — MM/dd/yyyy and dd/MM/yyyy can both parse a date like 03/04/2026 correctly, just with different meanings — using ISO 8601 (yyyy-MM-dd) removes any doubt about which format was intended. See the ISO 8601 standard for more detail.

When authoring a Blueprint, write values using the same labels and names you see in your CRM — not the underlying API values or record IDs your CRM stores internally. Insycle automatically resolves human-readable values to their technical equivalents when matching records and writing results.

Picklist Fields

Use the label exactly as it appears in your CRM dropdown. For example, if your Industry field shows Banking & Finance in the interface, write "Banking & Finance" in your Blueprint. Insycle automatically resolves it to the underlying API value. Matching is case-insensitive, so "banking & finance" and "BANKING & FINANCE" resolve to the same option. If you built your Blueprint using API values directly—for example, "banking_and_finance"—those also work; Insycle checks both the label and the API value.

Owner and Reference Fields

Use the person's name exactly as it appears in your CRM. Insycle looks up the corresponding owner ID and uses it when writing the assignment. If two users share the same name, Insycle returns an error rather than guessing — the Blueprint row will not match records until the ambiguity is resolved. If a value cannot be resolved, Insycle passes it to the CRM as-is; the CRM will typically reject it at write time, which surfaces the problem without silently corrupting data.

AI-generated Blueprints

When you use Generate with AI, the same resolution logic applies automatically. Picklist cells show the label, and owner cells show the person's name — no additional configuration is needed.

Example and reference Blueprints are available directly in the Data Logic module under:

• 1. Pick Blueprint > Explore Examples or 
• 1. Pick Blueprint > Use Reference Data

Rather than building a Blueprint from scratch, you can use either as a starting point and tailor it to match your specific field values, scoring criteria, or business rules.

To use an example or reference Blueprint as a starting point:

1. In Data Integrity > Data Logic, under 1. Pick Blueprint, select Explore Examples, or Use Reference Data.
2. Select the Blueprint you want to use. Click the Preview icon to review the table structure and column values before proceeding.
3. In the Blueprint Preview, click Download to save the Blueprint as a CSV file.
4. Open the CSV file and tailor the values to match your CRM data — update field values, scoring ranges, date ranges, owner assignments, or any other values specific to your business.
5. When your CSV is ready, navigate to Data Integrity > Blueprints and upload it as a new Blueprint.
6. Return to Data Integrity > Data Logic, select your uploaded Blueprint under 1. Pick Blueprint > Select Existing, and configure your input and output mapping.

 Note: Some CRM fields referenced in the example or reference Blueprints may not exist by default in your CRM and will need to be created as custom fields before configuring your input and output mapping.

If no Blueprint row matches a record, Data Logic applies the fallback values configured in your output mapping rather than leaving those fields empty. When tailoring a Blueprint, consider what default state non-matching records should receive and configure fallback values in your output mapping accordingly. For more information, see What Happens When a Record Does Not Match Any Blueprint Row? in the FAQ article.

In the Transform Data module, when a map function is configured in step 2, a blue Export button appears at the end of that row. Clicking it exports your mapping configuration as a Blueprint CSV file, ready to upload to the Data Logic module.

This is useful when your mapping logic has grown to a scale that's better managed continuously in Data Logic — where it can run automatically across all records and be updated at any time by editing the CSV.

For example, a Company Name mapping configured in Transform Data might look like this:

The image above shows the 2. Configure Changes step in Transform Data showing the Company Name field with four Map: Terms rows — CU → Credit Union, FCU → Federal Credit Union, CMNTY → Community Bank, and CB → Community Bank. A blue Export button (highlighted with a teal arrow) appears at the end of the first row.

Clicking the Export button downloads a CSV with your mapping values:

The image above shows a spreadsheet of the exported CSV with two columns — "Existing" (column A) and "Mapped" (column B) — and four rows of data: CU/Credit Union, FCU/Federal Credit Union, CMNTY/Community Bank, and CB/Community Bank.

Before uploading the CSV to Data Logic as a Blueprint, rename the column headers to reflect your actual CRM field names. In this example, you would rename "Existing" to "Company Name" (the input field) and "Mapped" to something like "Company Name Standardized" (the output field), or whatever names make the mapping clear in your Blueprint. You could map the output field to the same Company Name field as the input to overwrite the existing value. Column headers are what Data Logic uses to bind Blueprint columns to your CRM fields.

The image above shows a spreadsheet of the updated CSV with two columns — "Company Name" (column A) and "Company Name Standardized" (column B) — and four rows of data: CU/Credit Union, FCU/Federal Credit Union, CMNTY/Community Bank, and CB/Community Bank.

A few additional things to know about the export:

• If you've used pipe delimiters to define multiple existing text variations in a single row (for example, NY|NYC|New York City → New York), the export automatically splits those into individual rows, each with a single value.
• The export does not convert API values to labels. For picklist fields or reference fields like owner, the CSV will contain the same values shown in Transform Data. Data Logic works with either API values or labels, so the Blueprint will function correctly either way.
• The following map functions do not support the export: Map: US Zip Postal Code to US State (abbrev.), Map: US Zip Postal Code to US City, and Map: US Phone Area Code to US State (abbrev.).

In the Cleanse Data module, when you've identified a field with variations that need management, you can export the values as a Blueprint CSV to use with the Data Logic module. Blueprints scale to thousands of values, enforce mapping across all records continuously, and update instantly with a simple CSV edit.

1. Select the field under Step 2. Explore Field.
2. Click the Layout tab, then drag it into the field in the Visible Fields list.

3. In Step 4. Value Distribution, change the Rows per page so that all the values are visible at once (without needing to click through pages). For example, if the field has 55 different values, change Rows per page to 100.

   

4. Click the blue download icon next to the 4. Value Distribution heading to export the CSV.
5. Insycle automatically adds a Mapped column to the exported CSV. Use this column to map each incorrect value to its correct counterpart, upload the CSV as a Blueprint, and configure Data Logic to automatically standardize these values ongoing.