Most Salesforce–Slack projects are scoped from a feature list rather than from where the team actually loses time. Twopir Consulting starts with the process and the org you already have, works out which problems are worth solving, and tells you which of them need custom development and which are a Flow action and a channel policy. Advice first, and an honest answer about how much of this you need.
Trusted by 500+ organizations — sales, service and revenue operations teams deciding what to build across Salesforce and Slack.
What We Advise On
Nobody sets out to build the wrong thing. These are the six ways it happens anyway — and each of them is a decision that was never consciously taken.
Someone reads what Slack can do, and the requirements become a list of features rather than a list of problems. The build succeeds on its own terms and changes nothing, because no one asked which part of the week it was supposed to give back.
A requirement arrives sounding technical, so it goes to a developer. A large share of what we are asked to build turns out to be a Flow action and a channel naming rule. Nobody checked, because checking is somebody's job and it was not assigned.
The first release is whatever was easiest to agree on, not whatever the rest depends on. Six weeks later the second phase needs the data model changed anyway, and the first phase is rebuilt rather than extended.
The integration is delivered to a team that was not asked whether it wanted it. Alert thresholds are never revisited, channels multiply, and within two quarters the thing everybody asked for is the thing everybody mutes.
Slack channel membership and Salesforce sharing rules are separate models. If nobody owns the question of how they line up, the answer gets set by default — usually wider than anyone intended, and with nothing in Salesforce recording that it happened.
The project closes without a baseline, so the only available verdict is whether people say they like it. Anything you cannot measure against a before-state is, at renewal time, indistinguishable from something that did nothing.
Salesforce Slack consulting is advisory work: deciding which parts of a sales or service process should surface in Slack, which of the platforms’ own capabilities can carry each one, and in what order to build them. It is distinct from the build itself. The deliverable is a set of decisions with reasons attached, not a configured org.
What the platforms do. Salesforce and Slack ship almost everything most teams need: the Salesforce for Slack apps, Salesforce channels that tie a channel to a record, Flow Core Actions that send and act on Slack messages, Slack Workflow Builder with a Salesforce connector, and the Apex SDK for Slack when code is genuinely required. Because Salesforce owns Slack, none of this needs middleware. The capabilities are documented by Salesforce Help and Slack.
What Twopir does. We work out which of those capabilities your process actually needs, where the boundary between configuration and custom development falls for your requirements, and what to build first so the second phase extends it rather than replaces it. Where the answer is “you do not need us for this”, that is the answer you get.
What the client gets. A written plan: the problems worth solving, the approach per problem, the sequence, and what it will take from your team. We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges.
Each of these is a full engagement in its own right. On a consulting engagement we tell you which ones you need and which you can skip — the links go to the detail.
Whether the standard Salesforce for Slack apps cover your requirement, what Salesforce channels are worth enabling per object, and where a connection becomes a build. See integration services and the architecture decisions behind it.
Salesforce-side automation with Flow, Apex and Platform Events is a different discipline from Slack-side automation with Workflow Builder. Most estates need both. See Salesforce Slack automation and Slack workflow automation.
Notification design decides adoption more than any other single choice, and approvals are the one workflow where moving it into Slack has an immediate, measurable effect on cycle time. See notifications and approval automation.
Where configuration runs out — custom surfaces, your own Slack app, bulk-safe event delivery. See customization and API and development work.
Slack is where the questions are already being asked, which makes it a strong surface for agents and an unforgiving one. Which jobs suit an agent, what it is grounded on and where a human stays in the loop. See Agentforce in Slack.
Reconciling two permission models, and deciding retention, audit and external-collaboration policy before an auditor asks. See security and governance.
Delivery and adoption, moving an estate onto Slack, improving one that already exists, and who owns it afterwards. See implementation, migration, optimization and managed services.
Consulting does not have to mean a long engagement. Most relationships here start with the first or second row and only move down the table if the work warrants it.
| Engagement | What you get | Best when | Typical shape | What it is not |
|---|---|---|---|---|
| Advisory call | A working session on a specific question, with a written answer afterwards. | You have one decision to make and need someone who has made it before. | Hours | Not a review of your org — we are answering from what you tell us. |
| Salesforce–Slack audit | An inventory of what connects the two systems today, what fires, what is unused, and what is at risk. | Something already exists and nobody can describe it end to end. | Days to weeks | Not a remediation. The fixes are scoped, not applied. |
| Architecture & roadmap | The approach per requirement, the event and permission model, and a sequenced plan. | You are about to build and want the design settled before anyone starts. | Weeks | Not a build. It is the document the build is run against. |
| Embedded advisory | A named consultant alongside your team through delivery, reviewing decisions as they are made. | Your team is building it and wants a second opinion continuously rather than once. | Ongoing | Not managed services — that is a run-state retainer, not a build-state one. |
Engagement shapes, not fixed packages — scope is set in discovery
We inventory the existing connection: installed apps, user mapping, permission sets, Flows that touch Slack, Workflow Builder workflows, and anything custom. You get the list, the risks, and what we would retire rather than migrate — whether or not you engage us further.
Findings become decisions: which approach carries each requirement, what fires and at what threshold, how the two permission models reconcile. Written down, so the build has something to be measured against and the next consultant can read it.
A roadmap ordered by dependency rather than by enthusiasm. Phase one is chosen because the rest needs it, and each phase names what it unlocks — so cutting the budget cuts scope from the end rather than breaking the foundation.
Every channel, alert and workflow gets a named owner inside your organization before we leave, and your admins are trained on what they now own. An integration only its consultancy understands is a liability we are not willing to leave behind.
Two delivered Salesforce and Slack engagements. The numbers are the ones published on each case study, with their original scope intact.
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.
SaaS technology company. Sales Cloud pipeline brought into Slack so sellers manage deals where the conversation already happens.
Commercial cleaning and janitorial provider in Ohio. A Slack workspace structured around sites, crews and client accounts, with automated case notifications and swarming.
Incorrect user mapping, missing permission sets and over-triggered workflows were all found during testing on a live engagement — not in design. Advice that has survived a rollout is worth more than advice that has not.
The useful thing about advice is that it can be negative. A consultancy that only ever recommends the thing it sells is not advising you.
The hard part of this work is almost always on the Salesforce side — the data model, the sharing rules, the automation already in place. We come at it as CRM architects who know Slack, not as a chat-tools vendor with a CRM connector.
A large share of what clients arrive asking us to build turns out to be configuration. We will say so before you pay for development, and show you the reasoning that got us there.
User mapping that sends alerts to nobody, permission sets that lock users out of Sales Home, and workflow conditions that trigger so often the team mutes the channel are all things we have found in testing on live engagements. They are now things we design out.
You get the reasoning, not just the conclusion — which means the plan survives a change of staff on either side, and you can challenge it.
Named owners per channel and trained admins are part of the deliverable. If the only route to changing your own integration runs through us, we have built you a dependency, not a system.
For a straightforward rollout, a capable Salesforce admin can connect the two platforms and enable Salesforce channels without help — and if that is your situation we will say so. Consulting earns its place when the requirement spans both platforms' permission models, when you are choosing between configuration and custom development, or when something already exists and nobody can describe it end to end. The audit is usually the cheapest way to find out which of those you are in.
Decisions with reasons attached. Depending on the engagement that is a written answer to a specific question, an inventory of what connects the two systems today with the risks flagged, or a full architecture and sequenced roadmap. It is not a configured org — building to the plan is separate work, and you are free to have your own team do it.
By requirement, not by preference. Configuration covers the standard apps, Salesforce channels, record notifications, Flow Core Actions for Slack and Slack Workflow Builder with its connector steps — a large surface that handles most needs. Development starts when you need a Slack interface of your own, a Workflow Builder step for an internal service, message delivery at a volume that must be queued rather than fired inline, or a sync no connector covers. We assess which side of that line each requirement falls on and tell you when configuration is enough.
Start with the audit, because the answer genuinely varies. Where the connection is sound and the problem is notification design or channel ownership, tuning is faster and cheaper than rebuilding. Where the estate is undocumented webhooks and Apex callouts that will not survive volume, replacing it is the honest recommendation. Either way you get the inventory and the reasoning before you get a quote.
Yes, and it is common. On an embedded advisory engagement we review decisions as your team or your existing partner makes them, which keeps delivery where it already sits and adds a second opinion at the points where a wrong turn is expensive to reverse.
An advisory call produces a written answer the same week. An audit runs days to weeks depending on how much already exists. An architecture and roadmap is a matter of weeks. The variable that moves all of these is not Slack — it is the state of the Salesforce org underneath, which is why we scope after discovery rather than quoting a duration before seeing it.
Access to look, and access to the people who do the work. Reading the org tells us what was built; half an hour each with a rep, a manager and an admin tells us what is actually used, which is the part that decides whether anything we recommend gets adopted.
A discovery call covers what your teams actually do in Slack today, what your Salesforce org can already support, and which two or three problems are worth solving first. You leave with a view on scope whether or not you engage us to build it.
Salesforce architects who will tell you when you do not need a build
