Module Overview: Data Logic

Data Logic and Blueprints work together as two distinct but connected parts of the same system.

A Blueprint is a CSV-based table that defines your business logic — territory assignments, scoring criteria, field standards, classification rules — as rows and columns. Each row represents a condition and its associated outcomes. Each column represents either an input used to match records or an output value to apply.

Data Logic is the module that puts a Blueprint to work. It binds Blueprint columns to CRM fields, controls how and when each field is updated, and runs the logic across your records.

This separation is intentional. When your business logic changes — new territories, updated scoring tiers, revised routing rules — you update the Blueprint table and upload a new version. The Data Logic configuration stays the same. There are no automated processes to rebuild, no code to modify, and no configuration to redeploy.

Data Logic compares favorably to both workflows and lookup tools by handling what neither does cleanly:

• Lookup tools can return a single value from a table, but don't support multi-field matching, multi-field outputs, or per-field update conditions.
• Workflows can handle complex conditional logic, but become difficult to maintain as conditions multiply, and require rebuilding when logic changes.

Data Logic combines the simplicity of a table with the power of multi-condition, multi-output logic — without requiring code or complex configuration. It is well-suited for revenue operations, sales operations, and marketing operations teams who need to define and maintain CRM logic without engineering support.

A Blueprint is a CSV-based table that stores your business logic as data. Blueprints are created and managed under Operations > Blueprints and are available for use across Data Logic configurations.

Each Blueprint is made up of rows and columns:

• Each row represents a condition and its associated outcomes
• Each column represents either an input value used to match records or an output value to apply to CRM fields

For example, a Blueprint that assigns a customer tier and sales owner based on country and employee count might look like this. In this Blueprint, Country and Employees are the input columns used to match records, and Tier and Owner are the output columns whose values are written to CRM fields when a match is found:

A record with Country = US and Employees = 750 would match the first row, and Data Logic would write Enterprise to the Tier field and Sarah to the Owner field for that record.

When Data Logic evaluates a record, it checks the record's Country and Employees values against each row from top to bottom, and applies the Tier and Owner values from the first row that matches.

Blueprints are versioned assets. Each time you upload a new version, Insycle retains the previous versions, allowing you to compare values and track how the table has changed over time.

To create a new Blueprint:

1. Navigate to Operations > Blueprints.

2. Click New.

   

3. In the Create Blueprint popup, enter a Name and, optionally, a description.
4. Click Upload and select your CSV file.
5. Click Create.

To update an existing Blueprint:

1. Click the Blueprint in the list.
2. In the Table Preview below the list, click the Upload New Version icon in the header.
3. In the Upload New Version popup, click the yellow Upload button and select your CSV file.
4. Click the grey Upload button.

Previewing a Blueprint

When selecting a Blueprint in Data Logic, a Preview icon appears beside the Blueprint field. Clicking it opens a Blueprint Preview popup that displays the table data, a search field, and — for Insycle-provided reference Blueprints — a source attribution line. Use the preview to confirm you have selected the correct Blueprint and version before configuring your input and output mapping.

Blueprint Sources

When working in Data Logic, you can select or create a Blueprint from five sources:

• Generate with AI — Describe your logic needs and let AI generate a Blueprint based on your CRM fields. AI analyzes your field metadata and value distributions to suggest use cases, match common business logic patterns, or build a custom Blueprint from your own instructions. See Generate a Blueprint with AI for a step-by-step walkthrough.
• Explore Examples — Browse a library of Insycle-provided example Blueprints designed to help you get started with common use cases such as territory assignment, ICP scoring, job title normalization, lead source harmonization, and more
• Use Reference Data — Select from a library of Insycle-maintained reference datasets, including GDPR adequacy data, NAICS 2022 industry codes, and SIC codes
• Create from CSV — Upload a CSV file to create a new Blueprint directly from within Data Logic
• Select Existing — Choose from Blueprints you have already created and saved under Operations > Blueprints

Navigate to Data Management > Data Logic.

Data Logic is configured in four steps. Each step is collapsed by default and expands when selected. The configuration is saved as a template, which can be reused, scheduled for automation, or added to a Recipe.

Step 1: Pick Blueprint

Step 1 is where you select the Blueprint that defines the logic Data Logic will apply to your records. Choose from any of the five Blueprint sources described in the Blueprints section above.

Once a Blueprint is selected, a Preview icon appears beside the Blueprint field. Click it to open the Blueprint Preview popup and confirm the table data before proceeding.

Step 2: Input Mapping

Input mapping defines how Blueprint columns are used to match records. Multiple inputs can be added. When multiple inputs are configured, all conditions must be satisfied simultaneously for a row to match — see Key Behaviors and Rules for details.

To add an input:

1. Click + Input
2. Configure the following fields:
   • Blueprint Column — the Blueprint column to use as the matching value
   • CRM Field — the CRM field to compare against the Blueprint column
   • Matching Criteria — how the CRM field value is compared to the Blueprint column value. Select the option that matches how your data is structured:

Matching Criteria	How It Compares the CRM Field Value to the Blueprint Value
Exact	Field value exactly matches the Blueprint value
Contains	Field value contains the Blueprint value anywhere within it
Contains Word	Field value contains the Blueprint value as a whole word
Starts With	Field value begins with the Blueprint value
Ends With	Field value ends with the Blueprint value
Regex	Field value matches the regular expression pattern defined in the Blueprint
Number Between	Field value falls within the numeric range defined in the Blueprint, separated by a "-" character. For example: "1-9"
Greater Than	Field value is greater than the Blueprint value
Lower Than	Field value is lower than the Blueprint value
Greater Than or Equal To	Field value is greater than or equal to the Blueprint value
Lower Than or Equal To	Field value is lower than or equal to the Blueprint value
Date Between	Field value falls within the date range defined in the Blueprint, separated by "to". For example: "2026-09-01 to 2026-11-30"
Before	Field value is earlier than the Blueprint date value
After	Field value is later than the Blueprint date value
At or Before	Field value is on or earlier than the Blueprint date value
At or After	Field value is on or later than the Blueprint date value

In the example below, three inputs are configured:

• Blueprint Column Country maps to CRM field Country/Region using Exact matching
• Blueprint Column State maps to CRM field State/Region using Exact matching
• Blueprint Column Industry maps to CRM field Industry using Exact matching

When Data Logic evaluates a record, all three field values must exactly match a single Blueprint row simultaneously for that row to be applied.

Step 3: Output Mapping

Output mapping defines which Blueprint columns are written to CRM fields when a match is found. Multiple outputs can be added, allowing a single Blueprint row match to update several CRM fields at once.

To add an output:

1. Click + Output
2. Configure the following fields:
   • Column Name — the Blueprint column whose value will be written to the CRM field
   • Field Name — the CRM field to update
   • Update Condition — controls when the field is updated. Select the option that matches how you want Data Logic to handle existing field values:

• Fallback Value — if no Blueprint row matches the record, the fallback value is written to the field instead. If no fallback is configured, non-matching records are left unchanged.

Note: A CRM field used as an input in Step 2 can also be used as an output in Step 3. For example, if Job Title is used as an input to match records, it can also be configured as an output to update those records with a standardized value.

In the example below, four outputs are configured:

• Blueprint Column Territory Owner maps to CRM field Territory Owner with Update Condition Field Empty — the Territory Owner field is only updated if it has no existing value, protecting manual assignments from being overwritten
• Blueprint Column Sales Tier maps to CRM field Sales Tier with Update Condition Always — the Sales Tier field is updated on every match, regardless of its current value
• Blueprint Column Account Type maps to CRM field Account Type with Update Condition Output Non-Empty — the Account Type field is only updated when the matching Blueprint row contains a value, preventing blank Blueprint cells from erasing existing values
• Blueprint Column Region maps to CRM field Region with Update Condition Always — the Region field is updated on every match, regardless of its current value

Step 4: Filter Records

Step 4 is where you configure filters to limit which records Data Logic evaluates. Only records that match the filter criteria will be processed. By default, Data Logic evaluates all records of the selected object type in your CRM.

Filters follow Insycle's standard filtering options.

In the example below, three filters are configured to limit Data Logic to records that have values in all three input fields:

• Country exists
• State exists
• Industry exists

This ensures that Data Logic evaluates records only when all three input fields have values, avoiding partial matches against Blueprint rows that require all three conditions to be satisfied simultaneously.

Running Data Logic is done by clicking the Review button once your configuration is complete, which prompts you to choose how to run the operation.

Data Logic offers two run modes:

• Preview — simulates the operation and shows which records would be updated and what values would be written, without making any changes to your CRM. Use Preview mode to validate your Blueprint and mapping configuration before committing changes.
• Update — applies changes directly to your CRM, updating records based on your input matching, output mapping, and update conditions.

Note: Running in Preview mode first is recommended, especially when configuring Data Logic for the first time or after uploading a new Blueprint version.

The screenshot below shows the Data Logic Run step with Update mode selected.

After configuring Data Logic and reviewing your results in your CRM, you can save your configuration as a template for future reuse. Templates preserve all Data Logic settings, including the selected Blueprint, input mapping, output mapping, filters, and run mode.

To save a template, return to the Template menu at the top of the page and click Copy to save your configuration as a new template. Click the pencil icon to rename it.

Saved templates can be:

• Run manually — open the template at any time and run it on demand
• Scheduled for automation — set the template to run automatically on a recurring schedule
• Added to a Recipe — combine the template with others from any Insycle module to run a sequence of operations from a single schedule or trigger, which can then be integrated with HubSpot Workflows or Salesforce Flows as part of a larger data maintenance process

To schedule a template to run automatically:

1. Under Run, click the Review button and select Update mode
2. On the Notify tab, select the send option appropriate for your automation: Always send, Send when errors, or Do not email
3. Add any additional recipients who should receive the CSV, pressing Enter after each address. You can also provide additional context in the message subject or body
4. On the When tab, under Automate, configure the frequency: Hourly, Daily, Weekly, or Monthly
5. When finished, click Schedule and confirm

The screenshot below shows the Data Logic Run step configured in Update mode with the Automate frequency set to Daily.

For more information, see the Templates and Automation & Manual Operations articles.

Row order in a Blueprint matters because when a record matches more than one row, 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, the output values from that row are applied, and evaluation stops. Subsequent rows are not checked, even if they would also match.

Row order in your Blueprint is therefore significant. More specific conditions should 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. If the general row appears first, it will match before the more specific row is ever evaluated.

The following Blueprint excerpt shows a job title normalization table. More specific title variations — such as C-Level and VP titles — appear at the top, followed by progressively broader engineering title variants. This ensures that a record with Job Title = Chief Marketing Officer matches row 5 before any less-specific row could.

When uploading or editing a Blueprint, always review row order to ensure more specific conditions appear above more general ones. Row order cannot be configured within Data Logic — it is determined by the structure of the Blueprint CSV itself.

Yes, all input conditions defined for a Blueprint row must be satisfied simultaneously for that row to apply — there is no way to configure a single Blueprint row to match when any one of several conditions is true.

AND Matching: All Conditions Must Be True

In the ICP Scoring example below, two inputs are configured — Employee Count and Annual Revenue — and a record only matches a Blueprint row if both field values fall within the specified ranges simultaneously. There is no way to configure a single row to match when any one of several conditions is true — all of them must be true together.

The screenshot below shows the Input Mapping for the ICP Scoring example, with Blueprint Column Employee Count mapped to CRM Field Number of Employees using Number Between matching, and Blueprint Column Annual Revenue mapped to CRM Field Annual Revenue using Number Between matching. A record only matches a Blueprint row when both field values fall within the ranges defined in that row simultaneously.

OR Matching Across Different Fields: Use Separate Rows

OR matching across different fields in Data Logic is achieved by creating separate rows in your Blueprint with identical output values — one row per condition. Data Logic will match whichever row is satisfied first. 

In the Blueprint excerpt example below, two Blueprint rows match different variations of the same job title and produce identical output values. A record with Job Title = "VP Sales" matches the first row; a record with Job Title = "Vice President of Sales" matches the second row. Either match produces the same normalized job title, job function, seniority, and persona values — OR behavior achieved through Blueprint row structure rather than configuration.

OR Matching Against a Single Field: Use Multiple Input Columns

OR matching against a single CRM field is achieved by mapping multiple Blueprint input columns to the same CRM field in the Input Mapping — each with a different matching criteria — where only the column that contains a value in a given row is evaluated. Blank cells in that row are skipped. This means you can apply different matching criteria against the same CRM field across different rows, where each row activates only one criteria. A record can match via any one of those criteria depending on which row it satisfies first. This is OR behavior against a single field, implemented through Blueprint row structure rather than configuration.

For example, a job title normalization Blueprint could be configured with three input columns — Job Title Exact, Job Title Starts With, and Job Title Contains — all mapped to the CRM field Job Title, with Exact, Starts With, and Contains matching criteria, respectively. Each Blueprint row populates only one of those columns, leaving the others blank:

In this configuration:

• A record with Job Title = "Chief Executive Officer" matches row 1 via Exact criteria
• A record with Job Title = "VP of Marketing" matches row 3 via Starts With criteria
• A record with Job Title = "Director of Sales" matches row 5 via Contains criteria

Each row activates only one matching criteria based on which column is populated. The result is OR behavior against a single field — any one of the three criteria can produce a match — implemented via the row structure rather than a configuration option.

Note: Row order still determines priority. A record with Job Title = "Chief Financial Officer" matches row 2 via Exact before it can reach row 4 via Starts With, ensuring it receives the correct specific normalized title rather than the generic "Chief Officer" value.

The screenshot below shows the Input and Output Mapping configuration for the job title normalization example. Three Blueprint input columns — Job Title Exact, Job Title Starts With, and Job Title Contains — are each mapped to the CRM field Job Title with different matching criteria. The Output Mapping writes the Normalized Title Blueprint column to the Job Title CRM field using the Always update condition, overwriting the original value with the standardized title.

A simple way to remember it: conditions across columns within a row are always AND; different criteria against the same field across rows can behave as OR.

When a record does not match any row in the Blueprint, Data Logic applies the fallback values configured in the Output Mapping, if any are set. If no fallback value is configured for an output field, that field is left unchanged on non-matching records.

The screenshot above shows the Input Mapping configured with Blueprint Column Country mapped to CRM Field Country using Exact matching. Records are matched against the Blueprint based on their Country field value.

The screenshot above 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."

Yes, the same CRM field can be used as both an input in Step 2 and an output in Step 3. This allows Data Logic to match records based on a field's current value and, in the same operation, overwrite that field with a standardized value from the Blueprint. For example, Job Title can be used to identify records and then updated with a normalized job title value in the same process.

The screenshot below shows the Input and Output Mapping configuration for the OR matching against a single field example. Three Blueprint input columns — Job Title (Contains), Job Title (Starts With), and Job Title (Regex) — are each mapped to HubSpot Field Job Title with different matching criteria. The Output Mapping writes the Normalized Title Blueprint column back to the Job Title field using the Always update condition, overwriting the original value with the standardized title.

Yes, matching in Data Logic is case-sensitive. A record with Job Title = "vp sales" will not match a Blueprint row with the value "VP Sales." Ensure Blueprint values match the exact casing used in your CRM data, or use a Transform Data operation to standardize casing before running Data Logic.

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 against a single field through row structure.

For a full explanation with examples, see Do All Conditions Have to Match for a Blueprint Row to Apply? in Key Behaviors and Rules above.

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. More specific conditions should always appear above more general ones in your 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.

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.

Yes, Data Logic works with all CRMs supported by Insycle, including HubSpot, Salesforce, and others. The same Blueprint can be used across different CRM connections — because a Blueprint is simply a CSV table, independent of any specific CRM, the same logic can be applied to records in any supported CRM without creating separate Blueprint files for each.

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

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.

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.