Skip to main content
All articles

Automation

Flow #8: hand the leads who replied to your CRM with n8n

A LinkedIn reply belongs in your CRM. Your campaign tags whoever replied; a scheduled n8n or Make workflow reads the tag through the API and opens the deal.

By Swimlane 5 min read

The gap between “they replied on LinkedIn” and “there is a deal in the CRM” is where pipelines go stale. Copying replies across is a Friday chore, done in bulk and from memory. This flow is a LinkedIn CRM integration in two halves: Swimlane’s campaign builder marks who replied with a tag, and a scheduled n8n (or Make) workflow does the paperwork on the CRM side.

The flow
  1. Message The message step your campaign already sends
  2. Condition Replied to message? Checked after a 7-day delay, window "Last 7 days"
  3. Yes Tag Add tag "replied": the campaign ends here for them
  4. Yes Pipeline In n8n, every 15 minutes: reads the tag through the API, creates the person and the deal in your CRM
  5. Yes Pipeline Still n8n: puts the contact in "In conversation" on your Swimlane board
  6. Yes Tag Still n8n: swaps "replied" for "in-crm" so nobody is handed over twice
  7. No Tag Add tag "no-reply", or the next step of your campaign

Who does what in this LinkedIn CRM integration

  • Swimlane’s campaign builder runs the message, the “Replied to message” condition and the “Add tag” step. The builder has no CRM, pipeline or webhook step.
  • n8n or Make runs the schedule, calls Swimlane’s public API, writes to the CRM, moves the contact on your Swimlane pipeline and swaps the tag.
  • The tag is the contract between the two. “replied” means “hand this person over”; “in-crm” means “done”.

Because the workflow only reads a tag, it also takes replies to messages you typed yourself: add “replied” to the contact from the conversation and the next run picks them up.

Why a tag rather than a webhook

Swimlane’s outgoing webhooks send three events: contact.created, contact.updated and contact.deleted. None of them fires when a tag is added, when someone replies or when a contact changes stage, and a webhook cannot be filtered. A webhook is the right tool to push every new contact to the CRM, and the guide to a webhook CRM integration covers that route. To push only the people who answered, reading a tag on a schedule is the mechanism that exists.

Setting up the campaign in Swimlane

  1. The condition. Under the message step, add a “Replied to message” condition with a delay of 7 days and the window “Last 7 days”. A condition looks once, when it runs: the delay gives them a week, the window ignores an answer from last spring. “Any time” would send anyone who ever wrote to you down the yes branch.
  2. The yes branch. An “Add tag” step named “replied”. Type the name; the tag is created the first time the step runs.
  3. The no branch. Whatever your campaign does next.
  4. Before launch. A launched campaign’s steps are locked, so build the branch while it is a draft.
  5. A token. Settings → API → Add Token. It is shown once: store it as a credential in n8n or Make, sent as Authorization: Bearer wpa_….

The LinkedIn automation page lists every step and condition the builder offers.

Setting up the workflow in n8n or Make

One workflow on a Schedule Trigger (a scheduled scenario in Make), every 15 minutes. Before the first run, put both tags on a test contact by hand, read their ids from GET /v1/tags (it only lists tags in use), then remove them.

  1. Read the tag. GET /v1/contacts?tag_id=<replied id>&per_page=100. Each contact comes back with its uuid, names, headline, linkedinId, tagIds and pipelineStageUuid.
  2. Upsert the person, open the deal. Search the CRM before creating anything. Key on the LinkedIn URL (https://www.linkedin.com/in/ + linkedinId) stored in a custom field, not on email, which is often empty for LinkedIn contacts. The API returns no message text, so put the profile URL on the deal and let its owner read the thread in Swimlane.
  3. Move the contact. POST /v1/pipelines/stages/<stageUuid>/contacts with {"contactUuids": ["…"]}. Stage uuids come from GET /v1/pipelines/<uuid>/stages. Use a team pipeline or one the token’s owner created. A contact holds one stage per pipeline, so this also moves them.
  4. Swap the tag, last. POST /v1/contacts/<uuid>/tags with {"tagIds": […]} replaces all of the contact’s tags. Send their current tagIds minus “replied”, plus “in-crm”. Send only the new id and every other tag is gone.

The n8n setup guide and the Make setup guide cover the token and the HTTP request.

Guardrails

  • It is not instant. The condition sees a day-one reply on day seven, and n8n on its next run. To go faster, check after 3 days and add a second “Replied to message”, with its own “replied” tag, under the no branch; or tag the contact by hand the moment you reply.
  • Swap the tag only after the CRM call succeeds. A failed run leaves “replied” in place and the contact comes back next time; searching before creating stops that retry from duplicating the deal.
  • 100 API requests a minute per user. Each contact costs two Swimlane calls. If a campaign produces dozens of replies at once, loop over them in batches with a Wait node.
  • Tags are shared by the whole workspace. The API reads every contact in the organization, so a teammate’s campaign that tags “replied” feeds the same workflow. For a shared CRM that is what you want; if not, give each team its own tag. The team and API page shows what the workspace shares.

What to measure

Contacts still tagged “replied” an hour after a run: it should be zero, and anyone left is a failed hand-off. Then the share of CRM deals that carry a LinkedIn profile URL. When it climbs, your forecast finally includes the channel it could not see.

Do this with Swimlane

Everything in this article, minus the manual part.

Start my free trial

See how it works in Swimlane Team & API

Keep reading