A LinkedIn job-change alert should enter the CRM as a sourced employment observation, not as an automatic overwrite or a claim of buying intent. Preserve the old relationship, verify the new one, resolve ownership, and let policy determine the next action.
Direct answer: ingest the alert with source and event time, match it to the correct person, create a candidate employment transition, review ambiguous identity, then append or update CRM state under explicit authority. A role change can justify review; it does not prove budget, need, or permission to contact.
Treat the alert as an observation
LinkedIn Sales Navigator documents alerts for saved leads moving to a new company or changing roles within the same company. Availability and embedded CRM experiences depend on the configured plan. Record only what the alert supports: person candidate, prior or new role as available, account candidate, alert type, source reference, observed time, and ingestion time.
Do not rewrite the event as “new buyer,” “warm lead,” or “active evaluation.” Those labels add inferences. The job-change trigger guide covers messaging once the employment event has passed the workflow below.
Resolve the person and employment event
Match with stable identifiers where permitted, plus corroborating name, location, role, employer, prior CRM history, and profile evidence. LinkedIn's HubSpot CRM Sync implementation document describes people-and-company matching and notes a single CRM record match limit. Route namesakes, consultancies, concurrent roles, parent-subsidiary changes, and same-company promotions to review.
Keep four times distinct: when the role started, when the source published or exposed it, when the system observed it, and when the CRM changed. “Started this month” should not become an invented date.
Classify the event as new employer, internal role change, additional concurrent role, return to former employer, correction, or unresolved. That classification controls CRM history and seller routing.
Choose the CRM record model
Do not erase the former employer relationship if it explains prior activity, champion history, or an open opportunity. Adapt the model to the CRM, but preserve these concepts:
| Record element | Default treatment |
|---|---|
| Person identity | Retain stable CRM identity unless duplicate resolution requires a merge |
| Prior employment | Close or mark historical with source and effective-date uncertainty |
| New employment | Create a proposed association; review ambiguity |
| Email and phone | Do not carry old-company details as current without verification |
| Open opportunity | Keep owned commercial history; create an explicit handoff or exception |
| Alert evidence | Append source, timestamps, event class, reviewer, and correction state |
Define who owns a contact that changes territory, segment, or account. The CRM contact ownership rules should decide, not whichever integration wrote last.
Route a permitted sales action
First check whether the person is a customer contact, open opportunity stakeholder, former champion, suppressed contact, competitor, employee, partner, or entirely new prospect. Each relationship needs a different owner and message policy.
- Unresolved identity: research only.
- Verified former champion at a target account: owner review with relevant history.
- Internal promotion: account-plan update before any outreach.
- New target-account contact with no relationship: apply normal prospecting, channel, and suppression rules.
- Existing customer or open deal: route to the accountable owner; do not enroll in generic outbound.
Phrase any outreach around the known relationship or role change without pretending it proves a buying project. The rep reviews the source, current account state, and message.
Handle corrections and duplicates
Use a deduplication key based on source event, person, employer candidate, and event class. A recurring alert or sync retry should update the existing observation, not create another contact and task.
Support retraction and correction. Profiles can be edited, employment dates can shift, and CRM contacts can merge. Preserve prior values and provenance, mark superseded evidence, reverse only integration-owned changes, and retain commercial history.
Test the workflow end to end
Create a consented or synthetic golden set with same-name people, stale profiles, concurrent roles, internal promotions, returns to former companies, consultants, subsidiaries, customers, open opportunities, suppressed contacts, duplicates, deleted records, and role corrections.
Score identity precision, event classification, duplicate rate, history preservation, owner routing, prohibited updates, accepted actions, correction time, and rollback. Hard-stop on wrong-person updates, suppression loss, or deleted commercial history.
Where Gangly fits
Gangly repository facts describe job-change signals through a LinkedIn browser-extension path, not an official LinkedIn API, with downstream action reviewed by the rep. Evaluate Signal Detection against current platform terms, identity, history, ownership, suppression, and correction tests. No outcome lift is claimed.