Most Salesforce–Slack automation works perfectly on ten records and falls over on ten thousand. Messages fired from inside a trigger hit governor limits, fail silently, and take the alert nobody noticed was missing with them. We build the Salesforce side properly: queued delivery, deliberate entry criteria, and errors that reach a person. Flow, Platform Events and Apex — bulk-safe by default.
Trusted by 500+ organizations — including revenue and service teams whose Salesforce automation has to hold up on load day as well as on a demo.
What We Automate With
Salesforce-side automation fails in ways that are specific to Salesforce. Every one of these is a limit or a design choice, not a Slack problem.
A Slack message sent per record from a trigger works in a demo and dies on the first bulk update. The limit is reached, the transaction rolls back or the messages are lost, and nothing tells anyone — the alerts simply stop for that batch.
Automation accretes. Three record-triggered flows, a legacy workflow rule and a trigger all fire on Opportunity, two of them post to Slack, and nobody can say which one sent the duplicate. Order of execution stops being predictable long before anyone admits it.
A data load updates four thousand records and the channel receives four thousand messages. The automation is behaving exactly as designed; the design simply never considered that records change in batches as well as one at a time.
A delivery fails, the exception lands in a debug log or an unmonitored error object, and the first person to notice is the rep who asks why they stopped getting renewal alerts three weeks ago.
“Fire when the record is edited” ships as a placeholder and stays. Every field touch becomes an event, including the ones made by other automation, which is how a channel starts talking to itself.
Channel IDs and user IDs written into a Flow or an Apex class mean every change is a deployment, and a sandbox refresh silently points production alerts at a channel that no longer exists.
Salesforce Slack automation is automation that originates in Salesforce — a record change, a scheduled job, an approval event or a platform event — and reaches into Slack to post a message, open a channel or offer an action that writes back. It is built by a Salesforce admin or developer, in Flow or Apex, and it lives under Salesforce's governor limits.
Where the boundary sits. Automation that starts in Slack — a form, a request, an incident declaration — is a different discipline with different tools and a different owner. That is Slack workflow automation, built in Workflow Builder. Most estates need both, and the two meet at a documented handoff rather than overlapping.
What the platform does. Salesforce ships Flow Core Actions for Slack — actions that send a Slack message, post to a channel, or send a message that launches a flow from Slack — documented by Salesforce Help. Platform Events and Queueable Apex provide the asynchronous path that keeps delivery out of the triggering transaction.
What Twopir does. We decide which mechanism carries each requirement, design entry criteria that fire once rather than five times, queue anything that could run in bulk, and make failures visible. We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges.
Most estates use two or three of these together. The common mistake is using the first row for everything, which works until the first bulk update.
| Mechanism | What it is | Best for | Built by | Where it runs out |
|---|---|---|---|---|
| Record-triggered Flow + Flow Core Actions | Declarative automation reacting to a record change and calling a Send Slack Message action. | Event-driven alerts on a manageable volume of record changes. | Salesforce admin | Synchronous inside the transaction. Bulk operations need the queued path below. |
| Scheduled Flow or Scheduled Apex | A job that runs on a schedule and posts a summary rather than reacting to each change. | Digests, stale-record sweeps and anything where one message beats two hundred. | Salesforce admin or developer | Not real time by definition. Wrong choice where minutes matter. |
| Platform Events | A record change publishes an event; a separate subscriber delivers to Slack outside the original transaction. | High volume, bulk loads, and anywhere delivery must not block or roll back the save. | Salesforce developer | More moving parts, and the subscriber needs its own error handling and monitoring. |
| Queueable or Batch Apex | Delivery handed to an asynchronous job, processed in controlled batches. | Bulk sends, retries and anything that must respect rate limits deliberately. | Salesforce developer | It is code: tests, a release process and an owner. Not the first thing to reach for. |
Mechanisms verified against current Salesforce documentation
A stage change, an owner change or a status flip publishes to the channel that owns it, with the record context attached rather than a bare 'a record changed' line. Built in Flow where volume allows, and moved behind a platform event where it does not.
Stale opportunities, unworked leads and ageing cases summarised once rather than announced individually. A digest is usually the correct answer to a requirement that arrives phrased as 'we want to know about all of these'.
Data loads, mass updates and integration writes route through Platform Events or Queueable Apex so a four-thousand-record update produces a summary rather than four thousand posts, and never takes the triggering transaction down with it.
The return leg. A button in the message writes back to the record under the acting user's own permissions, so a rep cannot update through Slack what they could not update in Salesforce.
Six workstreams. Most engagements start with the first three, because an estate that fires unpredictably cannot be extended safely until it fires predictably.
Every Flow, workflow rule, trigger and Apex class that touches Slack, in one inventory, with the duplicates and the dead ones named. Usually the first useful deliverable, because most estates contain automation nobody remembers commissioning.
One record-triggered flow per object where possible, with entry criteria tight enough that it fires on the change you meant and not on every field touch. Order of execution made predictable again.
Platform Events or Queueable Apex behind anything that can run in bulk, so a data load produces a summary rather than a flood and never rolls the save back.
Scheduled jobs that batch what does not need to be instant, which is usually most of it. The cheapest way to reduce alert volume without losing information.
Failures logged to a queryable object, grouped by cause, with a named owner alerted — because a delivery integration that stops silently is indistinguishable from a quiet week.
Channel and user references held in custom metadata or settings rather than written into a Flow, so a change is a configuration edit and a sandbox refresh does not repoint production.
Four phases. The first two are worth doing even if you stop there — an inventory and a set of tightened entry criteria fix a surprising share of complaints about alert noise.
Every automation touching Slack, what triggers it, how often it ran last month, and which ones duplicate each other. We include the ones that error, because those are usually the ones nobody knew about.
Entry criteria narrowed to the change that was actually meant, duplicate automations merged, and dead ones retired. This is where most of the noise reduction comes from, before anything is rebuilt.
Anything that can be triggered by a data load or a mass update is moved onto Platform Events or Queueable Apex, with batch sizes set deliberately rather than left at whatever the default was.
Error logging, retry behaviour and a named owner per automation, plus documentation your admins can maintain. Where we wrote code, it ships with tests and we say plainly which parts need a developer.
A delivered Slack Sales Elevate engagement on Sales Cloud, where workflow alerts replaced manual record updates. 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.
Workflow alerts built for stage changes, closed-won and renewals so deal events fire the moment a record moves, instead of being re-entered by hand.
On the same engagement, early workflow conditions triggered too many notifications and created alert fatigue across teams. It was fixed by refining filters and trigger criteria — not by asking people to pay more attention.
Automated case notifications routed into a Slack workspace structured around sites and crews, for a mostly non-desk workforce.
Automation is easy to make work once. The engineering is in making it keep working when the record count, the user count and the number of other automations all go up.
Delivery is queued through Platform Events or Queueable Apex rather than fired inline. It costs a little more on day one and it is the reason the integration is still standing after a data load.
Most alert-noise complaints are solved by narrowing entry criteria on automation that already exists. We do that first, because it is faster and cheaper than anything we could build instead.
Errors go to a queryable object grouped by cause, with an owner attached. Silent failure is the worst property an alerting system can have, and it is the default unless someone designs it out.
Channel and user references live in configuration, so changing them is an edit rather than a deployment, and a sandbox refresh cannot quietly repoint production alerts.
A large share of what arrives as a development request is a Flow action and a tightened filter. We will tell you that before you pay for code.
Direction and ownership. This page covers automation that originates in Salesforce — a record change, a scheduled job, a platform event — and reaches into Slack, built by a Salesforce admin or developer in Flow or Apex. Slack workflow automation covers processes that start in Slack, built in Workflow Builder by an ops lead. Most estates need both, and they meet at a documented handoff rather than overlapping.
Yes. Salesforce ships Flow Core Actions for Slack, including actions to send a Slack message, post to a channel, and send a message that launches a flow from Slack. For event-driven alerts on a manageable volume of record changes that is the right tool and no code is required. The point at which it stops being sufficient is volume, not complexity.
Because it runs inside the triggering transaction and under Salesforce's governor limits. A message per record is fine on a single update and fails on a bulk one — the limit is reached and the messages are lost or the transaction rolls back. The fix is to move delivery out of the transaction, using Platform Events or Queueable Apex so records are processed in controlled batches.
By deciding up front what bulk changes should produce. Usually the answer is one summary rather than one message per record, which means routing bulk paths through a queued delivery mechanism and adding a scheduled digest. It is a design decision taken before the load, not a setting to change after it.
Yes, and it is one of the most common engagements we take. We inventory every Flow, workflow rule, trigger and Apex class touching Slack, identify the duplicates and the ones that error, consolidate to one record-triggered flow per object where possible, and tighten entry criteria so each fires on the change it was meant for. Order of execution becomes predictable again, which is usually the real complaint.
Not for the core Salesforce-to-Slack path. Because Salesforce owns Slack, the first-party tools handle it natively with no middleware licence to buy. A third-party integration platform earns its place when Slack is one leg of a wider flow involving systems outside Salesforce — and we do build those, but we will not put a middleware hop in the middle of a connection that does not need one.
Only if somebody built that in. We log failures to a queryable object, group them by cause, and alert a named owner, because an integration that stops delivering looks exactly like a quiet week. If your current setup has no error path, assume some alerts have already stopped and start with the audit.
A discovery call covers what automation currently touches Slack, what runs in bulk, and where the silent failures are likely to be. You leave with an inventory and a view on what to tighten first.
Salesforce architects who build for load day, not demo day
