Insycle Product News Center

The updated Welcome page brings together two views of your CRM data health right where you land after logging in: a Data Integrity Overview showing how well your records meet your standards, and a refreshed Health Assessment Overview highlighting duplicates, missing fields, and formatting issues. Instead of a generic landing page, you get a ranked, actionable list of what to fix first — no need to search through modules; the Welcome page indicates where to start.

Each card shows headline numbers alongside a short list of your worst-off templates, so you can go from logging in to fixing a problem in a single click.

For example, if your team recently implemented a new lead-routing standard, you'd typically need to open Data Integrity and manually review coverage to see whether it's gaining traction. Now, if that standard is drifting, it shows up right on your Welcome page, ranked against everything else that needs attention, with a link straight into the fix.

Learn more:

• Getting Started with Data Integrity
• Data Health Assessment

When you use the Cleanse Data module to explore a field and spot the variations hiding in it — inconsistent industries, mismatched job titles, messy lead sources — you can clean up what's there today. But new records keep coming in, and without an ongoing fix, the same inconsistencies creep right back in behind you.

Now, once you've identified those variations in Cleanse Data, you can export them directly as a Blueprint CSV and hand them off to Data Logic for standardization that runs automatically, on every record, going forward — not just the ones you happened to catch today.

For example, if your Industry field has drifted into a mix of "Technology," “Information Technology and Services,” and "Information Services" across your database, Cleanse Data shows you every variation and how often each one appears. Export that list, map the incorrect values to the one you want to keep, upload the Blueprint, and set up the automated Data Logic template — from then on, new and existing records with any of those variations get corrected automatically, with no manual re-cleaning required.

Learn more about exporting field details from Cleanse Data to create a Data Logic Blueprint, Data Logic, and Blueprints.

You've done the work to define how your CRM data should look — territory logic, lead scoring, standardized field values, routing rules. But once that logic is running, how do you know it's still working? New records come in that don't match anything you've defined. Fields quietly drift away from what they should say. Without a way to see it happening, the only signal is usually a downstream mess: a lead that went to the wrong owner, a report that doesn't add up.

Insycle’s Data Integrity gives you that visibility. It continuously measures your records against every Blueprint your Data Logic templates apply, showing you how much of your data is covered, how much has drifted, and exactly which records and fields need attention — before those gaps turn into bigger problems.

Three views work together to make this easy to act on. The Overview gives you the account-wide health check: coverage and drift trending up or down, at a glance. Observability lets you drill into any one Data Logic template to see precisely which values aren't matching and which fields have drifted. And Recommendations turns all of that into a single ranked to-do list, sorted by the number of records each fix would affect, so you always know where to spend your time first.

You'll find all of this in the left navigation under Data Integrity: Overview, Observability, Recommendations, Data Logic, and Blueprints.

For example, if you have a Blueprint assigning sales territories by country and industry, Data Integrity will flag the accounts with a firmographic combination your Blueprint doesn't yet cover, and separately surface the accounts whose Territory field has drifted from what the Blueprint says it should be — each ranked by record count, so you fix the highest-impact gaps first.

Blueprints, Data Logic, and Observability are all included in every Insycle plan at no additional cost.

Learn more about Data Integrity.

When a record isn't updating the way you expect in the Data Logic module, tracking down the reason has always meant manually comparing field values against your Blueprint, row by row. It's slow, and the actual cause is often something small and easy to miss — a stray space, a hyphen where you expected a dash, a capitalization mismatch. Test Matching does that comparison for you and tells you, in plain language, exactly where things went wrong.

From Step 2: Input Mapping in the Data Logic module, after setting up the parameters, click Test Matching, search for and select the record you want to verify, and then click Evaluate. You'll get a full breakdown of both sides of your configuration:

• Input fields show whether each value matched a condition in your Blueprint, and if not, why.
• Output fields show whether they'll be updated, left alone, or filled with a fallback value, and why.

An Input Analysis and Output Analysis summary at the bottom gives you the takeaway at a glance, so you don't have to piece it together yourself. And if a record matches every input individually but still doesn't match overall, Test Matching flags that too, so you know a new Blueprint row is likely needed.

Test Matching also catches near-misses automatically. If an input value is almost identical to something already in your Blueprint, it calls out the specific difference — extra whitespace, a punctuation mismatch, a case difference — and tells you which Match Option would close the gap.

For example, if a record's Company Name is listed as "AT & T" but your Blueprint has "AT&T," Test Matching identifies the punctuation difference and recommends turning on Ignore Special Chars, rather than leaving you to spot the mismatch on your own.

Learn more: Module Overview: Data Logic

Building value mappings one row at a time in the Transform Data module works fine when you have a handful of substitutions. But when you're standardizing company name abbreviations, industry codes, or territory labels across thousands of records — and you need those mappings enforced continuously, not just once — Insycle offers a better long-term home for that work in the Data Logic module.

You can now export your Transform Data mappings directly to a Blueprint CSV, ready to use in Data Logic. Instead of manually rebuilding your mapping logic from scratch, the export captures everything you've already configured and outputs it in the format Data Logic expects — so you can move your mappings to the tool built to run them at scale, automatically, across all records.

For example, if you've mapped abbreviations like CU → Credit Union, FCU → Federal Credit Union, and CB → Community Bank in Transform Data, the export generates a Blueprint CSV with those mappings ready to load.

If any existing text entry used pipe delimiters to define multiple variations (for example, NY|NYC|New York City → New York), the export automatically splits those into individual rows so the Blueprint is structured correctly.

To use it, configure any supported map function in step 2 of Transform Data — the blue Export button will appear in that row.

Learn more about Transform Data and Data Logic.

If your team manages territory assignments, lead scoring, routing rules, field classifications, or similar logic in your CRM, you know the maintenance burden: every time a rule changes, someone has to track down the right process branch, update conditions, test it, and hope nothing breaks. For logic that lives in your head — or in a spreadsheet — keeping the CRM in sync is a constant, manual effort.

Data Logic and Blueprints replace that process with a table. You define your business logic as rows and columns in a CSV — match conditions and output values — and Insycle applies it across your records. When your logic changes, you upload a new version of the table. There's nothing to rebuild.

A Blueprint is the table itself. Data Logic is the module that connects it to your CRM fields, controls when each field is updated, and runs the operation across your records. The same Blueprint can be reused across multiple configurations, applied to any supported CRM, and scheduled to run automatically.

For example, if you assign sales territories based on country, state, and industry, you can define every combination as rows in a Blueprint — each row specifying the Region, Territory Owner, and Sales tier to apply — and configure Data Logic to match records against it and update those fields automatically. When territories change, you update the Blueprint via a CSV file.

Blueprints can be built from a CSV you already have, created from one of Insycle's example templates, drawn from a library of reference data, or generated from scratch using AI, which analyzes your CRM fields and can suggest use cases, match common business logic patterns, or build a Blueprint from your own description.

Learn more about Data Logic and Blueprints.

HubSpot enforces a strict rule for Lifecycle Stage: it can only move forward in the funnel. When duplicates are merged — whether directly in HubSpot or through Insycle's native merge — HubSpot automatically keeps the stage furthest down the funnel, no exceptions. If your master record is a Lead but another duplicate is a Customer, the merged record becomes a Customer, regardless of your intent.

For teams that need to retain an earlier Lifecycle Stage after a merge — for example, to flag a record for re-nurturing or to match an internal classification — there was previously no way to override this.

Insycle now lets you control exactly which Lifecycle Stage is retained using Native merge, even if it's earlier in the funnel than the default HubSpot behavior would select. You can designate a specific stage from either the master record or any duplicate in the group, and Insycle will apply it to the merged record — bypassing HubSpot's usual funnel-progression rule. This applies to HubSpot contacts and companies.

For example, if your master record is tagged as Lead and a duplicate is tagged as Customer, Insycle can retain Lead on the merged record — something that isn't possible when merging directly in HubSpot.

To use this, go to the Merge Duplicates module, under 3. Merge Logic on the Method tab, make sure your Merge API is set to Native, and then set your Lifecycle Stage selection rule on the Fields tab.

Learn more about merging duplicates in HubSpot.

Salesforce databases often contain hundreds of fields—far more than most teams actively use. Without a way to control which fields are pulled into Insycle, your dataset can become bloated with unnecessary data, slowing syncs and making filtering and duplicate matching more difficult.

You can now choose exactly which Salesforce fields are included in your Insycle dataset — the same self-service field inclusion controls already available for HubSpot now work for Salesforce as well.

In Insycle, go to Settings > Fields, select your Salesforce database and object type, and use the Included toggle to add or remove individual fields from your dataset. The Fields table shows each field's label, internal name, field type, and writability, giving you full visibility into what's available. Fields used in automated Recipes and templates are protected and included automatically — you're only managing the additional fields you choose to bring in. You can include up to 100 fields per object type (150 for Enterprise plans).

For example, if your team tracks sales territory and contract tier in custom Salesforce fields, you can enable those fields so they're available for filtering and standardization in Insycle — without pulling in hundreds of fields you'll never use.

Field inclusion changes take effect during the overnight sync process. If you need fields available sooner, contact support to trigger an immediate sync. Note that an Admin or Owner user role is required to manage field inclusion.

Learn more about managing which Salesforce fields are included in Insycle.

When importing into Salesforce, one of the most common pain points is not knowing whether a person already exists in your CRM—and whether they're a Lead or a Contact. Without a way to check both object types at the same time, avoiding duplicates meant running separate comparisons and manually consolidating the results.

Insycle’s Magical Import now supports cross-object matching for Leads and Contacts for Salesforce. When importing into Leads, you can enable an Including Contacts toggle to match against Contacts as well. Likewise, when importing into Contacts, you can enable the Including Leads toggle to match against Leads as well.

Insycle searches across both object types simultaneously and returns a unified preview showing each record's type, so you can see exactly where every row stands before committing to an import. A Type column in the Preview and in CSV reports indicates whether each matched record is a Lead or Contact, giving you complete visibility into the results without leaving Insycle.

For example, you're importing a prospecting list from Sales Navigator. Some people on the list already exist as Contacts; others are Leads; and a few aren't in Salesforce at all. With cross-object matching enabled, Insycle identifies each one in a single pass, updates the existing record if a match is found, and creates a new Lead only for rows with no match in either object type—no manual cross-checking needed. It will also flag if duplicates are present in your database.

Learn more: Cross-Object Matching for Leads and Contacts in Magical Import

When merging duplicates, the right merge method depends on your CRM setup, the object types involved, and the level of control you need over the outcome. Until now, that choice has happened behind the scenes. The new Merge API setting — found on the Method tab in Step 3: Merge Logic — puts it in your hands.

Available for HubSpot and Salesforce users, the Merge API lets you choose between two merge approaches: Native, which uses your CRM's built-in merge logic, and Synthetic, which uses Insycle's custom merge logic for greater control over field retention, master record selection, and complex associations.

Insycle selects a sensible default based on your platform and object type — for example, Native is the default for HubSpot Contacts and Salesforce Contacts, Leads, and Accounts, while Synthetic is the default for object types that don't have native CRM merge support. But now you can override that default when your use case calls for it.

For example, a user merging HubSpot Contacts might switch from Native to Synthetic merge because they need the master record's ID to remain unchanged — such as when that record ID is referenced in an external system and changing it would break the connection.

Learn more:

• Native Merge vs. Synthetic Merge behavior in HubSpot
• Native Merge vs. Synthetic Merge behavior in Salesforce