CRM workflow examples. The ones actually worth building.

Why this matters. The CRM holds the data; the workflow does the work.

Salesforce Research's 2025 figures put the average rep's CRM data entry time at around 5.5 hours a week, more than half a working day spent typing in information a workflow could capture automatically. That number is the real argument for automation: a CRM that only stores what a rep manually logs is, at best, a historical record, and most of the examples below exist to close that specific gap, moving a task from "something a rep remembers to do" to "something that happens whether or not they remember."

This sits alongside our wider work on CRM automation and the step-by-step mechanics in our guide to setting up CRM workflows. That guide covers how to build one correctly; this one is about which ones are worth building in the first place.

The eight below group into four categories: lead handling, pipeline hygiene, customer lifecycle and data quality. Build roughly in that order. Lead handling workflows touch revenue the fastest and are the easiest to justify to a team that has never automated anything before; data quality workflows matter just as much but are the hardest to get buy-in for early, because nobody feels the pain of a duplicate record until a report is already wrong.

The list, with how to apply each. Four groups, worth building in roughly this order.

Lead handling

Lead routing by rule. Assign a new lead automatically by territory, product line, or round robin the moment it enters the CRM, rather than leaving it in a shared queue for whoever checks first. The rule itself matters less than having one; teams I've worked with lose more leads to a queue nobody owns than to a badly designed routing rule.

First-response SLA reminder. A timed alert, and an escalation to a manager if it's missed, the moment a lead has gone unanswered past an agreed window. Pair it with routing above: a lead assigned instantly but not followed up for two days has gained nothing from the speed of the assignment.

Pipeline hygiene

Stage-change task creation. The moment a deal moves to a new stage, the CRM creates the next task automatically, a proposal to send, a contract to draft, rather than relying on the rep to remember what comes next. This is the single workflow that does the most to keep a pipeline report honest, because stages stop drifting out of sync with what's actually happened.

Stalled-deal re-engagement. A deal with no activity logged for a set number of days gets flagged to its owner, or routed to a manager if it stays untouched. Set the threshold by typical cycle length for that deal size, not a single number for the whole pipeline; a flag that fires too early on long enterprise deals trains reps to ignore it.

Customer lifecycle

Renewal and contract-expiry alerts. A reminder fired a set number of days before a contract lapses, early enough that a renewal conversation can happen before the deadline becomes the reason for it. The lead time should match how long that renewal conversation actually takes to have, not an arbitrary company-wide default.

Post-sale handoff to customer success. The moment a deal closes, the CRM creates the onboarding record and notifies the customer success owner with the account context already attached, so the new customer isn't asked to repeat information they already gave the sales rep.

Data quality

Duplicate-record merge prompts. A rule that flags likely duplicate contacts or accounts, by matching email domain or company name, rather than letting them sit unmerged until a report quietly double-counts a pipeline figure.

Mandatory-field checks at stage change. A deal cannot move to the next stage until a required field, deal value, close date, next step, is filled in. This single rule prevents more forecasting inaccuracy than most dashboard fixes, because a forecast is only as reliable as the fields behind it.

Where teams go wrong. Automating the notification, not the decision.

A sales team I worked with, illustrative rather than a named result, had built a genuinely impressive set of CRM workflows inside their first two months on a new system, eleven separate automations covering almost every stage change and account event they could think of. Within a quarter, reps had started muting the Slack channel the alerts posted to, because most of what landed there didn't need a human decision at all, a field had updated, a routine task had been logged, and burying those routine pings alongside the two or three alerts that did matter meant everything got the same amount of attention: none. Cutting the eleven down to four, keeping only the ones tied to an action a rep actually had to take, restored attention to the channel within a couple of weeks. The decision rule that follows: before adding a workflow, ask whether it's telling someone something they need to decide on, or just something that happened. Only the first kind earns a notification.

A second common mistake is building workflows that try to make a judgement call rather than surface one. An automation that reassigns a stalled deal to a different rep without a manager's input, for instance, tends to create more friction than it saves, because it's making a call about account ownership that genuinely needs a human to weigh in on. The workflows that hold up over time are the ones that do the mechanical step reliably and then hand the judgement back to a person, not the ones that try to remove the person from the decision entirely.

A third, quieter mistake is building every workflow at once instead of in sequence. Lead routing and the SLA reminder should go live first and run cleanly for a few weeks before stage-change automation is layered on top, because each new workflow touches the same records the last one did, and debugging three new rules firing at once is considerably harder than debugging one. Teams that build their automation roadmap in this order, lead handling, then pipeline hygiene, then lifecycle and data quality, tend to end up trusting all of it; teams that build everything in the same sprint tend to end up trusting none of it, because the first thing that goes wrong gets blamed on whichever rule happened to fire at the same time.