# Salesforce Slack integration: which opportunity alerts to keep and how a manager checks the team reacts https://salesbond.app/blog/salesforce-slack-integration-opportunity-alerts-manager-check/ Published: 2026-10-25 · Updated: 2026-10-25 A Salesforce Slack integration should carry only the few opportunity events that need a human action: a stage change on a large deal, a close date pushed, no next step on an open opportunity, and closed-won. Give each alert an owner and an expected action, and once a week count how many alerts got a reply or a task the same working day. If that number is low, the problem is not the integration. It is that nobody agreed what an alert is for. ## An alert nobody acts on is just noise We have watched this on HubSpot and Pipedrive teams, and Salesforce teams are no different. The admin connects Slack, picks every opportunity field that sounds useful, and for two weeks the channel is lively. By week four people have muted it. By week eight a deal slips a quarter and the manager finds the warning in the channel, posted on a Tuesday, read by no one. The channel did not fail. The design did. An alert is a request for someone to do something. If the message does not name who should act and what the action is, it is a log line, and logs belong in a report. So the test for every alert is one question: what does a rep do in the next hour because this message arrived? If the honest answer is “nothing, but it’s nice to know”, mute it. The weekly pipeline review is the right place for nice-to-know, and we described how we run that in [a weekly Salesforce pipeline inspection](https://salesbond.app/blog/salesforce-pipeline-inspection-weekly-review/). ## What the Salesforce Slack integration can send, and how it gets connected Salesforce for Slack is not one feed but a set of apps. According to [Salesforce’s Slack integrations page](https://www.salesforce.com/products/integrations/slack/), you can search your Salesforce instance from Slack and share records into a conversation, including leads and opportunities, and pass messages both ways between Chatter and a Slack channel. Sales Cloud for Slack adds the sales layer: “view sales records, check your pipeline, get reminders, work as a team in sales channels, and stay in the loop using feed channels.” For anything custom, the same page points to MuleSoft Composer, which can use Slack as a target; Salesforce’s own example is a Slack message when an opportunity is won. The connection itself is an admin job, roughly in this order: 1. Install the Salesforce for Slack app from Slack’s app directory. [Slack’s help article](https://slack.com/help/articles/227838227) recommends it as the base the other Salesforce apps work through. 2. Add the Salesforce apps you need on top, such as Sales Cloud for Slack for pipeline views and sales channels. 3. Set up opportunity notifications. In Slack’s Sales Home, a user goes to **Manage notifications** and creates a notification from a template; Slack describes these as reminders to update opportunities, available on Business+ and Enterprise+ plans ( [Slack: Use Sales Home in Slack](https://slack.com/help/articles/18633032273939-Use-Slack-Sales-Elevate) ). 4. For alerts that go to a team channel, build a Slack workflow that starts from a Salesforce event, which the same article lists as an option. One trap for anyone following older guides: “My Alerts” and “Channel Alerts” belong to the Salesforce app built by Slack, which Slack now labels legacy and unsupported. Don’t design your channel around them. Two things follow from all this. Almost any opportunity change can become a Slack message, so the limit you hit is attention, not technology. And the mechanics are an admin task while the alert design is a management task. Decide the second before you ask for the first, or the admin will decide it for you by sending everything. ## Four deal alerts worth keeping, and the ones to mute Four alerts cover most of what a manager needs to hear about in real time. Each has a trigger, an owner and an expected action, and the expected action is the part teams usually skip. ### Large deal moved stage Fires when Stage changes on an opportunity above the team’s “large” amount, and it goes to the manager. The same day, the manager replies in the thread: approve the move or ask one question. A stage change on a big deal is where optimism enters the forecast. ### Close date pushed Fires when Close Date is edited to a later date. It is for the owning rep’s manager, and the rep answers with the reason and the new committed date. This is the quietest way a deal dies; the record looks freshly updated, so no staleness report catches it. ### No next step An open opportunity with an empty Next Step, or no open task. This one is for the owning rep, who adds a Next Step and a dated task. An opportunity without a next step has no plan, whatever the stage says, and we are strict about that for the reason laid out in [the next-step rule for Salesforce tasks](https://salesbond.app/blog/salesforce-tasks-next-step-rule/). ### Closed-won Stage set to Closed Won, posted to the whole channel. People congratulate; the manager confirms a handoff task exists. It’s the one alert allowed to be fun, and it still carries a job. What to mute, or never turn on: - Every stage change on every deal. The large-deal alert already covers the ones that matter. - Field edits other than Stage, Close Date, Amount or Next Step. Nobody acts on a changed description. - New opportunity created: useful to an owner once a week, useless as an interrupt. On the “large deal” threshold, pick one number per team and write it in the channel topic. Start with the amount where you would want a call before the forecast moves, and adjust after the first weekly check. ## Who owns the channel and what a rep does when an alert fires One channel, one owner, and the owner is a sales manager, not the Salesforce admin. The admin keeps the plumbing working, the manager decides what flows through it and answers for whether the team reacts. The rep’s job on an alert is small. For a pushed close date, the rep replies in the thread with two things: why it moved and what the next dated step is. Not a paragraph. “Buyer’s CFO is out until the 12th, demo to finance booked for the 14th” is enough. For a no-next-step alert the rep does not reply at all. They go to the opportunity, fill in Next Step, create the task, and the next alert run goes quiet on its own. For a large-deal stage change the reply comes from the manager: either “agreed” or one question about evidence, meaning what the buyer said or did that justifies the move. If the answer lives in the opportunity’s activity history, good. If it does not, the stage goes back, and [the activity timeline check](https://salesbond.app/blog/salesforce-activity-timeline-deal-check/) is how we settle that without opinions. Every one of these reactions leaves a trace a manager can count: a thread reply, a new task, an edited field. That’s what makes the weekly check possible. ## The weekly reaction check: alerts vs. actions taken The weekly reaction check counts, per alert type, how many alerts got the expected action the same working day. It takes about fifteen minutes on Friday afternoon or Monday morning. 1. Count the alerts the channel received during the week, by type. Scroll the channel or search it by each alert’s opening phrase. 2. For each alert, look for the expected action taken the same working day: a thread reply, a Next Step filled in, a task created, a close date confirmed. 3. Write down two numbers per alert type, received and acted on same day. 4. Take the worst ratio to the Monday meeting. Not “why didn’t you react” but “what would have made this one worth reacting to?” ![Empty weekly tally card with four alert types and columns for alerts received, acted on same day, and ratio](https://salesbond.app/wp-content/uploads/2026/10/salesforce-slack-integration-opportunity-alerts-manager-chec-2.png) If one alert type is received a lot and acted on rarely, either the alert is noise (mute it) or the expected action is wrong (change it). If every ratio is low, shrink the list to two alerts, because the team has already stopped reading. We think the same-day cutoff matters more than any ratio target. A close date pushed on Monday and explained on Thursday is a close date you would have found in the the pipeline review anyway, so the alert added nothing. ## Someone wants a new alert. Now what? The requests will keep coming, usually from someone who missed one deal and never wants to miss another. Our rule fits in one sentence: a new alert gets added when the requester names who acts on it and what the action is, and it gets removed at the next weekly check if that action happened on fewer than half of them. Written like that most requests either turn into a report or get withdrawn before they reach the admin. The ones that survive are usually worth keeping, and the channel stays a place where a message still means something. If your team runs on HubSpot or Pipedrive instead, the same four alerts and the same Friday count apply; we have walked through the field names for [HubSpot deal alerts in Slack](https://salesbond.app/blog/hubspot-slack-integration-deal-alerts/) and [Pipedrive deal alerts in Slack](https://salesbond.app/blog/pipedrive-slack-deal-alerts-automation/) separately. A disclosure, since this is the kind of problem we work on: we build SalesBond, a sales management layer on top of the CRM a team already uses; we started with Pipedrive. It finds the pushed dates and missing next steps across the whole pipeline, so the Slack channel only has to carry the ones that need a person today. The alert design above works with or without it. When you want the count done for you, [check your CRM with SalesBond](https://salesbond.app/).