CRM Enrich
Fill gaps in existing CRM records with anysite data. The most common flow: pull a list from
the CRM, enrich only what is missing, write back only to mapped fields.
Prerequisites
crm_list_connections → an active connection. Missing → send the user to
/anysite-crm-setup (or Profile → CRM Integration in the dashboard).- The
anysite-crm-profile skill exists → its mapping is law. Missing → minimal safe mode:
standard properties only, recommend running setup.
- Read the Writing rules in
anysite-crm-setup — they apply to every write below.
Flow
1. Scope — what to enrich
Ask (or infer from the request): which records and which fields. Pull them:
crm_query_records(object_type="contacts", list_id=<working list> | search=... | emails=[...],
properties=[record_id + match keys + mapped target fields])
Page through everything in scope. Locally split records into:
- complete — all mapped target fields filled → skip (report count),
- enrichable — has a match key (email / linkedin_url / domain) and gaps,
- unmatchable — no key at all → report, do not guess identities.
2. Resolve identities (contacts)
- Has
linkedin_url → execute linkedin/user/user (full profile: title, company, location).
- Only email → try reverse lookup first:
execute linkedin/email/email_sql_user (cached,
cheap) → remainder via email_user (live). Both take ONE email per call — loop, don't
batch, and expect misses (verified to return empty even for people who are on LinkedIn).
Then the cascade that actually works, because the CRM knows the name: email domain →
resolve company (verified, per anysite-mcp recipe) → organizational_urn →
search_users {first_name, last_name, current_company: [{"type": "company", "value": "<id>"}]} → usually exactly one match, WITH the profile URN as a bonus.
Company filter mandatory — bare names return namesakes. On BIG batches, do the same
cheaper in one call: search_sql_users {last_name: [...], current_company_domain: [<email domains>], count} resolves many name+domain pairs at DB cost (then live-verify
what you'll write). Still nothing → leave record, report.
- Needs email → cascade:
user_email (batch ≤10, cheap, low yield, a MIX of personal and
work addresses incl. past employers — group by profile, match domain to current company)
→ remainder via user_find_email_by_url {url: <vanity profile URL>} (50cr
each — estimate cost on large lists first). Check valid_email/email_status in its
response and write only addresses that pass; report the rest as "found, unverified".
Re-use cache instead of re-fetching anything twice — including across sessions: search_requests (free) finds cache_keys of identical calls from the last 7 days (a company resolved yesterday doesn't need a paid re-resolve today).
3. Resolve companies
By domain — with MANDATORY exact verification on every resolve (the website search is
substring match: stripe.com → Soundstripe; stlabs.com → five other *labs.com companies).
Default one domain per call; OR-DSL batching is an optimization with a tax — any domain
that didn't come back exact-matched gets re-queried individually:
execute linkedin/search/search_sql_companies {website: "acme.com", count: 5}
# batched variant: {website: "acme.com|globex.io", count: 10× domains}, then per domain:
query_cache {conditions: [{"field": "website", "op": "=", "value": "acme.com"}],
limit: <fetched count>}
# query_cache filters over the WHOLE cached set; `limit` (default 10) caps only how many
# rows come BACK. One domain → the default is fine; a multi-domain batch → pass a limit.
Only an exact-website match (normalized: lowercase, no protocol/www/path) counts as
resolved. Gives industry, employee_count, description, locations.
No exact match? Do NOT stop there — a whole class of domains never appears in its own
substring results (verified: {website: "stlabs.com", count: 5} returns five other
*labs.com companies and never STLabs, a live company with a LinkedIn page). Standard second
step, ~1cr:
execute webparser/parse {url: "https://acme.com", extract_minimal: true}
→ top-level `title` = who they say they are
→ links[] usually carries their own linkedin.com/company/... URL
execute linkedin/company {company: "<that URL>"} # exact, no fuzzy matching
Only after that fails is the domain genuinely unresolved — report it, never write.
Deeper firmographics (funding, size range): take the alias from crunchbase_link, which
the domain-resolve above ALREADY returned — free. Only when that field is empty and the
company is plausibly venture-backed, fall back to the live crunchbase/search by name
(20cr, fuzzy — verify name+domain before trusting it):
# crunchbase_link: "https://www.crunchbase.com/organization/acme" → alias "acme"
execute crunchbase/company {company: "acme"}
Only when the profile maps such fields. Normalize contacts.email before use — trailing
dots observed ("founders@reducto.ai."), and a match key with a trailing dot matches nothing.
4. Write back
Build upsert records keyed by the CRM record_id you pulled in step 1 — never re-search
the CRM for a record you already hold, and never create from an enrich flow:
crm_upsert_contacts(records=[{record_id, properties:{<mapped fields only>}}],
allow_create=false,
overwrite_properties=[<only fields marked overwrite in profile>],
dry_run=true)
Show the diff (old → new, counts of fill/skip), get confirmation, re-run with
dry_run=false. Companies go through crm_upsert_companies, which matches ONLY by
domain — always include domain in the properties you pull in step 1; a company record
without a domain is unwritable (report it, don't improvise a match). Keep request batches
reasonable (≤100 records per call). Save the returned run_id.
5. Report
Written / filled-blank-skipped (fill_blank_skip = policy working, not an error) /
enum warnings / unmatchable. Mention crm_undo(run_id) availability. If the profile maps
anysite_last_enriched_at, it was stamped by the mapping — say so.
Rules specific to enrichment
- Never write a value you did not get from a source this session. No invented data.
- A profile field with no fresh source value → leave it out of
properties entirely.
- Enum targets (e.g. industry): pick from the CRM schema
options list, translating the
source value; no match → skip with a note, don't force.
10 records or any overwrite → dry-run first, always.
1---2name: anysite-crm-enrich3description: Enrich existing CRM records (HubSpot contacts and companies) with fresh data from anysite - job titles, LinkedIn profiles, firmographics, emails. Reads records from the connected CRM, finds gaps in mapped fields, fills them from LinkedIn/Crunchbase/web sources, and writes back safely (fill-blank, dry-run, undo). Use when the user asks to enrich CRM records, fill missing fields, update contact or company data, or refresh a CRM list. Requires an active CRM connection and the anysite-crm-profile mapping.4---56# CRM Enrich78Fill gaps in existing CRM records with anysite data. The most common flow: pull a list from9the CRM, enrich only what is missing, write back only to mapped fields.1011## Prerequisites12131. `crm_list_connections` → an `active` connection. Missing → send the user to14 `/anysite-crm-setup` (or Profile → CRM Integration in the dashboard).152. The `anysite-crm-profile` skill exists → its mapping is law. Missing → minimal safe mode:16 standard properties only, recommend running setup.173. Read the Writing rules in `anysite-crm-setup` — they apply to every write below.1819## Flow2021### 1. Scope — what to enrich2223Ask (or infer from the request): which records and which fields. Pull them:2425```26crm_query_records(object_type="contacts", list_id=<working list> | search=... | emails=[...],27 properties=[record_id + match keys + mapped target fields])28```2930Page through everything in scope. Locally split records into:31- **complete** — all mapped target fields filled → skip (report count),32- **enrichable** — has a match key (email / linkedin_url / domain) and gaps,33- **unmatchable** — no key at all → report, do not guess identities.3435### 2. Resolve identities (contacts)3637- Has `linkedin_url` → `execute linkedin/user/user` (full profile: title, company, location).38- Only email → try reverse lookup first: `execute linkedin/email/email_sql_user` (cached,39 cheap) → remainder via `email_user` (live). Both take ONE email per call — loop, don't40 batch, and expect misses (verified to return empty even for people who are on LinkedIn).41 Then the cascade that actually works, because the CRM knows the name: email domain →42 resolve company (verified, per anysite-mcp recipe) → `organizational_urn` →43 `search_users {first_name, last_name, current_company: [{"type": "company",44 "value": "<id>"}]}` → usually exactly one match, WITH the profile URN as a bonus.45 Company filter mandatory — bare names return namesakes. On BIG batches, do the same46 cheaper in one call: `search_sql_users {last_name: [...], current_company_domain:47 [<email domains>], count}` resolves many name+domain pairs at DB cost (then live-verify48 what you'll write). Still nothing → leave record, report.49- Needs email → cascade: `user_email` (batch ≤10, cheap, low yield, a MIX of personal and50 work addresses incl. past employers — group by profile, match domain to current company)51 → remainder via `user_find_email_by_url {url: <vanity profile URL>}` (50cr52 each — estimate cost on large lists first). Check `valid_email`/`email_status` in its53 response and write only addresses that pass; report the rest as "found, unverified".5455Re-use cache instead of re-fetching anything twice — including across sessions: `search_requests` (free) finds cache_keys of identical calls from the last 7 days (a company resolved yesterday doesn't need a paid re-resolve today).5657### 3. Resolve companies5859- By domain — with MANDATORY exact verification on every resolve (the `website` search is60 substring match: stripe.com → Soundstripe; stlabs.com → five other *labs.com companies).61 Default one domain per call; OR-DSL batching is an optimization with a tax — any domain62 that didn't come back exact-matched gets re-queried individually:63 ```64 execute linkedin/search/search_sql_companies {website: "acme.com", count: 5}65 # batched variant: {website: "acme.com|globex.io", count: 10× domains}, then per domain:66 query_cache {conditions: [{"field": "website", "op": "=", "value": "acme.com"}],67 limit: <fetched count>}68 # query_cache filters over the WHOLE cached set; `limit` (default 10) caps only how many69 # rows come BACK. One domain → the default is fine; a multi-domain batch → pass a limit.70 ```71 Only an exact-website match (normalized: lowercase, no protocol/www/path) counts as72 resolved. Gives industry, employee_count, description, locations.7374 **No exact match? Do NOT stop there** — a whole class of domains never appears in its own75 substring results (verified: `{website: "stlabs.com", count: 5}` returns five other76 *labs.com companies and never STLabs, a live company with a LinkedIn page). Standard second77 step, ~1cr:78 ```79 execute webparser/parse {url: "https://acme.com", extract_minimal: true}80 → top-level `title` = who they say they are81 → links[] usually carries their own linkedin.com/company/... URL82 execute linkedin/company {company: "<that URL>"} # exact, no fuzzy matching83 ```84 Only after that fails is the domain genuinely unresolved — report it, never write.85- Deeper firmographics (funding, size range): take the alias from `crunchbase_link`, which86 the domain-resolve above ALREADY returned — free. Only when that field is empty and the87 company is plausibly venture-backed, fall back to the live `crunchbase/search` by name88 (20cr, fuzzy — verify name+domain before trusting it):89 ```90 # crunchbase_link: "https://www.crunchbase.com/organization/acme" → alias "acme"91 execute crunchbase/company {company: "acme"}92 ```93 Only when the profile maps such fields. Normalize `contacts.email` before use — trailing94 dots observed ("founders@reducto.ai."), and a match key with a trailing dot matches nothing.9596### 4. Write back9798Build upsert records keyed by the CRM `record_id` you pulled in step 1 — never re-search99the CRM for a record you already hold, and never create from an enrich flow:100101```102crm_upsert_contacts(records=[{record_id, properties:{<mapped fields only>}}],103 allow_create=false,104 overwrite_properties=[<only fields marked overwrite in profile>],105 dry_run=true)106```107108Show the diff (old → new, counts of fill/skip), get confirmation, re-run with109`dry_run=false`. Companies go through `crm_upsert_companies`, which matches ONLY by110`domain` — always include `domain` in the properties you pull in step 1; a company record111without a domain is unwritable (report it, don't improvise a match). Keep request batches112reasonable (≤100 records per call). Save the returned `run_id`.113114### 5. Report115116Written / filled-blank-skipped (`fill_blank_skip` = policy working, not an error) /117enum warnings / unmatchable. Mention `crm_undo(run_id)` availability. If the profile maps118`anysite_last_enriched_at`, it was stamped by the mapping — say so.119120## Rules specific to enrichment121122- Never write a value you did not get from a source this session. No invented data.123- A profile field with no fresh source value → leave it out of `properties` entirely.124- Enum targets (e.g. industry): pick from the CRM schema `options` list, translating the125 source value; no match → skip with a note, don't force.126- >10 records or any overwrite → dry-run first, always.
anysiteio