Notification volume is the single biggest predictor of whether a Salesforce–Slack integration gets used. Push every field change and the team mutes the channel within a fortnight; push too little and nobody opens it. The work is deciding what genuinely deserves an interruption, who owns it, and what should arrive as a digest instead. Alert fatigue is a configuration defect, not a user attitude problem.
Trusted by 500+ organizations — including sales and service teams whose Slack channels went from muted to the first thing they open.
What We Tune
Every one of these is a design decision that was never consciously taken. They are also, fortunately, the cheapest class of problem in this whole cluster to fix.
“Notify on record edit” ships as a placeholder and stays. Every field touch becomes an event, including the ones made by other automation, and the channel starts reporting on itself. Within two weeks the mute button solves it for everyone.
An alert posted to a channel of forty people is addressed to nobody. Diffusion of responsibility is not a metaphor here: the larger the channel, the lower the chance any individual acts, and the easier it is for everyone to assume someone else did.
A renewal at risk and a description field edit arrive as the same grey message in the same channel. With no visual or structural difference between them, the reader has to evaluate every one, which is exactly the cost the alert was supposed to remove.
Every requirement is implemented as an instant push because that is the default, when most of them are really 'I want to know this happened' rather than 'interrupt me'. One summary would have replaced two hundred messages and lost nothing.
There is no baseline for how many alerts fire, how many are opened, or how many are followed by the action they were asking for. Without that, tuning is guesswork and the only feedback available is a complaint.
Alert design quietly becomes an access decision. Amount, stage and contact detail posted into a broad channel widen visibility past what the Salesforce sharing model allows, with nothing in Salesforce recording that it happened.
Salesforce notification design is the decision of which record events justify an interruption, which named person or small group owns each one, what threshold makes an event material, and what should arrive as a periodic digest rather than an instant message. It is a business decision expressed in configuration, not a technical one.
What the platforms do. Salesforce provides record notifications and Salesforce channels tied to specific records, with an admin setting controlling how much record detail is shared; Flow Core Actions send messages on record change; Slack delivers them and lets each person set their own preferences on top. Salesforce documents the record-detail and subscription settings here. What none of it decides is which events are worth sending — that is left to you, and it is the part that decides adoption.
What Twopir does. We classify the candidate events by whether anyone actually acts on them, assign each to an owner rather than a channel, set thresholds against real volume, move everything that can be batched into a digest, and review the result against whether people responded — not against whether the messages were delivered.
What the client gets. A smaller number of alerts with a higher response rate, and a documented rule for what earns a push. We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges.
Every candidate event goes through this before anything is built. In a typical estate the majority of what currently fires ends up in the bottom three rows, which is where most of the improvement comes from.
| Class | The test | How it is delivered | Where it goes | Reviewed |
|---|---|---|---|---|
| Act now | Someone has to do something today, and the cost of missing it is real. | Instant message, with the record context and the action attached. | A named owner, or a small role-based group. | Monthly against response rate. |
| Be aware | It changes someone's picture of the account, but requires nothing today. | A digest, once or twice a day. | The team channel that owns the account. | Quarterly against open rate. |
| On demand | Someone will want it when they go looking, and not before. | Not pushed. Available in the Salesforce channel or by search. | The record itself. | Only when someone asks for it to be pushed. |
| Exception only | Normal is silence; the event means something has gone wrong. | Instant, and visually distinct from routine traffic. | The on-call owner, with escalation if unacknowledged. | After every occurrence. |
| Never | It fires because it can, and no one has ever acted on it. | Switched off. | Nowhere. | Confirmed at each review that nobody has missed it. |
Classification applied per event during design, then re-checked after go-live
'Notify on close-date change' is an event. 'Notify when a close date moves out by more than two weeks on a deal above the median value in the final stage' is a threshold. The first produces noise, the second produces a phone call to a customer.
Each alert names who is expected to act. Where that cannot be answered, the alert is a digest item rather than a push — because an interruption addressed to everyone is addressed to no one.
If the useful response window is a day, a daily digest loses nothing and costs a fraction of the attention. Instant delivery is reserved for events where minutes genuinely change the outcome, which is fewer of them than any first requirements list assumes.
How much record detail an alert carries is an access decision as much as a design one. Wide channels get the fact and a link; the detail stays on the record where the Salesforce sharing model still governs it.
Six workstreams. On an existing estate the first two usually produce most of the improvement before anything new is built at all.
What fires today, how often, into which channels, and — where the data exists — how often anyone responded. The baseline matters: without it, tuning is guesswork and success is unprovable.
Every candidate event run through the five classes above with the owning team, which is usually the point at which people volunteer that they have been ignoring half of it for a year.
Materiality expressed as actual criteria — value bands, stage, age, size of change — so an alert means something happened worth knowing rather than something happened.
Scheduled summaries for everything that does not need to interrupt, which is most of it. The cheapest single lever for reducing volume without losing information.
Named owners per alert, role-based groups where an individual is wrong, and an escalation path for exception alerts that go unacknowledged.
A scheduled re-check against response behaviour, because the right threshold on day one is rarely the right threshold at triple the volume.
Four phases. Phase two is where most of the value is, and it requires no build at all.
Inventory every alert, count volume per channel, and gather what response data exists. We also ask which channels people have muted, which is usually the fastest diagnostic available.
Run every event through the five classes with the team that gets them. Switching off what nobody acts on is free, immediate, and produces the largest single improvement in the whole engagement.
What survives classification gets real criteria and a delivery cadence, with digests replacing instant pushes wherever the decision window allows it.
After a few weeks of real volume, re-check against whether people responded — not whether messages were delivered — and re-tune. Thresholds are a setting that gets revisited, not chosen once.
A delivered Slack Sales Elevate engagement where over-triggered workflow conditions were one of six rollout problems found and fixed. The figures are the ones published on the case study.
The goal was never to replace Salesforce — it’s still the system of record. We just made sure the team never had to leave Slack to know what was happening in their pipeline.
Early workflow conditions triggered too many notifications and created alert fatigue across teams. Filters and trigger criteria were refined to remove duplicate alerts — a configuration fix, not a training one.
Automated case notifications routed into a field-service workspace with full attachments, so damage reports and missed-service alerts reached the office instead of sitting unseen for hours.
On the same engagement, incorrect Salesforce–Slack user mapping caused notifications to go to the wrong people or nowhere at all. No error is raised when this happens, so notification design and identity mapping have to be verified together.
Almost every notification engagement we run ends with fewer alerts firing than when we arrived, and a higher proportion of them being acted on.
The largest single improvement in a notification engagement is usually free: identify what nobody has ever acted on and stop sending it. That happens before anything is designed or built.
If the question 'who is expected to act on this' has no answer, it is not an alert. It is a digest item, and treating it as one immediately reduces volume without losing the information.
Materiality expressed as real criteria is the difference between a channel that reports changes and a channel that reports problems.
When people mute a channel, the configuration is wrong. We fix the filter rather than asking anyone to pay more attention — which has never worked anywhere.
The right threshold at launch is rarely right at triple the volume, so the engagement includes a scheduled re-check against response behaviour rather than ending at go-live.
With an inventory and a classification, not a rebuild. List every alert that currently fires, how often, and into which channel, then run each one past the people who receive it and ask which they have ever acted on. Switching off what nobody acts on is free and immediate, and in most estates it removes the majority of the volume before anything is redesigned.
There is no universal figure, and anyone quoting one is guessing. The useful measure is the proportion that get acted on: if most alerts in a channel produce a response, the volume is roughly right; if most are scrolled past, it is too high regardless of the absolute count. That is why we baseline response behaviour rather than message count.
The decision window. If the useful response happens within minutes, it earns an instant message; if it happens within a day, a daily digest loses nothing and costs a fraction of the attention. Most requirements arrive phrased as 'we want to know about this', which is a digest, but get implemented as an instant push because that is the default.
Partly, and they should — Slack lets each person tune what reaches them. But per-user preferences cannot fix an alert that should never have been sent to anyone, and in practice people do not tune settings, they mute channels. Design decides the baseline; user preferences adjust around it.
It can, and it is the part most often overlooked. Slack channel membership and Salesforce sharing rules are separate models, so posting record detail into a broad channel can widen visibility beyond what your sharing model allows, with nothing in Salesforce recording it. Salesforce provides an admin setting controlling how much record detail is shared in notifications; beyond that it is a design decision. We treat how much detail an alert carries as an access question, not a formatting one.
The most common cause is user mapping rather than the alert itself. A Slack user is mapped to a Salesforce user, and where that mapping is wrong or missing, notifications go to the wrong person or nowhere at all — with no error raised. We have found exactly this in testing on a live engagement, which is why mapping is verified per user rather than assumed from a bulk import.
At least once after the first few weeks of real volume, because the launch threshold is always slightly wrong, and then on a regular cadence tied to how fast your volumes change. An estate that doubles its record count without revisiting thresholds will drift back into fatigue on its own.
A discovery call covers what currently fires, into which channels, and which of it anyone has ever acted on. You leave with a classification of your own alerts and a shortlist of what to switch off first — which costs nothing to act on.
Fewer alerts, acted on more often
