# Pipeline automation, stage by stage > A catalogue of automations we have actually built, arranged by pipeline stage, with the flexibility each one costs and the condition under which it stops earning its place. - Source: https://synconai.com/insights/sales-pipeline-automation-examples - Publisher: SynconAI (https://synconai.com) - Desk: Sales Cloud - Author: SynconAI Delivery Team, Consulting & implementation - Published: 30 March 2026 - Updated: 29 August 2026 - Reading time: 11 minutes - Topics: Sales Cloud, Automation, Pipeline, Flow, Sales Process ## Key points - Every automation buys speed with flexibility. The speed is visible on day one and the flexibility is spent silently over the following two years. - Key stage automation off evidence the record already holds rather than off the picklist alone, because a stage value moves for reasons that are not always about the deal. - The removals are the useful list. Most came out because they encoded a sales motion that changed, and nobody noticed the encoding was still running. - Write the removal condition at build time. An automation with no stated end condition never acquires one, and it outlives the process it was built for. --- The design principles are settled elsewhere. We set them out in [Sales Cloud automation that reps do not work around](/insights/sales-cloud-automation-best-practices), and the short version is that a rule which removes work gets adopted, and a rule which adds work gets satisfied rather than answered. What that article does not give you is a list. This one does. Below is the catalogue we build from, arranged by pipeline stage, with three things stated for each entry: what it does, what it costs in flexibility, and the condition under which it stops being worth keeping. The third item is the one that usually goes unwritten, which is why so many orgs run automations nobody can justify and nobody dares switch off. ## Two questions asked of every entry Before an automation goes on the list it has to survive two questions, and both are about cost rather than benefit. The first is what the automation makes harder. Every rule removes a degree of freedom somewhere. A field that gets derived cannot easily be set by hand. A task that gets generated has to be closed even when it is not relevant. A gate that enforces an order stops any deal that arrives in a different order. None of that is a reason not to build it, but a build decision made without naming the cost is a decision made on half the information. The second is what would have to be true for us to remove it. If nobody in the room can answer that, the automation has no end condition, and an automation with no end condition is permanent by accident rather than by choice. ::: takeaways Write the removal condition into the same ticket as the build. It takes one sentence, it is the only part of the record that will still be useful in two years, and it is the difference between an estate you can prune and an estate you can only add to. ::: ## Before the opportunity: lead and qualification Automation at this end of the pipeline is cheap, because there is little judgement in play and almost nothing yet worth protecting. **Assignment on a derived territory.** The lead lands, a rule reads country, employee band and product interest, and it sets an owner. It removes the daily triage meeting and the twenty minutes of nobody-owns-this that follows every campaign send. What it costs is the ability to route by hand, which matters more than teams expect during a reorganisation or when someone is on leave. It stops earning its place the moment the territory model changes faster than the rule does, so any organisation restructuring its patch more than once a year should keep a manual override on the same screen. **A first-touch task with a due date.** On lead creation, generate the call task, due same day, with the campaign context written into the subject. This one is close to free: it is the task the rep would have written for themselves, so it costs nothing in flexibility and gets adopted without a change programme. It stops being worth it only when volume outruns capacity, at which point the queue fills with overdue tasks and the whole task list stops carrying signal. **Conversion field mapping.** Carry campaign, source, qualification notes and the original enquiry text through to the opportunity automatically. The cost here is subtle: the mapping hardens the definition of what a lead is, so changing the lead model later means revisiting the mapping and every report built on it. That is an acceptable price. It is only wrong when the mapping starts inventing values to satisfy required fields on the opportunity, and at that point the problem is the required fields rather than the mapping. ## Early stage: creating and shaping the opportunity This is where most estates put too much in, because the opportunity object is where the reporting pressure lands. **Derive everything derivable at creation.** Currency, price book, region, industry, account tier, the default sales process: all of it can be read from the account, and none of it should ever be typed. This is the highest-return automation on the list and among the lowest in cost, because the rep loses nothing they wanted. The thing to watch is derived values that later need correcting. Make them editable, and log when they are edited, because a field manually corrected on a third of records is telling you the derivation is wrong. **Generate the stage-appropriate next task on stage change.** When the opportunity moves into discovery, create the discovery call task. Into solution, create the demo preparation task. The cost is real: the task set encodes a sales methodology, and when the methodology shifts the tasks become noise before anybody updates them. The condition for removal is measurable. If reps are closing the generated tasks in bulk without opening them, the automation is producing administrative work rather than removing it, and it should come out or be rewritten. **A stage-entry snapshot.** On every stage change, write the date and the stage-entry amount into their own fields. Nothing is enforced, nothing is blocked, and the rep experiences no cost at all. What you get is stage duration and amount drift, the two measurements that make an ageing report worth reading. We have never removed one of these. ::: tip Snapshot automations are the quiet winners in most estates. They add no friction, they cannot be worked around because the rep is not involved, and the data they produce answers the questions pipeline reviews actually ask. Build them before you build anything that gates. ::: ## Mid stage: pricing, approvals and alerts Here the automation starts to cost something, because it begins to touch decisions rather than data. **Discount threshold approval.** Above an agreed discount, route for approval before the quote can be sent. The flexibility cost is entirely predictable: reps structure the deal to land just under the threshold, which is not misconduct, it is competent people responding to an incentive you created. Keep the approval, and treat the clustering of discounts just below the line as a monitoring output rather than a surprise. It stops being worth it when the approver approves everything within an hour, because at that point it is a delay dressed as a control. **Ageing alerts on stage duration.** Using the snapshot fields above, notify the owner and the manager when a deal has held a stage beyond the typical duration for its segment. This is genuinely useful and it degrades faster than anything else on the list. Set the threshold too tight and the alert fires on half the pipeline, at which point it is filtered into a folder and the escalation path stops escalating. Review the threshold against actual cycle times every couple of quarters, or accept that you have built a notification nobody reads. **Competitor and close-plan prompts.** When a deal passes a value threshold, prompt for the competitive picture and the mutual close plan. The cost is the usual one for anything that asks a rep for input: it will be satisfied cheaply if the rep cannot see the return. Prompt rather than block, and measure how often the prompt is actioned. If it is rarely actioned and those deals still close, the field was not load-bearing. ## Late stage and after close **Closed lost reason with a short, honest picklist.** Six values, each of which someone would actually pick, plus a free-text box nobody is forced to fill. The cost of a longer list is not administrative, it is analytical: a fifteen-value picklist produces fifteen small piles that support no conclusion. This automation stops being worth it if the most-used value is Other, because that means the list does not describe your losses. **Closed won handover.** Create the onboarding record, notify delivery, copy the agreed scope and the key contacts across. This is the highest-value automation in most estates and the one most often left manual. Its flexibility cost is that the handover now happens in one shape, so an unusual deal has to be reshaped to fit or handled outside the process entirely. **Renewal opportunity creation.** Generate the renewal at a fixed horizon before contract end. Useful, and it quietly assumes a renewal model. If the business moves to consumption pricing or to auto-renewing terms, the automation keeps producing records that describe a commercial arrangement you no longer have. That is the removal condition, and it is one almost nobody writes down. ## The stage-by-stage pattern table This is the summary we hand to clients, and it is arranged so the last column is the one you read. | Stage | Automation | Trigger | Trade-off accepted | | --- | --- | --- | --- | | Lead | Territory-based assignment | Lead create or update | Manual routing becomes an exception path, awkward during reorganisation | | Lead | First-touch task with due date | Lead create | Task list loses signal once volume exceeds capacity | | Conversion | Field mapping to opportunity | Lead convert | Lead model changes now require a mapping and reporting revisit | | Early | Derive currency, price book, region, tier | Opportunity create | Derived values need an audited manual override | | Early | Stage-appropriate next task | Stage change | Encodes one methodology, becomes noise when the methodology shifts | | Early | Stage-entry date and amount snapshot | Stage change | Nothing material, the rep is not involved | | Mid | Discount approval above threshold | Quote or amount change | Deals cluster just under the threshold | | Mid | Ageing alert on stage duration | Scheduled, daily | Degrades into filtered noise if the threshold is not maintained | | Mid | Competitive and close-plan prompt | Amount above threshold | Answered cheaply wherever the rep sees no return | | Late | Closed lost reason capture | Stage set to closed lost | Short list loses nuance, long list loses conclusions | | Post | Onboarding handover record | Closed won | One handover shape, unusual deals get reshaped or bypass it | | Post | Renewal opportunity generation | Contract end minus horizon | Assumes a renewal model the business may move away from | ## Automations we have removed again Nobody publishes this list, which is unfortunate, because it is more instructive than the build list. **A validation rule requiring next step on every save.** Completion went to nearly total within a fortnight. The entries were full stops, the word Follow, and the previous entry copied forward. It came out because it was generating text rather than collecting it, and because the pipeline review was reading those entries as though a rep had thought about them. **An alert to the manager on every close-date change.** Built to give early warning of slippage. What it produced was a manager with a full inbox and reps who learned that moving a date started a conversation. Within a quarter the dates stopped moving until the final fortnight, and the organisation had traded a working early-warning signal for a notification. It was replaced with a monthly report on slippage patterns by segment, which nobody has to react to individually. **Automatic stage advancement when a quote was sent.** It looked like a clean derivation. It was not, because sending a quote is a seller action and the stage was supposed to record buyer progress. Deals arrived in the late-stage report having done nothing except receive an email attachment. The full reasoning sits in [opportunity stages that mean something in a forecast](/insights/salesforce-opportunity-management-best-practices). **Overwriting the rep's amount with the sum of opportunity products.** Defensible, tidy, and it silently destroyed a number reps were measured on. Once a field is overwritten without warning, people stop maintaining it, and within two months the amount on early-stage deals had become meaningless because nobody bothered any more. **A required close plan on every deal above a mid-sized threshold.** The threshold caught a large volume of routine renewals that needed no plan at all. The template was completed with three words and a full stop. Removed, then rebuilt as a prompt on deals above a much higher value, where the plan gets written because it is genuinely useful to the rep. **A Chatter post on every stage change.** Well intentioned, and it turned the feed into a ticker nobody read, which then meant the genuinely important posts went unread too. The removal cost nothing and restored a channel. ## What the removals have in common Read those six together and a pattern appears that is more useful than any individual case. Four of the six came out because they encoded something that changed: a methodology, a commercial model, a definition of what a stage meant. The automation kept running perfectly and kept producing an answer to a question the business had stopped asking. Nothing raised an error, because nothing was broken. The other two came out because they consumed a signal. The close-date alert consumed slippage warnings. The amount overwrite consumed the rep's own estimate. In both cases the organisation ended up with less information after the automation than before it, while believing it had more, and that is the most expensive failure mode on this page. ::: warn An automation that quietly stops being right produces no error. The only way to find these is to look at what the organisation does with the output. An alert everyone filters, a task everyone bulk-closes, a field everyone overwrites: three short queries, each of them naming an automation that has outlived its reason. ::: ## Choosing what to build next The ordering that has worked for us is not the ordering clients usually ask for. Build the derivations first, because they cost nothing and remove keystrokes. Build the snapshots second, because they are invisible to the rep and they make everything downstream measurable. Build the handovers third, because a bad handover is felt by the customer. Then, and only then, consider the alerts and the gates, which are the entries in this catalogue that cost real flexibility and need real maintenance. Salesforce documents the platform capability in its own [sales automation](https://www.salesforce.com/sales/what-is-sales-automation/) and [pipeline](https://www.salesforce.com/sales/pipeline/) material, and [Sales Cloud](https://www.salesforce.com/sales/cloud/) will let you build every entry above in an afternoon. That is the risk rather than the benefit. The constraint is not what the platform can do, it is what the organisation can maintain, and a catalogue of a dozen well-understood automations beats forty that nobody can explain. Whether the team will use any of it is a separate question, and one we take up in [why Sales Cloud adoption stalls](/insights/improve-sales-cloud-adoption). ::: note Once a quarter, take the automation inventory and put three dates against each entry: when it was built, when it was last reviewed, and what would have to be true to remove it. Any row where the third column is blank is a row where nobody owns the decision, and those are the ones still running long after the process they served has gone. :::