Why this matters
The case for automation is boring and strong. Reps forget follow-ups, skip data entry after calls and let won deals slip into delivery without a handoff. Automations do not forget. The core set below returns roughly an hour per rep per week and, more importantly, makes the process consistent enough to measure.
The case against is just as real. Every automation is invisible machinery. It keeps running after the process changes, after its author leaves, after the field it writes to is renamed. An account with forty undocumented workflows is scarier than an account with none, because nobody dares touch anything. The discipline is to automate proven manual process, never hoped-for process. That is why automation comes last in our six step method.
The design decisions that matter
Decision one: the admission test. An automation earns its place when it removes a task someone demonstrably does by hand today, at least weekly. Automating a step nobody performed manually means automating a guess.
Decision two: stage changes as the spine. Almost everything useful hangs on the trigger deal updated with the condition stage has changed. This is also why stage design precedes automation. Automating a broken pipeline pours concrete over the cracks.
Decision three: activity creation over email sending. An automation that creates a call task keeps the human in the loop. An automation that emails the customer removes them. Start with tasks, add automated email only where the message is genuinely standard.
Decision four: ownership and naming. One person owns the automation list. Every automation gets a name in the form of trigger, then effect. Deal to Proposal sent, create follow-up call. Six months later that name is the documentation.
A worked example
The starter set we deploy in most implementations. Five automations, all native, no external tools.
| Trigger and condition | Action | Removes |
|---|---|---|
| Deal created | Create activity: qualification call, due in 2 days | New deals sitting untouched |
| Deal updated, stage changed to Proposal sent | Create activity: follow-up call, due in 3 days | The forgotten quote chase |
| Deal updated, stage changed to Proposal sent | Send templated email: proposal cover note, from owner | Retyping the same email |
| Deal updated, status changed to won | Create activity for delivery lead: kickoff, plus Slack notification | Won deals lost in handoff |
| Deal updated, status changed to lost | Create activity: revisit in 90 days, if lost reason is timing | Cold revival lists built by hand |
Each one was tested by moving a single dummy deal through the pipeline before going live. Each one writes something a human will see and can question. None of them changes data silently, which is a property worth protecting as the list grows.
Common mistakes
Automating the customer relationship away is the expensive one. Drip sequences firing at every stage read as machinery within two emails, and replies drop. Automate your own admin, and keep customer-facing sends few and owner-signed. The follow-up templates themselves belong with your quote workflow.
Second, the orphan workflow. Its author left, its purpose is folklore, and everyone is afraid to disable it. The naming convention and the single owner exist to prevent this, and the quarterly review below catches the ones that slip through.
Third, automations papering over missing data. If a workflow needs a field that is empty half the time, it misfires half the time. Fix the field discipline first, then automate on top of data you trust.
Maintenance
Monthly, the owner opens the execution history and scans for failures and surprises. A workflow that fired 400 times when its process happens 40 times a month is telling you something. So is one that never fires at all.
Quarterly, walk the full list against the current process. Disable rather than delete, and leave disabled workflows visible for a quarter before removing them. When a stage is renamed or a field retires, search the automation list for it the same day. The list stays under ten items far longer than anyone expects, and that is the sign of health, not of underuse.
Questions
What can Pipedrive workflow automations trigger on?
Creation and updates of deals, people, organizations, leads, activities and projects. The workhorse is deal updated with the condition that the stage has changed, which powers most stage-driven automation.
What actions can an automation take?
Create or update deals, activities, people and leads, send or schedule templated email, send Slack or Teams notifications, and add delays between steps. That covers the useful majority of sales process automation.
How many automations should a team run?
Fewer than you think. A healthy small team runs five to ten. If you cannot say from memory what your automations do, you have too many, and one of them is quietly doing something wrong.
Can an automation trigger another automation?
Yes, an automation that updates a deal can fire one that triggers on deal updates. That enables chains and also loops. Keep chains short, name them so the sequence is obvious, and test with one record first.
Should automated emails come from the deal owner?
Yes. Automated sends go through the connected mailbox of the owner, and that is how it should read. An email from a system address announces itself as a robot and gets treated like one.