Data Logic & Blueprints FAQs

A Blueprint defines the logic — it is the table that stores your business rules as rows and columns. Data Logic is the module that applies that logic to your CRM records. Data Logic binds Blueprint columns to CRM fields, defines how records are matched, sets update conditions for each output, and controls when and how the operation runs. A Blueprint on its own does nothing; it requires a Data Logic configuration to be applied to your data.

A Blueprint is a CSV-based table that defines business logic as rows and columns. Each row represents a condition and its associated outcomes. Input columns define the values used to match records; output columns define the values written to CRM fields when a match is found. Blueprints are used by the Data Logic module to apply that logic to your CRM records.

Yes. Data Logic and Blueprints work with all CRMs supported by Insycle, including HubSpot, Salesforce, and others. Because a Blueprint is simply a CSV table, independent of any specific CRM, the same Blueprint can be referenced by Data Logic configurations across different CRM connections. There is no need to create separate Blueprint files for each CRM — the same logic can be applied to records in any supported CRM using a single Blueprint.

Data Logic can replace many of the workflows teams build specifically to apply conditional logic to CRM fields — territory assignment, lead scoring, job title normalization, field classification, and similar use cases that involve matching records against a set of conditions and updating one or more fields based on the result.

The key advantage is maintenance. When your logic changes, you update the Blueprint table rather than editing workflow branches, reconfiguring conditions, or redeploying anything. For logic that changes frequently — scoring models, territory rules, routing criteria — this can significantly reduce the overhead of keeping your CRM data current.

Data Logic is not a full replacement for all workflows. It is purpose-built for table-driven, multi-field conditional logic. Workflows remain the better choice for processes that involve actions beyond field updates — sending emails, creating tasks, triggering notifications, or branching based on events rather than data conditions.

If your workflow primarily evaluates a record's field values and updates other fields based on the results, Data Logic is likely a cleaner, more maintainable solution. If your workflow does more than that, Data Logic may handle part of the logic while workflows handle the rest.

Blueprints are well-suited for any business logic that can be expressed as a table of conditions and outcomes. Common use cases include persona assignment, UTM normalization, lifecycle-stage enforcement, pricing-tier and discount governance, SKU standardization, and GDPR or consent management. Any logic that evaluates one or more CRM field values and writes one or more output values based on the results is a candidate for a Blueprint.

Data Logic and Transform Data serve different purposes. Transform Data is well-suited for operations on individual field values — formatting, extracting, replacing, or standardizing the contents of a single field at a time. It works field by field and does not use an external table to drive its logic.

Data Logic is the better choice when the outcome for a record depends on a combination of field values evaluated together, when you need to update multiple fields in a single operation based on a matched condition, or when your logic is likely to change over time and you want to manage it by updating a table rather than reconfiguring the module. If your use case involves matching records against structured business logic — territory rules, scoring criteria, classification tables — Data Logic is designed for that.

You can build a Blueprint from a CSV, or generate one automatically with Generate with AI — the right choice depends on whether you want full manual control over the Blueprint structure or want Insycle to build it for you.

Generate with AI

Generate with AI analyzes your CRM field metadata and creates a Blueprint based on your data, a common use case pattern, or your own custom instructions. You don't need to build a Blueprint from a CSV file first. For a complete walkthrough, see Generate a Blueprint with AI.

Build from a CSV

You can also create a Blueprint by uploading a CSV file — either using Create from CSV directly within Data Logic, or by navigating to Data Integrity > Blueprints and clicking Upload.

If you'd rather not build a Blueprint from scratch, you can select an existing one, browse Insycle-provided examples, or use an Insycle-maintained reference dataset instead.

For a full overview of all Blueprint sources, see Picking a Blueprint for Your Data Logic Template.

Once you've mapped a CRM field as an input, it's worth knowing that the same field can also serve as an output in the same Blueprint. For example, a Job Title column can match records based on their current job title value and, in the same run, write a standardized job title back to that same CRM field—letting Data Logic identify and update a field in a single pass. 

See Configuring Data Logic Input Mapping and Configuring Data Logic Output Mapping for how Data Logic mapping works.

A Fallback Row and a Fallback Value are two different ways to tell Data Logic what to do when a record doesn't match any row in the Blueprint. A Fallback Value is configured per output field in the Data Logic output mapping — it applies a single fixed value to any non-matching record, subject to that field's update condition. A Fallback Row is the last row in the Blueprint CSV itself, with all input columns left blank and Blank Cell Matches Any enabled on each — it catches every non-matching record and can write independent, coordinated values across multiple output fields, just like any other Blueprint row.

For a full comparison — including when to use each and why configuring both for the same output field can create a fallback that never fires — see Fallback Row vs. Fallback Value in Designing a Blueprint CSV.

You can use picklist labels in a Blueprint — there is no need to look up or use API values. When authoring a Blueprint, write the label exactly as it appears in your CRM dropdown. For example, if your Lifecycle Stage field shows "Sales Qualified Lead" in the interface, write "Sales Qualified Lead" in your Blueprint. Insycle automatically resolves the label to its underlying API value when matching records and writing results.

Matching is case-insensitive on picklist values, so "sales qualified lead" and "SALES QUALIFIED LEAD" both resolve to the same option. If your Blueprint was built using API values directly — for example, "sales_qualified_lead" — those also work. Insycle checks both the label and the API value, so existing Blueprints built either way keep working without changes.

The same principle applies to owner and reference fields: write the person's name as it appears in your CRM, and Insycle automatically looks up the corresponding owner ID.

For more details see Picklist Values and Owner Names in Designing a Blueprint CSV.

There are two ways to make a row apply broadly without restricting by a particular field, and they behave differently:

1. If you want a column to never act as a condition anywhere in the Blueprint, omit that input column from the mapping entirely in Data Logic. Unmapped columns are not evaluated as conditions, so every row matches based only on the columns that are mapped.
    
2. If you want some rows to ignore a column while other rows still use it for matching, map the column as usual and enable Blank Cell Matches Any on it. With this Match Option enabled, a blank cell in that column acts as a wildcard for that row only — rows that populate the column still match against it normally, while rows that leave it blank skip that condition.

Numeric and date ranges in a Blueprint use specific formats depending on the matching criteria.

For Number Between, use a hyphen-separated format: 500-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 500-1000. For open-ended ranges with no upper bound, use the + notation: 3000+ matches any value greater than or equal to 3000.

For Date Between, 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. Other common date formats are also supported.

Both range types are configured in the Blueprint CSV itself. The matching criteria — Number Between or Date Between — is selected in the Input Mapping in Data Logic when you bind the Blueprint column to a CRM field.

Learn more about Numeric and Date Ranges in Blueprints.

In Data Logic's Generate with AI, 'Data Hygiene Suggestions for Your CRM' and 'Explore Business Logic Examples' are two different paths for generating a Blueprint with AI, and they produce different results when you click Generate.

Data Hygiene Suggestions for Your CRM 

This path analyzes your actual CRM field metadata — including field population, cardinality, and value distributions — and recommends Blueprint use cases based on your specific data. For example, a suggestion for job title classification appears because your data has inconsistent job title variants that the AI detected. A suggestion for country normalization appears because your country field contains multiple spellings of the same value. Because the AI has access to your actual field values, it can generate a complete Blueprint immediately — the rows reflect real values from your data and are ready to review and apply. 

Explore Business Logic Examples 

This path starts from business processes that Data Logic is well-suited for, rather than from your data. The AI checks whether the fields typically needed for each use case exist in your CRM and presents relevant patterns accordingly. These cover multi-field business logic — territory assignment, lead routing, scoring, account health, compliance enforcement, and others. When you generate a Blueprint from a Common use case, the result is a starting point template with rows that reflect your data where possible, plus representative placeholder rows for patterns the AI inferred from the category. The output columns — Territory, Risk Level, and similar — are new columns you will map to your actual CRM fields when you configure Data Logic. You may also want to add, remove, or adjust rows to reflect your specific business logic before running.

Both paths lead to the same Data Logic configuration experience. The difference is how much of the Blueprint is ready to use versus how much you will customize before running it against your records.

Learn more about generating a Blueprint using AI.

Yes, a Blueprint can be regenerated if the results don't look right. On the Preview tab of the Generate with AI popup, click Back to return to the Guide AI tab. Edit the instructions in the Guide AI with your own words field to refine your logic, then click Preview again to generate a new Blueprint. You can iterate as many times as needed before clicking Save.

The same instructions will not always generate the same Blueprint. Generate with AI uses an AI model to generate Blueprint rows, and AI generation is non-deterministic — the same instructions may produce slightly different results each time, particularly in the specific values and row structure generated. If a generated Blueprint doesn't look right, return to the Guide AI tab, refine your instructions to be more specific, and regenerate.

Output columns in a generated Blueprint may reference fields that don't yet exist in your CRM because they are suggestions meant to illustrate possibilities, not fields that are required to exist. You are not required to use all suggested output columns. Review the suggestions, decide which ones are relevant to your use case, create the corresponding CRM fields if needed, and then map only the columns you want to use in Step 3: Output Mapping.

The Data Logic Input and Output Mapping fields are blank after saving a generated Blueprint because Generate with AI only creates the Blueprint table. The mapping configuration depends on your CRM fields and update conditions, which you set manually in 2. Input Mapping and 3. Output Mapping of the Data Logic module. After you save, the Blueprint automatically loads into 1. Pick Blueprint in Data Logic, ready for you to configure. 

For guidance, see Configuring Data Logic Input Mapping and Configuring Data Logic Output Mapping.

Yes — you can edit an AI-generated Blueprint after saving, and using it as a starting point for manual edits is often the recommended approach. Generate with AI creates a Blueprint based on the field values it observed in your CRM at the time of analysis, but the generated rows may not cover every case or reflect every value in your data. 

Once you've completed all the Generate with AI steps, navigate to Data Integrity > Blueprints, locate and select your Blueprint, then click the Download as CSV icon in the Table Preview header. Make your edits, and click the Upload New Version icon to upload the revised file. Insycle retains previous versions, allowing you to compare changes over time.

The image above shows the Table Preview panel on the Blueprints page displaying version 2 of a Blueprint with columns for Country, State, Industry, Region, Territory Owner, and Sales Tier, with a teal arrow pointing to the Download as CSV icon in the top-right corner of the panel.

Yes, you can use the same Blueprint across multiple Data Logic templates. Because a Blueprint exists independently of any Data Logic template, multiple templates can reference the same Blueprint simultaneously — each with different input mapping, output mapping, and filter configurations. This lets you apply the same business logic to different object types, CRM fields, or subsets of records without duplicating the Blueprint. When you upload a new version of the Blueprint, all templates that reference it will use the updated version on their next run.

When you upload a new version of a Blueprint, Insycle retains all previous versions. All Data Logic configurations that reference the Blueprint automatically use the updated version on their next run — no reconfiguration is required. 

To preview any Blueprint version, go to Data Integrity > Blueprints, locate and select your Blueprint, then click the version dropdown in the Table Preview header.

The image above shows the Table Preview panel on the Blueprints page displaying a Blueprint's versions with columns for Country, State, Industry, Region, Territory Owner, and Sales Tier, with a teal arrow pointing to the version dropdown in the panel header.

If a Blueprint column referenced in a Data Logic template is renamed or removed, the affected input or output mapping will need to be remapped. Open the Data Logic template, locate the input or output where the Blueprint Column field is empty or no longer valid, select the correct column from the Blueprint Column dropdown, and save the template before running it again.

The screenshot below shows an Output Mapping row where the Blueprint Column was reset when the Blueprint column name was changed — the field displays the greyed-out "Blueprint Column" placeholder. In this state, the row is incomplete, and the CRM field will not be updated until a Blueprint column is mapped to it.

Yes, row order matters in a Blueprint. More specific conditions should always appear above more general ones — for example, if you have one row matching Financial Services companies with over 100,000 employees and a separate row matching all Financial Services companies, the specific row must appear first. Row order is determined by the structure of the Blueprint CSV itself; it cannot be configured within Data Logic. See "When a record matches more than one row, which row is applied?" for how Data Logic resolves conflicts between rows.

When a record matches more than one row in a Blueprint, Data Logic applies the first matching row — the row closest to the top of the Blueprint that satisfies all input conditions for that record. Once a match is found, evaluation stops, and subsequent rows are not checked, even if they would also match.

Data Logic matching within a single row is always AND for input columns bound to different CRM fields. Every input condition defined in the Input Mapping must be satisfied simultaneously for that row to match. There is no way to configure a single row to match when any one of multiple conditions on different fields is true — all of them must be true together.

If you need OR behavior across different fields, create separate rows with identical output values — one row per condition.

There is one exception: if multiple input columns map to the same CRM text field, only the column that has a value in that row is evaluated. This allows you to apply different matching criteria — such as Contains Word, Starts With, and Regex — against the same field across different rows, effectively creating OR behavior within a single field via the row structure.

Same-field columns mapped to a numeric or date field behave differently — they combine as AND, not OR. This is how a bounded range is built, pairing a Greater Than column with a Less Than column on the same field.

For a full explanation with examples, see OR and AND Matching Patterns in a Blueprint in Designing a Blueprint CSV.

By default, how a blank cell in a Blueprint input column is handled depends on the Matching Criteria configured for that column. With Exact matching, a blank cell matches only records where the corresponding CRM field is also empty. With any other criteria, a blank cell is skipped and places no condition on the record. With any other criteria — Contains, Starts With, Ends With, Regex, or a numeric or date comparison — a blank Blueprint input cell will never match any record; it is effectively inactive for that condition, and the Blueprint row containing the blank input cell is permanently unusable until the blank cell is resolved.

Enabling Blank Cell Matches Any on an input column changes this: a blank cell in that column matches any value in the corresponding CRM field, regardless of Matching Criteria, turning that column into a wildcard for that row. Other input columns in the same row are unaffected and still need to satisfy their own Matching Criteria.

When 'Blank Cell Matches Any' is enabled on all input columns, a row with every input cell left blank matches any record that reached it — this is called a fallback row. Placed as the last row in the Blueprint, it catches every record not matched by an earlier row. This makes it possible to build sparser Blueprints, where a single row applies broadly across one dimension — such as state or industry — while still requiring an exact match on another dimension — such as country — without needing a separate row for every combination of values.

When a record does not match any row in the Blueprint, Data Logic provides two ways to handle it: a Fallback Value configured in the Output Mapping, or a Fallback Row added as the last row of the Blueprint itself.

Fallback Value

A Fallback Value is configured per output field in Data Logic's Output Mapping. When a record matches no Blueprint row, Data Logic writes the fallback value to that field instead, subject to the same update condition configured for the output. If no fallback value is configured for an output field, that field is left unchanged on non-matching records.

The screenshot below shows the Output Mapping configured with Blueprint Column Region mapped to CRM Field Region using the Always update condition, with a Fallback Value of Unassigned. Records that do not match any row in the Blueprint will have their Region field set to "Unassigned."

Fallback Row

A Fallback Row is an alternative way to define what happens to non-matching records directly inside the Blueprint. The 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 in Data Logic's Input Mapping, each blank cell acts as a wildcard — so the row catches any record not matched by an earlier row and is evaluated like any other matched row.

The screenshot below shows the Territory Assignment Blueprint preview with the Fallback Row highlighted at the bottom. Every input cell in that row — Country, State, and Industry — is blank. With Blank Cell Matches Any enabled on all three input columns, the row catches any record not matched by an earlier row and assigns Region = Unassigned, Territory Owner = unassigned-pool@company.com, and Sales Tier = Review, making unmatched records immediately visible.

The screenshot below shows the Data Logic Input Mapping for the Territory Assignment example. Country, State, and Industry all have Blank Cell Matches Any enabled alongside Case Insensitive and Trim Whitespace, enabling the blank cells in the Fallback Row to act as wildcards for all three columns. Without this override, Industry's Contains matching criteria would leave any row with a blank Industry cell — including the Fallback Row — permanently unable to match, since Contains has no default wildcard behavior for blank cells.

See Fallback Row vs. Fallback Value in the Designing a Blueprint CSV for guidance on when to use each approach, including how to avoid configuring both for the same output field.

Whether all conditions must match depends on whether the input columns in that row are mapped to the same CRM field or to different ones: columns bound to different CRM fields combine as AND and must all be satisfied, while columns bound to the same CRM field combine as OR and only one needs to be satisfied.

• Columns bound to different CRM fields combine as AND. Every one of them must be satisfied for the row to match— there is no way to configure a row to match when any one of several conditions is true. For example, a Territory Assignment Blueprint with Country, State, and Industry as separate inputs only matches a record when all three are true together.
   
• Columns bound to the same CRM field combine as OR. The row matches if any one of them is satisfied. This lets a single Blueprint row express the same match in several ways — for example, mapping Job Title (Exact), Job Title (Starts With), and Job Title (Contains) to the same Job Title field, with each row populating only the column relevant to that row.

If you need OR behavior across different fields, create separate Blueprint rows with identical output values — one row per condition. Data Logic matches whichever row is satisfied first.

For same-field OR columns, blank cells are skipped natively — do not enable Blank Cell Matches Any there, since that turns a blank cell into a wildcard that can cause an unrelated row to incorrectly match.

For the full explanation of both patterns — including worked examples for Job Title Normalization (OR) and Territory Assignment (AND), a side-by-side comparison table, and screenshots — see the OR and AND Matching Patterns in a Blueprint section of Designing a Blueprint CSV.

Data Logic's Match Options let you address common data inconsistencies at match time, without modifying the Blueprint or cleaning your CRM data first. Match Options are configured per input column in Data Logic's Input Mapping and apply only during comparison — your Blueprint and CRM data are never modified.

• Case Insensitive — Matches values regardless of letter casing. Use when CRM data has inconsistent capitalization from form submissions, imports, or manual entry.
• Trim Whitespace — Strips leading and trailing spaces before comparing. Use when CRM data has stray spaces from imports or integrations.
• Normalize Whitespace — Strips leading and trailing spaces and collapses internal runs of whitespace to a single space. Use when CRM data has inconsistent internal spacing from copy-paste or rich text fields.
• Ignore Special Characters — Removes punctuation and special characters before comparing, while preserving letters, digits, and spaces. Use for company name matching where the same company may appear with or without punctuation.

You can combine multiple Match Options in the same input column. See the Match Options Reference in the Configuring Data Logic Input Mapping article for full details, including important limitations for Ignore Special Characters.

By default, Data Logic matching is case-sensitive. A record with Job Title = "vp sales" will not match a Blueprint row with the value "VP Sales" unless the Case Insensitive Match Option is enabled on that input column. You can enable Case Insensitive on the relevant input in 2. Input Mapping, or use a Transform Data operation to standardize casing before running Data Logic.

Note: matching for picklist fields is case-insensitive, regardless of the Case Insensitive Match Option setting. See Picklist Values and Owner Names in the Designing a Blueprint CSV article for details.

By default, Data Logic evaluates all records of the selected object type in your CRM every time it runs. It does not automatically limit processing to new or recently changed records.

To limit which records are evaluated, configure filters under 4. Filter Records. Filters can be used to target specific subsets of records — for example, records created after a certain date, records where a specific field is empty, or records that meet other criteria relevant to your use case.

The screenshot below shows a Filter Records configuration that limits Data Logic to recently modified records that have not yet been assigned a Territory Owner. Two filters are configured: Territory Owner doesn't exist, and Last Modified Date in the last 2 Days. This combination ensures Data Logic evaluates only new or recently changed records that still need a territory assignment, rather than processing all records on every run.

For more details, see Filtering Which Records Data Logic Evaluates.

Data Logic is designed for ongoing maintenance, not just one-time cleanup. Because a Data Logic configuration is saved as a template, you can schedule it to run automatically on a recurring basis — hourly, daily, weekly, or monthly — so that fields stay consistent as new records enter your CRM and existing records change over time.

This is particularly valuable for data cleansing and normalization use cases. Lead source values, job titles, industry classifications, and similar fields tend to accumulate inconsistencies continuously — new records arrive with variant spellings, different team members enter values differently, and imported data rarely matches your internal standards. Running Data Logic on a schedule catches and corrects those inconsistencies automatically, rather than letting them build up between manual cleanup cycles.

When your field standards or normalization logic changes, you update the Blueprint and upload a new version. The scheduled template picks up the updated Blueprint on its next run — no reconfiguration required. This separation between the logic (the Blueprint) and the schedule (the template) is what makes Data Logic practical as a long-term maintenance tool rather than a one-off fix.

For instructions on scheduling a template, see Templates and Automation in the Module Overview.

In the Data Logic module, use Test Matching to troubleshoot when a record isn't matching a Blueprint row. Available in 2. Input Mapping or 3. Output Mapping, it shows a field-by-field breakdown of whether each input matched a condition in the Blueprint and why. It also detects near-misses — cases where a value is almost identical to one in the Blueprint but differs by whitespace, punctuation, or casing — and recommends the specific Match Option that would resolve it. See Testing Data Logic with Test Matching and Near-Miss Detection for full details.

The image above shows the Test Matching Criteria and Update Conditions dialog with a search for "Z" entered in the record search field, displaying two matching company records in the dropdown — EZE A and Zapsec — ready for selection before clicking Evaluate.