Follow-up rules
Understand how built-in follow-ups are created, updated, and counted.
When to use this
Use this when you need to understand why a follow-up exists, which surface created it, or why it appears in dashboard, navigation, or admin counts.
Follow-up rules are built into the current pipeline and lifecycle flows. They are visible here for review and provenance, not configurable automation.
Current built-in rules
Rendering flowchart...
| Trigger | Condition | Action | Provenance |
|---|---|---|---|
| Pipeline call attempt finished | A newer completed outreach exists | Complete active follow-ups from older attempts | pipeline_call_attempt |
| Pipeline call attempt finished | nextFollowUpAt is present | Keep only the newest dated next action active | pipeline_call_attempt |
| Pipeline timeline prompt saved | No active saved prompt follow-up exists | Create a prompt follow-up | pipeline_timeline_prompt |
| Pipeline work panel task | User enters a task title | Create a manual pipeline task | pipeline_work_panel |
| Complete, snooze, or reassign | Existing follow-up is accessible to the session | Update status, due date, or owner | Work activity where supported |
| Contact or company archived | Open related work remains | Cancel active follow-ups | System lifecycle cleanup |
When another touch is needed, add follow-up context before saving the pipeline outcome.
Where follow-ups appear
Rendering flowchart...
The admin Follow-ups page is for organization-wide review, filtering, drawer review, reassignment, snoozing, and completion. Employees see assigned next actions from dashboard, notification, and pipeline work surfaces.
Dashboard and navigation counts use actionable due buckets. Follow-ups tied to closed or archived pipeline work, retired bad-contact reviews, and outreach superseded by a later completed attempt remain available for audit but do not inflate the actionable overdue count.
Future workflow builder
Rendering flowchart...
Future builder work should stay separate from the current built-in rules. The intended model covers triggers, conditions, actions, delays, run history, versions, and visual editing. These built-in rules should remain code-owned until they are explicitly migrated.