GTM Engineering skill 08 of 13

CRM Sync and Routing SKILL.md

The CRM Sync and Routing skill makes Claude Code or another AI agent sync GTM tables to HubSpot, Salesforce or a sequencer safely. It maps fields with overwrite rules, looks up records before creating them, protects rep and system fields, routes ownership by territory, tier and capacity, applies suppression before enrolment and stamps every record with its source.

crm-sync-routing/SKILL.md, version 1.0.0, 1,488 words.

The last step of a GTM workflow is where the most damage happens. Enriched data overwrites what reps typed, duplicate records appear, accounts land with the wrong owner, contacts are added to sequences while already talking to sales, and nobody can trace where a record came from. A careful sync turns good table work into pipeline; a careless one erodes trust in the CRM.

This skill designs how GTM tables sync to CRMs (HubSpot, Salesforce or similar) and sequencers: field mapping, create-versus-update logic, field ownership and overwrite rules, deduplication lookups, account and contact ownership, routing by territory, tier and capacity, sequence enrolment rules, suppression, source tracking, error handling and monitoring.

Operating principles

  1. Look up before you create. Every push checks for existing accounts and contacts first.
  2. Never overwrite human data. Rep-entered and system-critical fields are protected.
  3. One owner per account. Routing rules decide ownership before outreach starts.
  4. Do not sequence active conversations. Suppress anyone in an open deal, recent conversation or opt-out.
  5. Trace every record. Source, workflow, date and version are stamped on each record.

Field mapping table

| Table column | CRM object.field | Direction | Overwrite rule | Required |
| in_domain | Company.domain | Table -> CRM | Only if empty | Yes |
| en_email | Contact.email | Table -> CRM | Only if empty | Yes |
| sc_tier | Company.gtm_tier | Table -> CRM | Always update | Yes |
| sc_fit_score | Company.fit_score | Table -> CRM | Always update | No |
| title | Contact.job_title | Table -> CRM | Only if empty or older than 90 days | No |
| owner | Company.owner | CRM -> Table | Never from table | Yes |
| src_workflow | Contact.lead_source_detail | Table -> CRM | Set on create only | Yes |

Field ownership

TypeExamplesRule
System fieldsIDs, created dates, lifecycle stageCRM owns; never written by the table
Rep-owned fieldsNotes, next steps, owner, deal stageNever overwritten
Enrichment fieldsEmployees, industry, tech stackUpdated on schedule with source and date
Score fieldsFit, timing, tierAlways updated by the scoring workflow
Source fieldsWorkflow, list, dateSet once on create

When to use, and when not to

Use it when connecting Clay or another tool to a CRM or sequencer, when CRM data gets overwritten or duplicated, when routing is unclear, or before scaling automated pushes.

Don't use it for full CRM implementation or lifecycle design (the CRM and Lifecycle skills), though it should follow their definitions.

Inputs

  • CRM objects, fields and permissions.
  • Ownership and territory rules.
  • Sequencer and its enrolment options.
  • Suppression lists: customers, open deals, opt-outs, competitors.
  • The table spec and QA results.

Raw SKILL.md file

.md

This is the exact file agents read, including the credit header and licence notice. Save it as crm-sync-routing/SKILL.md.

---
name: crm-sync-routing
description: "Sync GTM tables to CRMs and sequencers safely: field mapping with direction and overwrite rules, lookups before create, protected rep and system fields, ownership and routing by territory, tier and capacity, enrolment and suppression rules, source stamping, error handling and weekly monitoring. Use whenever someone connects Clay or another GTM tool to HubSpot, Salesforce or a sequencer, sees duplicates or overwritten CRM data, needs account routing rules or wants to stop sequencing people already in deals."
license: CC-BY-4.0
metadata:
  author: Afeez Adebayo
  author_url: https://afeezadebayo.com
  author_linkedin: https://www.linkedin.com/in/afeez-adebayo/
  author_x: https://x.com/za_icon
  source: https://afeezadebayo.com/skills-md/marketing/gtm-engineering/crm-sync-routing/
  category: marketing
  subcategory: gtm-engineering
  version: "1.0.0"
  created: "2026-10-10"
  updated: "2026-10-13"
---

# CRM Sync and Routing

The last step of a GTM workflow is where the most damage happens. Enriched data overwrites what reps typed, duplicate records appear, accounts land with the wrong owner, contacts are added to sequences while already talking to sales, and nobody can trace where a record came from. A careful sync turns good table work into pipeline; a careless one erodes trust in the CRM.

This skill designs how GTM tables sync to CRMs (HubSpot, Salesforce or similar) and sequencers: field mapping, create-versus-update logic, field ownership and overwrite rules, deduplication lookups, account and contact ownership, routing by territory, tier and capacity, sequence enrolment rules, suppression, source tracking, error handling and monitoring.

## Operating principles
1. **Look up before you create.** Every push checks for existing accounts and contacts first.
2. **Never overwrite human data.** Rep-entered and system-critical fields are protected.
3. **One owner per account.** Routing rules decide ownership before outreach starts.
4. **Do not sequence active conversations.** Suppress anyone in an open deal, recent conversation or opt-out.
5. **Trace every record.** Source, workflow, date and version are stamped on each record.

## Field mapping table
```
| Table column | CRM object.field | Direction | Overwrite rule | Required |
| in_domain | Company.domain | Table -> CRM | Only if empty | Yes |
| en_email | Contact.email | Table -> CRM | Only if empty | Yes |
| sc_tier | Company.gtm_tier | Table -> CRM | Always update | Yes |
| sc_fit_score | Company.fit_score | Table -> CRM | Always update | No |
| title | Contact.job_title | Table -> CRM | Only if empty or older than 90 days | No |
| owner | Company.owner | CRM -> Table | Never from table | Yes |
| src_workflow | Contact.lead_source_detail | Table -> CRM | Set on create only | Yes |
```

## Field ownership
| Type | Examples | Rule |
|---|---|---|
| System fields | IDs, created dates, lifecycle stage | CRM owns; never written by the table |
| Rep-owned fields | Notes, next steps, owner, deal stage | Never overwritten |
| Enrichment fields | Employees, industry, tech stack | Updated on schedule with source and date |
| Score fields | Fit, timing, tier | Always updated by the scoring workflow |
| Source fields | Workflow, list, date | Set once on create |

## When to use, and when not to
Use it when connecting Clay or another tool to a CRM or sequencer, when CRM data gets overwritten or duplicated, when routing is unclear, or before scaling automated pushes.

Don't use it for full CRM implementation or lifecycle design (the CRM and Lifecycle skills), though it should follow their definitions.

## Inputs
- CRM objects, fields and permissions.
- Ownership and territory rules.
- Sequencer and its enrolment options.
- Suppression lists: customers, open deals, opt-outs, competitors.
- The table spec and QA results.

## Workflow

### Step 1. Map fields
Table columns to CRM fields with direction, overwrite rules and requirements.

### Step 2. Define create versus update
Look up companies by domain and contacts by email (then LinkedIn URL); update if found, create only if not.

### Step 3. Protect fields
Set overwrite rules and test them on a sandbox or a small batch.

### Step 4. Set ownership and routing
Existing owner wins; otherwise route by territory, segment, tier and rep capacity; round-robin within a team.

### Step 5. Define enrolment rules
Only QA-passed, tier-appropriate contacts with valid emails, no open deals, no recent activity and no opt-outs.

### Step 6. Stamp the source
Workflow name, table, version and date on create.

### Step 7. Handle errors
Failed pushes go to an error list with reasons; retry rules; alert the owner.

### Step 8. Monitor
Weekly report on records created, updated, failed, duplicates found and routing exceptions.

## Routing rules example
```
1. If the company has an owner in the CRM -> keep owner.
2. If tier A and region UK -> UK enterprise team (round-robin by capacity).
3. If tier A and region West Africa -> Lagos team.
4. If tier B -> SDR pool, round-robin.
5. If tier C -> nurture sequence, no owner.
6. Tier D -> not pushed.
```

## Suppression checks
| Check | Source | Action |
|---|---|---|
| Existing customer | CRM lifecycle stage | Do not sequence; notify account owner if a signal fired |
| Open deal | Deal pipeline | Do not sequence; send signal to the deal owner |
| Contacted in last 30 to 90 days | Activity history | Hold |
| Unsubscribed or opted out | CRM and sequencer | Never contact |
| Competitor or partner | Lists | Exclude |

## Signals for existing customers and deals
When a signal fires for a customer or an account with an open deal, do not sequence; instead create a task or alert for the owner with the signal and a suggested action, such as an expansion conversation after a funding round. This turns GTM data into account management value without annoying active buyers.

## Testing a sync
Before going live, push 20 to 50 tagged records, check every mapped field in the CRM, confirm protected fields were untouched, check owners and sequence enrolment, then delete or untag the test records. Repeat after any mapping change. Keep a rollback plan, such as a saved export of affected records, for bulk updates.

Document every mapping change with the date and reason.

## Monitoring report example
```
Week 42: created 640 | updated 1,120 | failed 18 (missing owner region) | duplicates blocked 210 | routing exceptions 6
```
Investigate any rise in failures or duplicates the same week.

Agree mapping and routing changes with sales operations before releasing them.

## Edge cases and judgement calls
| Situation | What to do |
|---|---|
| Contact exists under a different company | Check for job change; create new association, keep history |
| Several contacts per account | Limit per account; sequence by persona and priority |
| Account owned by an inactive rep | Route by rules and notify sales operations |
| API limits | Batch pushes; schedule off-peak |
| Sandbox not available | Test with a tagged small batch and roll back plan |
| Regional data rules | Store and route data according to local requirements |

## Handoffs to related skills
- Deduplication before push: `data-deduplication-normalisation`
- Tiers used in routing: `icp-account-scoring`
- QA before push: `gtm-workflow-qa`
- Documentation of mappings: `gtm-workflow-documentation`
- Lead routing in depth: the CRM and Lifecycle `lead-scoring-routing` skill
- CRM hygiene: the CRM and Lifecycle `crm-data-hygiene` skill

## Worked example
A team pushed Clay contacts straight into HubSpot. Within a month, 900 duplicate contacts appeared, rep notes were overwritten by enrichment, and 40 contacts in open deals received cold sequences. The redesign added domain and email lookups, a mapping table with overwrite rules, protected rep-owned fields, routing that kept existing owners and assigned new accounts by region and tier, suppression for customers, open deals and recent activity, and source stamps on every record. A 50-record test batch passed. Duplicates stopped, reps stopped complaining about lost notes and no active deals were sequenced again.

## Common mistakes
- Creating records without lookups.
- Overwriting rep-entered fields.
- Sequencing people in open deals or recent conversations.
- No source stamps, so nobody knows where data came from.
- Ignoring failed pushes.

## Output format
```
1. Field mapping with overwrite rules
2. Create-versus-update logic
3. Ownership and routing rules
4. Enrolment and suppression rules
5. Source stamping
6. Error handling and monitoring report
```

## Self-check before you answer
- Does every push look up existing records first?
- Are rep-owned and system fields protected?
- Are suppression rules applied before enrolment?
- Is every record stamped with its source?

---
Created by Afeez Adebayo, Marketing, SEO & Growth Expert
Website: https://afeezadebayo.com
LinkedIn: https://www.linkedin.com/in/afeez-adebayo/
X: https://x.com/za_icon
Source: https://afeezadebayo.com/skills-md/marketing/gtm-engineering/crm-sync-routing/

Licence: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). You may copy, share and adapt this skill, including for commercial use, as long as you credit Afeez Adebayo and link to the source URL above. Keep this notice in any copy or adapted version.

Workflow

Step 1. Map fields

Table columns to CRM fields with direction, overwrite rules and requirements.

Step 2. Define create versus update

Look up companies by domain and contacts by email (then LinkedIn URL); update if found, create only if not.

Step 3. Protect fields

Set overwrite rules and test them on a sandbox or a small batch.

Step 4. Set ownership and routing

Existing owner wins; otherwise route by territory, segment, tier and rep capacity; round-robin within a team.

Step 5. Define enrolment rules

Only QA-passed, tier-appropriate contacts with valid emails, no open deals, no recent activity and no opt-outs.

Step 6. Stamp the source

Workflow name, table, version and date on create.

Step 7. Handle errors

Failed pushes go to an error list with reasons; retry rules; alert the owner.

Step 8. Monitor

Weekly report on records created, updated, failed, duplicates found and routing exceptions.

Routing rules example

1. If the company has an owner in the CRM -> keep owner.
2. If tier A and region UK -> UK enterprise team (round-robin by capacity).
3. If tier A and region West Africa -> Lagos team.
4. If tier B -> SDR pool, round-robin.
5. If tier C -> nurture sequence, no owner.
6. Tier D -> not pushed.

Suppression checks

CheckSourceAction
Existing customerCRM lifecycle stageDo not sequence; notify account owner if a signal fired
Open dealDeal pipelineDo not sequence; send signal to the deal owner
Contacted in last 30 to 90 daysActivity historyHold
Unsubscribed or opted outCRM and sequencerNever contact
Competitor or partnerListsExclude

Signals for existing customers and deals

When a signal fires for a customer or an account with an open deal, do not sequence; instead create a task or alert for the owner with the signal and a suggested action, such as an expansion conversation after a funding round. This turns GTM data into account management value without annoying active buyers.

Testing a sync

Before going live, push 20 to 50 tagged records, check every mapped field in the CRM, confirm protected fields were untouched, check owners and sequence enrolment, then delete or untag the test records. Repeat after any mapping change. Keep a rollback plan, such as a saved export of affected records, for bulk updates.

Document every mapping change with the date and reason.

Monitoring report example

Week 42: created 640 | updated 1,120 | failed 18 (missing owner region) | duplicates blocked 210 | routing exceptions 6

Investigate any rise in failures or duplicates the same week.

Agree mapping and routing changes with sales operations before releasing them.

Edge cases and judgement calls

SituationWhat to do
Contact exists under a different companyCheck for job change; create new association, keep history
Several contacts per accountLimit per account; sequence by persona and priority
Account owned by an inactive repRoute by rules and notify sales operations
API limitsBatch pushes; schedule off-peak
Sandbox not availableTest with a tagged small batch and roll back plan
Regional data rulesStore and route data according to local requirements
  • Deduplication before push: data-deduplication-normalisation
  • Tiers used in routing: icp-account-scoring
  • QA before push: gtm-workflow-qa
  • Documentation of mappings: gtm-workflow-documentation
  • Lead routing in depth: the CRM and Lifecycle lead-scoring-routing skill
  • CRM hygiene: the CRM and Lifecycle crm-data-hygiene skill

Worked example

A team pushed Clay contacts straight into HubSpot. Within a month, 900 duplicate contacts appeared, rep notes were overwritten by enrichment, and 40 contacts in open deals received cold sequences. The redesign added domain and email lookups, a mapping table with overwrite rules, protected rep-owned fields, routing that kept existing owners and assigned new accounts by region and tier, suppression for customers, open deals and recent activity, and source stamps on every record. A 50-record test batch passed. Duplicates stopped, reps stopped complaining about lost notes and no active deals were sequenced again.

Common mistakes

  • Creating records without lookups.
  • Overwriting rep-entered fields.
  • Sequencing people in open deals or recent conversations.
  • No source stamps, so nobody knows where data came from.
  • Ignoring failed pushes.

Output format

1. Field mapping with overwrite rules
2. Create-versus-update logic
3. Ownership and routing rules
4. Enrolment and suppression rules
5. Source stamping
6. Error handling and monitoring report

Self-check before you answer

  • Does every push look up existing records first?
  • Are rep-owned and system fields protected?
  • Are suppression rules applied before enrolment?
  • Is every record stamped with its source?

When to use this skill, and when not to

Use it when connecting Clay or another tool to a CRM or sequencer, when CRM data gets overwritten or duplicated or before scaling automated pushes.

The final sync is where most damage happens: overwritten notes, duplicates, wrong owners and cold sequences sent to people in open deals.

Example prompts

  • “Map our Clay columns to HubSpot fields.”
  • “Stop enrichment overwriting rep notes.”
  • “Write account routing rules by region and tier.”
  • “Never sequence contacts in open deals.”

Example output

The skill returns a fixed structure. A shortened example for an imaginary site:

Mapping: direction and overwrite rule per field
Lookups: domain and email before create
Routing: existing owner wins, then region and tier
Suppression: customers, open deals, recent activity, opt-outs
Test batch: 50 records passed

Every push looks up existing records first, and rep-owned fields are never overwritten.

What the agent needs from you

It needs CRM objects, fields and permissions, ownership and territory rules, the sequencer, suppression lists and the table spec with QA results.

How this skill hands off to related skills

CRM Sync and Routing connects to related skills in the GTM Engineering skills, including GTM Workflow QA and GTM Engineering Audit.

How to run CRM Sync and Routing step by step

  1. Install the skill as crm-sync-routing/SKILL.md.
  2. Map fields.
  3. Define create versus update.
  4. Protect fields.
  5. Set ownership and routing.
  6. Define enrolment rules.

Situations this skill handles

CRM Sync and Routing handles these situations:

SituationWhat the skill does
Contact exists under a different companyCheck for job change; create new association, keep history
Several contacts per accountLimit per account; sequence by persona and priority
Account owned by an inactive repRoute by rules and notify sales operations
API limitsBatch pushes; schedule off-peak
Sandbox not availableTest with a tagged small batch and roll back plan
Regional data rulesStore and route data according to local requirements

What makes this skill different

Most syncs push everything and hope. This skill protects human data, prevents duplicates, routes ownership and blocks outreach to anyone already talking to sales.

Practical tips from real projects

  • Look up before you create.
  • Never overwrite human data.
  • One owner per account.
  • Do not sequence active conversations.

A worked example: A team pushed Clay contacts straight into HubSpot. Within a month, 900 duplicate contacts appeared, rep notes were overwritten by enrichment, and 40 contacts in open deals received cold sequences. The redesign added domain and email lookups, a mapping table with overwrite rules, protected rep-owned fields, routing that kept existing owners and assigned new accounts by region and tier, suppression for customers, open deals and recent activity, and source stamps on every record. A 50-record test batch passed. Duplicates stopped, reps stopped complaining about lost notes and no active deals were sequenced again.

Map fields: Table columns to CRM fields with direction, overwrite rules and requirements. Define create versus update: Look up companies by domain and contacts by email (then LinkedIn URL); update if found, create only if not. Protect fields: Set overwrite rules and test them on a sandbox or a small batch.

Set ownership and routing: Existing owner wins; otherwise route by territory, segment, tier and rep capacity; round-robin within a team. Define enrolment rules: Only QA-passed, tier-appropriate contacts with valid emails, no open deals, no recent activity and no opt-outs. Stamp the source: Workflow name, table, version and date on create.

Handle errors: Failed pushes go to an error list with reasons; retry rules; alert the owner. Monitor: Weekly report on records created, updated, failed, duplicates found and routing exceptions.

Field mapping table. in_domain: crm object.field Company.domain; direction Table -> CRM; overwrite rule Only if empty; required Yes. en_email: crm object.field Contact.email; direction Table -> CRM; overwrite rule Only if empty; required Yes. sc_tier: crm object.field Company.gtm_tier; direction Table -> CRM; overwrite rule Always update; required Yes. sc_fit_score: crm object.field Company.fit_score; direction Table -> CRM; overwrite rule Always update; required No. title: crm object.field Contact.job_title; direction Table -> CRM; overwrite rule Only if empty or older than 90 days; required No. owner: crm object.field Company.owner; direction CRM -> Table; overwrite rule Never from table; required Yes. src_workflow: crm object.field Contact.lead_source_detail; direction Table -> CRM; overwrite rule Set on create only; required Yes.

Field ownership. System fields: examples IDs, created dates, lifecycle stage; rule CRM owns; never written by the table. Rep-owned fields: examples Notes, next steps, owner, deal stage; rule Never overwritten. Enrichment fields: examples Employees, industry, tech stack; rule Updated on schedule with source and date. Score fields: examples Fit, timing, tier; rule Always updated by the scoring workflow. Source fields: examples Workflow, list, date; rule Set once on create.

Suppression checks. Existing customer: source CRM lifecycle stage; action Do not sequence; notify account owner if a signal fired. Open deal: source Deal pipeline; action Do not sequence; send signal to the deal owner. Contacted in last 30 to 90 days: source Activity history; action Hold. Unsubscribed or opted out: source CRM and sequencer; action Never contact. Competitor or partner: source Lists; action Exclude.

Signals for existing customers and deals. When a signal fires for a customer or an account with an open deal, do not sequence; instead create a task or alert for the owner with the signal and a suggested action, such as an expansion conversation after a funding round. This turns GTM data into account management value without annoying active buyers.

Testing a sync. Before going live, push 20 to 50 tagged records, check every mapped field in the CRM, confirm protected fields were untouched, check owners and sequence enrolment, then delete or untag the test records. Repeat after any mapping change. Keep a rollback plan, such as a saved export of affected records, for bulk updates. Document every mapping change with the date and reason.

Edge cases and judgement calls. Contact exists under a different company: what to do Check for job change; create new association, keep history. Several contacts per account: what to do Limit per account; sequence by persona and priority. Account owned by an inactive rep: what to do Route by rules and notify sales operations. API limits: what to do Batch pushes; schedule off-peak. Sandbox not available: what to do Test with a tagged small batch and roll back plan. Regional data rules: what to do Store and route data according to local requirements.

Frequently asked questions

Map fields with overwrite rules, look up before creating, protect rep fields, test on a small batch and monitor failures.

The existing owner if there is one; otherwise route by territory, tier and capacity.

Customers, people in open deals or recent conversations, opt-outs and competitors.

So every record can be traced to the workflow, table and date that created it.

Changelog

  • 1.0.0, 10 October 2026: first release.

Use, adapt and share this skill under CC BY 4.0: credit Afeez Adebayo and link to this page.