Skip to content

Workflow automation

The workflow automation add-on runs trigger → action rules on your leads, so routine pipeline work happens by itself.

Watch: Every lead, acted on (0:54)
Trigger Fires when Narrow it by
Lead created A new lead arrives
Stage changed A lead moves stage The stage
Score crossed A lead’s score passes a threshold Threshold and direction
Lead inactive No activity for N days (daily sweep) Days
Booking no-show An appointment is marked no-show
Ticket checked in A lead’s event ticket is scanned at the door
Lead assigned A lead gets an owner The member or the department
Tag added A tag is put on a lead The tag
Field changed Temperature, value, company, job title, source, campaign, event or currency changes The field
Email opened A lead opens a tracked email
Link clicked A lead clicks a tracked link The link’s domain
Replied A lead replies to a tracked email Human replies only, or any
Booking requested, confirmed, cancelled, rescheduled The booking changes state
Task overdue A task on the lead passes its due date (hourly check) Priority
Task completed A task on the lead is marked done Priority
Deal won, deal lost The lead’s deal closes Minimum value
Handed to a person An AI employee opens a handoff on the lead The agent’s role

Optionally narrow any trigger further with an advanced filter expression (e.g. score > 40 && tags contains "enterprise"). in_segment(lead, 12) is true when the lead matches segment 12, and works the same way in lead scoring rules. The id is the # number beside the segment’s name in the segment editor. A segment that such an expression uses cannot be deleted until the expression no longer names it.

Open and click triggers fire at most once per rule and lead per day, so a rule that sends an email never answers the open of its own message.

A rule runs for every lead by default. Set its Audience to one segment and it only runs for leads that match it. Lynqu checks when the rule fires and again when it runs after its delay, so a lead that left the segment in between is skipped, and the runs history says the lead is not in the rule’s audience segment.

Send a follow-up template also respects the template’s A/B variants: the rule names the template, and each lead gets the version the test gives it.

Up to 5 per rule, run in order:

  • Messages and people: send a follow-up template, notify someone in-app, post to Slack or Teams, fire an outgoing webhook.
  • Notes and tasks: add a note to the lead, add a task to the lead.
  • Ownership: assign (member or department round-robin), unassign.
  • Pipeline: move stage, move to another pipeline, set temperature, add or remove a tag, adjust score, create a deal, push to your CRM.
  • Growth: add to a campaign, start enrichment, propose meeting times, hand the lead to an AI employee.

Message templates take the same tokens as follow-up emails ({{lead.first_name}}, {{employee.name}}, {{campaign.name}} and the rest).

Send a follow-up template picks from team templates. When the lead’s owner has their own version of that template, their version is sent, unless the team template is locked. See team and personal follow-ups.

Rules never trigger other rules. No loops, ever.

Organization → Automation (manager+). Start from a scenario in the gallery (“speed-to-lead assignment”, “no-show recovery”, “cold lead win-back”) or from scratch.

Test a rule before you trust it. Pick a lead and Lynqu answers: would this rule fire for this lead, if not why not, and what each action would do. Nothing is written and nothing is sent.

Every rule keeps a runs history showing what fired, when, and what each action did. It also records the times a rule looked at a lead and did not run, with the reason: the rule was paused, the condition no longer held, the filter did not match, the lead was not in the rule’s audience, the add-on lapsed, the lead was closed, or sending is switched off. An action that could not run (Slack not connected, no one to notify) says so instead of reporting success.

Each rule shows its totals: runs, completed, partly completed, failed, skipped, and the last error. History is kept for 90 days. The one exception is an inactive-lead rule: its last run for a lead that is still idle is kept, so the rule does not fire again for the same idle stretch.

  • One job per rule; compose small rules instead of one mega-rule.
  • Watch the runs panel after enabling a new rule.
  • Use tags as breadcrumbs between rules (“nurture-sent”) so filters can exclude already-processed leads.