Sync Pipedrive Deal Stages from Product Milestones via Webhook

A pipeline stage is supposed to describe reality, but in most CRMs it describes the last time a salesperson remembered to drag a card. This blueprint inverts that: the product itself reports milestones through a webhook, and io.kestra.plugin.pipedrive.deals.Update moves the deal to the stage that matches what the customer actually did. An activated account advances to evaluation, an account crossing the expansion threshold advances to negotiation, and unmapped milestones are logged rather than dropped.

How it works

1. The product_event_webhook trigger (io.kestra.plugin.core.trigger.Webhook) receives a JSON body carrying dealId and milestone from your product analytics or event bus.
2. route_milestone (io.kestra.plugin.core.flow.If) matches milestone == 'activated' and runs move_to_evaluation, a deals.Update that sets stageId: 3.
3. The else branch nests a second If: expansion_ready runs move_to_negotiation with stageId: 4, and anything else lands in log_unmapped, so a new product event type shows up in the logs instead of disappearing.
4. notify posts the processed milestone and deal id to Slack after the branch completes.
5. The errors block posts a distinct Slack alert naming the milestone and deal that failed to apply.

What you get

• Pipeline stages driven by product behavior instead of manual card-dragging.
• An explicit, versioned mapping from milestone to stage that lives in YAML, reviewable in a pull request.
• A log trail for unmapped milestones, which is how you discover the product started emitting events sales never heard of.
• A Slack feed of every automated stage move, so reps trust the automation instead of fighting it.

Who it's for

• Product-led growth teams whose CRM lags days behind what accounts are doing in the app.
• Revenue operations teams codifying stage definitions as executable rules instead of tribal knowledge.
• Sales engineers tired of end-of-week CRM archaeology to reconstruct what happened.

Why orchestrate this with Kestra

The mapping between product milestones and pipeline stages is business logic, and business logic deserves version control, branching, error alerts, and an execution history. Kestra gives the webhook, the If tree, the CRM update, and the notification one home, so when someone asks why a deal moved, the answer is an execution link rather than a shrug.

Prerequisites

• A Pipedrive account and API token, plus the stage ids of your target pipeline (Pipedrive exposes them in the pipeline settings).
• A product analytics tool or event bus able to POST JSON milestones with dealId and milestone fields.
• A Slack incoming webhook for move notes and failure alerts.

Secrets

• PIPEDRIVE_API_TOKEN: Pipedrive API token.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

1. Add both secrets to your Kestra namespace and replace the webhook key with a strong random value.
2. Replace the example stageId values 3 and 4 with real stage ids from your pipeline.
3. POST a test payload such as {"dealId": 1, "milestone": "activated"} to the webhook URL.
4. Confirm the deal moved in Pipedrive and the note appeared in Slack.

How to extend

• Add more milestone branches, or replace the nested If tree with a io.kestra.plugin.core.flow.Switch on the milestone value as the mapping grows.
• Set probability alongside stageId in the update so the forecast moves with the stage.
• Mark a churn-risk milestone by updating status to lost with a matching stage instead of advancing.
• Feed the same webhook from multiple sources and include a source field in the Slack note for attribution.

Links

• Pipedrive plugin documentation
• Pipedrive API documentation