FAQ
What happens if a record is flagged as both a duplicate and a child type at the same time? What is the priority of attributes?
The recommended order of events for Kernel's Cleaning action (outlined in Actioning) is to first Merge, then Associate , but users don't need to follow the recommendations in order.
Some customers prefer to use the hierarchy data first due to its non-destructive nature. The user can use hierarchy data to fill in the blanks of existing Parent Account fields, overwrite existing, or use a separate custom field, e.g., the one provided by Kernel in Kernel fields.
Merge operations are destructive and may require further calibration, which means customers prefer to do this last.
What does Day 0 look like?
Day zero begins before signing with Kernel. We have pre-kickoff materials which show the access we need via Salesforce so you can begin the conversations with your Salesforce admins.
We then have our kick-off call which is when we will make sure everything is set up to be able to access your CRM and will begin to go through the custom configurations in the Kernel platform. Meaning that we can get started on cleaning your data as soon as possible.
How is Kernel different from traditional data vendors?
Unlike traditional vendors that deliver static data dumps, Kernel continually crawls public sources (websites, filings, news, etc.), measures account risk in real time, and updates hierarchies and deduplication recommendations automatically. Kernel also returns contextual reasoning for its decisions and allows customer‑specific rules and feedback loops .
How does Kernel assign risk scores and what do the risk tiers mean?
Every account receives a risk score between 0 and 100. “Hard factors” such as open opportunities, a customer relationship or significant contracted ARR automatically set the risk to 100, protecting these accounts from destructive actions. For all other records, Kernel calculates risk from activity and completeness signals—recent activity, record age, number of opportunities, tasks and contacts, owner type (integration vs. human), and field completeness—and customers can adjust weightings. Accounts are grouped into tiers (very low, low, medium, high). High‑risk records are shielded from merges or deletions until reviewed; lower‑risk records can be cleaned first, enabling a phased approach.
What duplicate types does Kernel identify, and how is the primary record chosen?
Kernel categorizes duplicates into types: Primary (the master record), Exact, Subdomain, Regional, Potential, Tenant, and Location. When multiple records share the same company identity, Kernel selects a primary record by evaluating domain authority and geography: it prefers global domains over regional ones, well‑known TLDs over obscure ones, root domains over subdomains, shorter and simpler domains, working websites over dead links, and domains that don’t redirect to others. The record with the highest risk score also influences the decision.
How does Kernel determine which fields survive a merge?
Survivorship logic then determines which fields persist: Kernel fills blanks from non‑master records, keeps the earliest creation date and latest activity date, prefers an active owner, preserves the most complete address, and avoids circular parent‑child relationships. Administrators can customize survivorship rules to ensure specific fields always survive.
Why would I keep deliberate duplicate and how does Kernel handle them?
Some duplicates are intentional, such as separate billing entities, channel partners, product lines or regional offices. These should not be merged. Kernel lets you define “deliberate duplicate” rules using fields like billing entity flags, partner types, product lines or owner roles. When a record matches a deliberate‑duplicate rule, Kernel excludes it from merge recommendations and treats it as a separate entity.
What do the Kernel cleaning actions mean?
The Cleaning action field tells you what to do with each record.
Delete removes dead or dormant accounts; these actions are only applied to very low‑risk records.
Merge consolidates duplicates; Kernel selects a master record and merges others into it.
Associate links a child account to its parent within your CRM hierarchy; this is non‑destructive.
Associate (missing parent) creates a missing parent account and then associates the child; once created, the action resets to None.
Review flags low‑confidence decisions for manual inspection. Administrators can adjust risk thresholds that determine when each action appears.
How does Kernel verify and clean website data?
Kernel’s website analysis has three steps. First, it removes invalid domains like public email providers, placeholder domains and link‑shortening services. Second, if an account’s website is missing, Kernel infers a domain by examining the account name, LinkedIn profile, contact email domains, alternate websites, address look‑ups, web searches and common typos. Finally, Kernel verifies the site by resolving the URL, ensuring it loads globally and contains relevant content; this step flags “dead” or misleading sites and informs whether a record should be deleted.
What happens when our account data doesn't match?
When a company’s name and website conflict (e.g., the account uses a reseller’s site or has a placeholder domain), Kernel performs account analysis. It looks at related opportunity names, contact email domains, alternate websites, billing emails, account notes, existing LinkedIn information, legal name fields and live website content to infer the correct name and website. The output includes a suggested name, suggested website and the reasoning behind the suggestion so administrators can decide whether to update the record.
What does implementing Kernel look like?
Kernel provides a 30‑day transformation guarantee. The timeline generally includes Day 0 (CRM access and kickoff), Week 1 (account‑level cleaning), Week 2 (deduplication and hierarchies), Week 3 (custom business logic), and Week 4 (actioning and rollout). To meet this timeline, customers must provide CRM access before kickoff and allocate roughly ¼–½ FTE to work with Kernel’s solutions engineer. The kickoff call establishes integration, reviews your CRM fields and risk definitions, and begins configuring deliberate duplicates, risk scores and safeguards.
Last updated