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.

Building a Blueprint from a CSV is not the only option, and using Generate with AI is not required either — there are two paths, and you can use either one.

Generate with AI

Generate with AI analyzes your CRM field metadata and generates a Blueprint based on your data, a common use case pattern, or your own custom instructions. There is no requirement 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 Operations > Blueprints and clicking Upload. If you already have a Blueprint, you can select it in Data Logic using Select Existing, browse Insycle-provided examples using Explore Examples, or choose from Insycle-maintained reference datasets using Use Reference Data. For a full overview of all Blueprint sources, see Module Overview: Data Logic.

In the Data Logic module, '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.

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 is specific to your CRM fields and update conditions, which you manually set in Steps 2 and 3 of the Data Logic module. After saving, the Blueprint is automatically loaded into Step 1: Pick Blueprint in Data Logic, ready for you to configure. See Module Overview: Data Logic for guidance on configuring Input and Output Mapping.

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 continue to work 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.

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.

Yes. 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 allows the same business logic to be applied to different object types, different CRM fields, or different 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.

Yes, generated Blueprint rows can be edited after saving. Navigate to Operations > Blueprints, locate and select your Blueprint, and click the Upload New Version icon in the Table Preview header. Download the current Blueprint CSV, make your edits, and upload the revised file as a new version. Insycle retains previous versions, allowing you to compare changes over time.

Yes, a generated Blueprint can be used as a starting point and edited manually — and this 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. To edit it, download the current version via Upload New Version in Operations > Blueprints, make your changes, and upload the revised file as a new version. See "Can I Edit the Generated Blueprint Rows After Saving?" for full details.

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. You can preview any version from the Table Preview panel in Operations > Blueprints.

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. 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 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 are mapped to the same CRM 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.

For a full explanation with examples, see Do All Conditions Have to Match for a Blueprint Row to Apply? in the Module Overview.

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.

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 and State both 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 those columns. Industry has Case Insensitive and Trim Whitespace enabled, but not Blank Cell Matches Any — rows that leave Industry blank skip that condition rather than matching any value, which is the default behavior for a non-Exact column.

See Fallback Row vs. Fallback Value in the Module Overview: Data Logic for guidance on when to use each approach, including how to avoid configuring both for the same output field.

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.

Multiple Match Options can be combined on the same input column. See Match Options in the Module Overview: Data Logic for full details, including important limitations for Ignore Special Characters.

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.

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 means those inconsistencies are caught and corrected automatically, rather than building 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 in the Module Overview for full details.