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. No automated processes to rebuild, no code to modify, and no configuration to redeploy.

Data Logic typically helps teams with two kinds of work:

• Data cleansing and normalization — standardizing inconsistent CRM field values, such as lead source, job title, industry, region, and product data, to keep fields clean and reporting reliable.
• Business and operations logic — applying repeatable scoring, routing, assignment, and governance logic that would otherwise live in Workflows, spreadsheets, or custom scripts.

Both categories use the same Blueprint-powered model: define your logic in a table, map Blueprint columns to CRM fields, and let Data Logic apply it across your records.

Data Logic handles what neither workflows nor lookup tools do 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 the 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.

Data Logic supports two broad categories of use cases:

Data Cleansing and Normalization 

Cleaning, standardizing, and classifying CRM field values to keep your data consistent and reporting reliable:

• Lead source and UTM normalization
• Job title classification and normalization
• Persona and seniority mapping
• Industry standardization
• Product and SKU standardization
• Country, state, and region normalization
• Data quality enforcement
• Derived field creation

Business and Operations Logic 

Applying repeatable scoring, routing, assignment, and governance logic that would otherwise live in Workflows, spreadsheets, or custom scripts:

• Territory assignment
• Lead routing and ownership assignment
• ICP scoring
• Renewal risk scoring
• Pricing tier and discount governance
• Compliance and suppression logic
• Account health classification
• Account and customer segmentation

Both categories use the same Blueprint-powered model.

A Blueprint is a CSV-based table that stores your business logic as data. You create and manage Blueprints under Data Integrity > Blueprints, and you can reuse them across objects and 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

Example: Territory and tier assignment Blueprint

The table below shows a simple territory and tier assignment Blueprint—a common business and operations logic use case for Data Logic. 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. For a broader look at what Data Logic can do across use-case categories, see What You Can Do with Data Logic above.

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 matching row.

For a full reference on creating, versioning, and managing Blueprints, see Blueprints.

Navigate to Data Integrity > Data Logic.

Configure Data Logic in four steps. Each step is collapsed by default and expands when you select it. Save the configuration as a template to reuse, schedule for automation, add to a Recipe, and make observable to track coverage and drift in Observability.

Step 1. Pick Blueprint

Select the Blueprint that defines the logic Data Logic will apply to your records — a new CSV upload, an existing saved Blueprint, an AI-generated Blueprint, an example, or a reference dataset. Once a Blueprint is selected, a Preview icon appears beside the Blueprint field, letting you confirm the table data before proceeding. For the full list of sources and how to choose between them, see Picking a Blueprint for Your Data Logic Template.

The image above shows Step 1. Pick Blueprint in the Data Logic module, with Select Existing chosen as the source and the Territory Assignment by Country, State, Industry Blueprint selected from the list.

Step 2. Input Mapping

Input mapping defines how Blueprint columns match records—which CRM field each column compares against, and which matching criteria and Match Options to apply. For the full reference, including every matching criteria and Match Option and how blank Blueprint cells are handled, see Configuring Data Logic Input Mapping and How Blank Cells Are Evaluated in Blueprint Input and Output Columns.

The image above shows the Data Logic input mapping that applies the Blueprint pictured above. Lead Source (Contains) and Referrer Domain (Ends With) both have Blank Cell Matches Any enabled, letting their blank cells act as wildcards across the sparse rows shown above. Lead Source Original (Exact) has no Match Options enabled, since its default Exact behavior — a blank cell matching only an empty CRM field — is already the correct behavior for this column.

Step 3. Output Mapping

Output mapping defines which Blueprint columns are written to CRM fields when a match is found, and under what conditions — including how to fall back to a default value when no Blueprint row matches. For the full reference, see Configuring Data Logic Output Mapping.

The image above shows 3. Output Mapping of the Data Logic module for a Job Title Normalization and Persona Assignment template, with four Blueprint columns mapped to CRM fields— Normalized Title (Always) mapped to Job Title, Persona (Always) mapped to Persona, Seniority (Output Non-Empty) mapped to Seniority, and Department (Field Empty) mapped to Department.

Step 4. Filter Records

Filtering limits which records Data Logic evaluates, so it processes only records that match your filter criteria. By default, Data Logic evaluates all records of the selected object type in your CRM. For the full reference, see Filtering Which Records Data Logic Evaluates.

The image above shows Step 4. Filter Records in the Data Logic module, with three filters configured: Country exists, State exists, and Industry exists. State and Country are case-insensitive.

Data Logic includes Test Matching, a diagnostic tool that evaluates a specific record against your current input and output mapping configuration and shows, field by field, whether it matches and why. This eliminates the need to manually compare a record's field values against the Blueprint to figure out why it isn't updating as expected. Test Matching also flags near-miss values—a stray space, a hyphen standing in for a space, differing capitalization—that are easy to type past and hard to catch by eye, and recommends the Match Option that would resolve each one.

Test Matching is available once your input and output mapping is fully configured in Steps 2 and 3.

For the full walkthrough — including how to run a test, interpret the Input and Output Analysis, and use Near-Miss Detection — see Testing Data Logic with Test Matching and Near-Miss Detection.

The image above shows the Test Matching Criteria and Update Conditions dialog in the Data Logic module after evaluating the record "Graso," displaying three input field results — Country/Region and State/Region passing with green checkmarks, and Industry failing with a red X because the field is blank — and three output field results — Country/Region failing because no Blueprint match was found, and Tier and County passing with updates ready to write — with an Input Analysis summary noting the unmatched Industry field and an Output Analysis summary confirming that 2 of 3 output fields would be updated.

To run Data Logic, click Review once your configuration is complete; it 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 changing 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: Run Preview mode first, especially when configuring Data Logic for the first time or after uploading a new Blueprint version.

The image above 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.

The image above shows the Data Logic Template menu with the Copy and pencil (rename) icons highlighted.

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.
• Made observable — Click the shield icon in the template toolbar to have Insycle evaluate the template's records against its Blueprint on every ingestion cycle, reporting coverage and drift in Using the Observability View. Observability only evaluates; it doesn't write changes — correcting what it finds still requires a template run. The image above shows the Data Logic Template menu with the Observability shield icon enabled (blue) and highlighted.

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

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

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

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.

  Do not enable Blank Cell Matches Any on these columns. Same-field OR matching already skips blank cells natively — Blank Cell Matches Any turns a blank cell into a wildcard that's always satisfied, which can cause an unrelated row to match instead of the one the record actually belongs to. Reserve Blank Cell Matches Any for input columns bound to different CRM fields, where it's used to create broad, sparser rows — see How Blank Cells Are Evaluated in Blueprint Input and Output Columns for details.

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.