A Blueprint is a CSV-based table that stores business logic as rows and columns — the logic layer of the Data Logic module. Covers what Blueprints are, how they work, versioning, managing Blueprints, and authoring your own Blueprint CSV.
Blueprints are CSV-based tables that define business logic as rows and columns. Blueprints are the logic layer of the Data Logic module — they define what should happen, and Data Logic applies that logic to your CRM records.
Blueprints are created and managed under Operations > Blueprints and are available for use across all Data Logic configurations.
Blueprints as Your System of Record for Business Logic
Insycle Blueprints serve as the system of record for your CRM business logic. Territory assignments, scoring models, routing rules, field classifications, suppression lists — each piece of logic lives in a single, versioned Blueprint table rather than scattered across HubSpot Workflows, Salesforce Flows, scripts, and spreadsheets. When the logic changes, you update the Blueprint. Everything that references it stays up to date automatically. No rebuilds, no redeployment, no hunting down which Workflow branch needs editing.
What a Blueprint Is
A Blueprint is a CSV file made up of input columns and output columns.
- Input columns define the matching conditions — the values the system checks against your CRM records to find a match.
- Output columns define the outcomes — the values written to your CRM fields when a record matches a row.
When Data Logic evaluates a record, it checks the record against each row in the Blueprint from top to bottom. The first row where all input column conditions are satisfied is the matching row. The output values from that row are then applied to the record's CRM fields according to the update conditions configured in Data Logic.
A Blueprint that assigns territory and sales tier based on country and employee count might look like this:
| Country | Employees | Territory | Sales Tier |
|---|---|---|---|
| United States | 500–1000 | North America Enterprise | Enterprise |
| United States | 100–499 | North America Mid-Market | Mid-Market |
| Germany | 100–500 | DACH Mid-Market | Mid-Market |
In this Blueprint, Country and Employees are the input columns used to match records, and Territory and Sales Tier are the output columns whose values are written to CRM fields when a match is found. A company record with Country = United States and Employees = 750 matches the first row and receives the corresponding Territory and Sales Tier values.
A Blueprint is the single system of record for a piece of business logic — one table that defines the rules, versioned over time, and applied consistently across your CRM records.
How Blueprints Differ from Workflows
HubSpot Workflows and Salesforce Flows use branching if/else logic. As the number of conditions grows, they become difficult to read, slow to update, and brittle to maintain. A territory model covering 50 countries with size-based tiers requires hundreds of branches. The same logic in a Blueprint is a table with rows that any RevOps or operations team member can read, edit, and version — without touching a single Workflow or Flow.
Blueprints also support multi-field matching and multi-field outputs in a single operation. One matching row can evaluate conditions across Country, Industry, and Employee Count, and write back Territory, Sales Tier, Owner, and Region in a single step. Workflows and Flows typically require separate branches and actions for each output field.
Blueprints are not a full replacement for all Workflows or Flows. They are purpose-built for table-driven, multi-field conditional logic — territory assignment, ICP scoring, renewal risk scoring, compliance enforcement, pricing governance, lead source harmonization, and similar use cases. For processes that go beyond field updates — such as sending emails, creating tasks, triggering notifications — Workflows and Flows remain the right tools. Blueprints handle the data logic, while Workflows or Flows handle the rest.
How Blueprints and Data Logic Work Together
A Blueprint on its own does nothing. It is a definition, not an executor.
Data Logic is the configuration layer that puts a Blueprint to work. It binds Blueprint columns to CRM fields, defines matching criteria for each input, sets update conditions for each output field, applies fallback values for records that don't match, and controls when and how the logic runs.
This separation is what makes the maintenance advantage possible. When business logic changes, you update the Blueprint. The Data Logic configuration stays the same — the same input mapping, the same output mapping, the same filters. The same Blueprint can also be referenced by multiple Data Logic configurations simultaneously, and the same Data Logic configuration continues to work unchanged when a new Blueprint version is uploaded.
For complete details on configuring Data Logic, see Module Overview: Data Logic.
Blueprint Versioning
Blueprints are versioned. When the logic changes — a new territory, a revised scoring model, updated suppression rules, new SKU classifications — you update the Blueprint CSV and upload a new version. Each time you upload a new version, Insycle retains all previous versions. You can preview any version and maintain a full history of how the table has changed over time. To restore a prior version, download the CSV file from the Table Preview panel and upload it as a new version.
When you upload a new Blueprint version, all Data Logic configurations that reference that Blueprint automatically use the updated version on their next run. No reconfiguration, Workflow rebuilds, or no code changes required.
Because every version is retained and previewable, a Blueprint functions as an auditable system of record — you can always trace how your business logic has changed over time.
Creating and Managing Blueprints
Creating a Blueprint
Blueprints can be created from the Data Logic module or the Operations > Blueprints page.
Within Data Logic under 1. Pick Blueprint choose from five sources:
- Generate with AI — Describe your logic needs, and AI generates a Blueprint based on your CRM field metadata and value distributions. There are three paths: Suggested for your data (AI identifies logic opportunities in your CRM), Common use cases (pre-built patterns for territory assignment, scoring, normalization, and similar use cases), and Build your own (define your own input and output fields). For a step-by-step walkthrough, see Generate a Blueprint with AI.
- Explore Examples — Browse a library of Insycle-provided example Blueprints for common use cases, including lead source harmonization, compliance and suppression list enforcement, renewal risk scoring, legacy CRM field migration, and more.
- Use Reference Data — Select from 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. See Building Your Blueprint CSV below.
- Select Existing — Choose from Blueprints you have already created and saved under Operations > Blueprints.
The image above shows the 1. Pick Blueprint step in the Data Logic module, configured for a HubSpot demo account with the Contacts object type selected. The five Blueprint source options are listed — Generate with AI, Explore Examples, Use Reference Data, Create from CSV, and Select Existing — with Use Reference Data selected (indicated by the filled radio button). The Blueprint dropdown to the right of Use Reference Data shows GDPR Adequacy Reference selected, with description and version info, preview, and refresh icons displayed alongside it.
Blueprints can also be created by uploading a CSV directly from the Operations > Blueprints page, without going through the Data Logic module.
The image above shows the Operations > Blueprints page for a HubSpot demo account. The page displays a list of saved Blueprints with Name, Description, and File Name columns. Two Blueprints are partially visible: Derive Country from State/Province Code, which maps state and province values to their parent country, and Industry + Country → Success Tier & Territory, which matches accounts on Industry and Country/Region to assign Success Tier and Territory values. An Upload button and a Generate button are available at the top of the page, along with a filter field for searching the list.
Building Your Blueprint CSV
This section covers everything you need to know to author a Blueprint CSV file — structure, column conventions, value formatting, and row design patterns for common matching scenarios.
CSV Structure
A Blueprint CSV is a table where every column represents either an input or an output, and every row represents one condition and its associated outcomes. No special formatting is required beyond a standard CSV structure: one header row followed by data rows.
- The first row is the header row. Each column header is the name you will reference when mapping the Blueprint to your CRM fields in Data Logic.
- Each data row defines one matching condition. When Data Logic evaluates a record, it checks it against each row from top to bottom and applies the first row for which all input conditions are satisfied. Row order does matter; see details below.
- There is no required column order. Input and output columns can appear in any order, but grouping inputs on the left and outputs on the right makes the table easier to read and maintain.
The CSV pictured above shows the Territory Assignment example. Rows 2–3 match US companies by state and industry (California/Tech and New York/Finance), assigning region, owner, tier, and segment accordingly. Row 4 matches all US companies in Texas, regardless of industry, and assigns AMER-Central and Mid-Market with no segment value. Row 5 matches all UK companies, regardless of state or industry, and assigns EMEA, Enterprise, and Strategic.
Column Headers
Column headers serve as the identifiers that Data Logic uses to bind Blueprint columns to CRM fields. A few conventions to follow:
- Use clear, descriptive names. Headers like "Country," "Employee Count," and "Sales Tier" are easier to map and maintain than abbreviated or ambiguous names.
- When multiple columns map to the same CRM field — a pattern used for OR matching against a single field — differentiate the headers by the matching criteria each column uses. For example, if three columns all map to Job Title with different criteria, name them "Job Title Exact," "Job Title Starts With," and "Job Title Contains." This makes the purpose of each column explicit and prevents mapping errors.
- Column headers are case-sensitive when referenced in Data Logic. Use consistent casing across versions of the same Blueprint to avoid remapping after an upload.
Row Order
Row order in a Blueprint is significant and must be addressed while designing your CSV — it cannot be configured or adjusted within Data Logic.
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. Once a match is found, evaluation stops, and subsequent rows are not checked, even if they would also match.
This means more specific conditions must always appear above more general ones. For example:
| Job Title Exact | Normalized Title | Seniority |
|---|---|---|
| Chief Marketing Officer | Chief Marketing Officer | C-Level |
| Chief Financial Officer | Chief Financial Officer | C-Level |
| VP Sales | Vice President Sales | VP |
| Vice President of Sales | Vice President Sales | VP |
If a row matching all Financial Services companies appeared above a row matching Financial Services companies with more than 100,000 employees, every Financial Services record would match the general row first, and the specific row would never be reached.
Review row order carefully before uploading, especially when your Blueprint mixes broad and narrow conditions.
Blank Cells
Blank cells in a Blueprint row have a defined behavior: they are skipped during evaluation. A blank cell in an input column means that condition is not evaluated for that row. A blank cell in an output column means nothing is written to the corresponding CRM field for that row.
This is the mechanism that enables OR matching against a single CRM field. When multiple input columns all map to the same CRM field — for example, "Job Title Exact," "Job Title Starts With," and "Job Title Contains" — each row populates only one of those columns and leaves the others blank. Data Logic evaluates only the populated column for that row, which means a record can match via any one of the three criteria, depending on which row it reaches first.
| Job Title Exact | Job Title Starts With | Job Title Contains | Normalized Title | Seniority |
|---|---|---|---|---|
| Chief Executive Officer | Chief Executive Officer | C-Level | ||
| Chief Financial Officer | Chief Financial Officer | C-Level | ||
| VP | Vice President | VP | ||
| Director | Director | Senior |
In this example, a record with Job Title = "Chief Executive Officer" matches row 1 via the Exact column; a record with Job Title = "VP of Marketing" matches row 3 via the Starts With column; a record with Job Title = "Director of Sales" matches row 4 via the Contains column. Row order still governs priority — a record that could match on both Exact and Starts With criteria will match the Exact row first if it appears higher in the table.
Input Columns and Output Columns
Any column in a Blueprint can be configured as an input, an output, or both — this is determined by how you map the column in Data Logic, not by anything in the CSV itself.
A column used as an output can be configured with an update condition and a fallback value in Data Logic. Update conditions control when the field is written to — for example, only when the field is currently empty, or only when the matching Blueprint row contains a value in that column. Fallback values are written to a field when no Blueprint row matches the record at all.
A column can also serve as both an input and an output in the same operation. For example, a Job Title column can be used to match records based on their current job title value and, in the same run, write a standardized job title back to the same CRM field. This allows Data Logic to identify and update a field in a single pass.
Numeric and Date Ranges
Two matching criteria — Number Between and Date Between — use a range format with specific formatting rules.
Number Between
Ranges use a hyphen-separated format: 100–1000, 1000–10000. The lower bound is inclusive, and the upper bound is exclusive, so a value of 1000 matches the row 1000–10000, not 100–1000. For open-ended ranges with no upper bound, use the + notation: 3000+ matches any value greater than or equal to 3000.
Date Between
Ranges use a to-separated format: 2026-01-01 to 2026-04-01. The lower bound is inclusive, and the upper bound is exclusive, following the same rule as Number Between. ISO 8601 formats are recommended: yyyy-MM-dd for dates and yyyy-MM-dd'T'HH:mm:ss for datetimes. Other common date formats are also supported.
Picklist Values and Owner Names
When authoring a Blueprint, you write values using the same labels and names you see in your CRM — not the underlying API values or record IDs that your CRM stores internally. Insycle automatically resolves human-readable values to their technical equivalents when matching records and writing results.
Picklist fields
Use the label exactly as it appears in your CRM dropdown. For example, if your Industry field shows Banking & Finance in the interface, write "Banking & Finance" in your Blueprint. Insycle automatically resolves it to the underlying API value. Matching is case-insensitive, so "banking & finance" and "BANKING & FINANCE" resolve to the same option. If your Blueprint was built using API values directly — for example, "banking_and_finance" — those also work. Insycle checks both the label and the API value, so existing Blueprints built either way continue to work without changes.
Owner and reference fields
Use the person's name exactly as it appears in your CRM. Insycle looks up the corresponding owner ID and uses it when writing the assignment. If two users share the same name, Insycle returns an error rather than guessing — the Blueprint row will not match records until the ambiguity is resolved. If a value cannot be resolved, Insycle passes it to the CRM as-is; the CRM will typically reject it at write time, which surfaces the problem without silently corrupting data.
AI-generated Blueprints
When you use Generate with AI, the same resolution logic applies automatically. Picklist cells show the label, and owner cells show the person's name — no additional configuration is needed.
Managing Blueprints
Blueprints are uploaded and managed under Operations > Blueprints.
To add a new Blueprint:
- Navigate to Operations > Blueprints.
- Click New.
The image above shows the Operations > Blueprints page with the left navigation expanded, showing Blueprints selected under the Operations section. The New button is visible at the top of the Blueprint list, with an arrow pointing to it. The list shows four saved Blueprints: Automobiles, Map Country, Territory ID, and Owner (described as "Map Country and Territory ID"), Simple discount and assignment (described as "Global Sales"), and Company Enrichment.
- In the Create Blueprint popup, enter a name and, optionally, a description.
- Click Upload and select your CSV file.
- Click Create.
The image above shows the Create Blueprint popup with a name, optional description, and uploaded CSV file. The Name field contains "Territory Assignment by Country, State, & Industry," and the Description field contains "assign Region, Territory Owner, Sales Tier, Account Type." A CSV file named Territory-Assignment-Country-State-Industry-AccountType.csv has been uploaded, shown with its file size, row count, column count, and modification date. The Upload button (yellow) and Create button (dark) are visible at the bottom of the popup.
To upload a new version of an existing Blueprint:
- Click the Blueprint in the list.
- In the Table Preview below the list, click the Upload New Version icon in the header.
The image above shows the Table Preview panel in Operations > Blueprints, displaying version v1 of a Blueprint with columns for Country, State, Industry, Region, Territory Owner, and Sales Tier. The first visible row shows United States / California / Technology mapped to West / Sarah Chen / Enterprise. An arrow points to the Upload New Version icon in the Table Preview header, with a tooltip reading "Upload New Version." A version dropdown, description, and version info icon, edit icon, and download icon are also visible in the header.
- In the Upload New Version popup, click the yellow Upload button and select your CSV file.
- Click the grey Upload button.
To preview 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 and a search field. Use the preview to confirm you have selected the correct Blueprint and version before configuring your input and output mapping.
The image above shows the 1. Pick Blueprint step in the Data Logic module with Explore Examples selected and the Data Quality Enforcement Blueprint chosen from the Blueprint dropdown. An arrow points to the Preview Blueprint icon (eye icon), with a tooltip reading "Preview Blueprint." The description, version info, and refresh icons are also visible alongside the dropdown.
Frequently Asked Questions
What is a Blueprint in Insycle?
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.
What is the difference between a Blueprint and Data Logic?
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.
What kinds of business logic can a Blueprint represent?
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.
Does Blueprint row order matter?
Yes, row order matters in a Blueprint. 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. 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.
Can the same Blueprint be used in more than one Data Logic configuration?
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.
Can a Blueprint be used across different CRMs?
Yes. 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 supported CRM connections — including HubSpot, Salesforce, and others. There is no need to create separate Blueprint files for each CRM.
What happens when I upload a new Blueprint version?
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.
Can I generate a Blueprint automatically instead of building one from a CSV?
Yes. The Generate with AI feature in the Data Logic module 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. For a complete walkthrough, see Generate a Blueprint with AI.
Can I use picklist labels in a Blueprint, or do I need to use API values?
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.
How do I specify a numeric or date range in a Blueprint?
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.
Additional Resources
Related Help Articles
- Module Overview: Data Logic
- Generate a Blueprint with AI
- Integrate Insycle with HubSpot Workflows
- Integrate Insycle with Salesforce Flow
- Automation & Manual Operations
Related Blog Posts