Handle Linkedin Connection Request Signal

Template placeholders

Replace every {{...}} before enabling. See the setup checklist reference for the full setup list.

• {{PROFILE_OWNER}} — Team member whose inbound connection requests are processed
• {{CRM}} — Your CRM (e.g. HubSpot, Attio)
• {{INTERNAL_DOMAINS}} — Your company domain(s); requests from these stop silently
• {{VISIBILITY_CHANNEL}} — Slack channel that gets one visibility post per processed request
• {{CRM_HYGIENE_SKILL}} — Sub-skill reference: how to create/update companies & contacts in your CRM
• {{LEAD_SCORING_SKILL}} — Sub-skill reference: your lead scoring & qualification methodology (its normal MQL alerting stays on)
• {{REACTIVATION_SKILL}} — Sub-skill reference: how you handle closed-lost account reactivation (optional — skip the reactivation branch's owner notification if you don't have one)
• {{SELF_SERVE_THRESHOLD}} — Company profile below which accounts route self-serve rather than MQL (default: fewer than 50 employees AND ≤$10M raised)
• {{REACTIVATION_WINDOW}} — Minimum time since a closed-lost deal before a request counts as a reactivation signal (default: ~90 days)

Overview

This skill runs when someone sends {{PROFILE_OWNER}} a LinkedIn connection request. The requester reached out to YOU — this is a deliberate, active first-party intent signal, meaningfully stronger than a passive profile view. The job is: resolve + enrich the requester and their company, gate it, attach to CRM per standard hygiene, and score the signal.

Golden rule — the CRM is never polluted. Only a requester who is identified + company-resolved + not-internal + not-a-current-customer + ICP-matched ever reaches a CRM write. Everyone else is silently discarded or logged to account memory only.

The webhook trigger only validates + routes. All behavior lives here.

Payload shape

The routing trigger passes a single, already-deduplicated signal with the person's name, LinkedIn member id / URL, headline, and the invitation note (or null), plus a detection timestamp. Be robust to both a structured person object and a stringified context blob carrying the same fields.

• The invitation note, when present, is strong verbatim intent evidence. Carry it through verbatim to scoring, account memory, and any alert. Never invent one if absent.
• The headline is a LinkedIn headline, not a company name — never treat it as a company or parse a company out of it.

Scope — score + alert only

This skill does scoring + routing + CRM/account-memory updates ONLY. These are people who reached out to YOU — any reply or accept is handled manually by {{PROFILE_OWNER}} outside the agent. Do not send outreach of any kind, do not build or enroll sequences, do not queue or accept connection requests or DMs, and do not create review/approval tasks. Letting {{LEAD_SCORING_SKILL}} post its normal MQL alert for a genuine qualifying account is expected and is NOT outreach. (⚠️ Policy decision — see the checklist. Wire outreach on top only as a conscious opt-in once you trust the signal quality.)

Step 1 — Dedup (before enrichment)

A connection request is a single discrete action, so the only real duplicate source is webhook redelivery from the same person. After you have the person's LinkedIn member id (and, once resolved, the account), check the resolved account's memory for an existing connection-request entry with the same member id. If found → redelivery of an already-processed request → stop silently. No new CRM writes, no memory writes, no channel post.

If the person cannot be identified at all (no name and no LinkedIn URL / member id) → stop silently (anonymous). No enrichment, no writes, no post.

Step 2 — Resolve requester identity & company (mandatory)

Identifying the person is not the same as resolving the company. You need both before proceeding. Never infer the company from the headline.

1. Run contact enrichment on the person's LinkedIn URL (or member id) to resolve current employer name, company domain, confirmed title, and location.
2. Headline-vs-enrichment conflict (mandatory live check). Enrichment is frequently stale and lags job changes. If the headline names a specific, different current company or status than enrichment returns — "Stealth", "Building X", "Founder/Co-Founder at [new co]", "ex-[Company]", or a named employer that is not the enriched one — do NOT trust enrichment. Verify against the person's live LinkedIn profile via a profile scrape and use the current position shown there. A request from someone who has left the enriched company is not intent for that company.
3. If enrichment does not return a confident company name + domain, run a LinkedIn profile scrape on the profile URL, then general web research as a last resort.

Exit condition — UNRESOLVED: If after the full waterfall you still cannot confidently determine a company name + domain, set outcome = UNRESOLVED, write nothing to CRM / account memory, do NOT post, and stop. A guessed company is worse than UNRESOLVED.

Exit this step with: full name, confirmed title, company name + domain, location.

Step 3 — Internal check

If the resolved domain is one of {{INTERNAL_DOMAINS}} → stop silently. No CRM, no memory, no post.

Step 4 — CRM relationship check

Look up the company in the CRM and branch:

• Active Partner → stop silently. Partner accounts are managed by their owner — no CRM writes, no scoring, no post.
• Current customer (Closed Won) → outcome = EXISTING CUSTOMER. Log the request (with verbatim note) to the account's memory so the owner sees the touch — memory-only write. Do NOT create/update CRM records, do NOT score. Jump to Step 8.
• Active (open) deal → outcome = EXISTING RELATIONSHIP. Log the request (with verbatim note) to account memory so the deal owner sees it. Do NOT create outreach. Jump to Step 8.
• Closed-Lost → reactivation candidate (do NOT ignore). A deliberate connection request from a decision maker months after a lost deal is a genuine reactivation signal. Do NOT silent-stop. Instead:
  1. Log the request (with verbatim note) to account memory.
  2. Continue to Step 5 (ICP) and Step 7 (score) treating it as a live signal.
  3. In Step 7, apply the closed-lost reactivation judgment: the top-tier reactivation floor applies only when there was a genuine prior buying evaluation (a real deal / demo / trial), the requester is a strong buyer persona, and enough time has elapsed ({{REACTIVATION_WINDOW}} since the close). A weak persona, a very recent close, or a loss driven by low-dollar pricing friction does NOT lift it — it stays at the awareness tier: log + visibility post, no MQL.
  4. For a qualifying reactivation, also load {{REACTIVATION_SKILL}} for the deal-owner notification and "what changed" framing — notify the deal owner and post, but do NOT run any reactivation outreach or sequence. The MQL channel must get exactly one post per reactivation: the lead scoring skill's normal alert owns it; the reactivation skill contributes only the deal-owner notification.
• No existing relationship (net-new) → continue to Step 5.