Most Salesforce–Slack estates we are called into work, in the sense that messages arrive somewhere. What nobody can produce is a list of what fires, what has silently stopped, who owns which channel, and which half of it anybody reads. An optimization engagement produces that list first and fixes against it second. Findings with severity attached, then the work — in that order.
Trusted by 500+ organizations — including teams who inherited a Salesforce and Slack estate nobody could describe.
What We Audit
We would like this list to be more varied. It is not — estates decay in remarkably consistent ways, which at least makes them quick to diagnose.
Flows, workflow rules and Apex that touch Slack, built by people who have moved on, some of them duplicating each other and some erroring on every run. The inventory is usually longer than anyone on the client side expects.
The volume made it unreadable, everyone muted it, and nobody escalated that because muting solved their individual problem. The integration looks live and is functionally switched off.
One path fails silently — a mapping broke, a token expired, a condition stopped matching. Nothing errored visibly, so the discovery date is whenever someone happens to ask about a deal that never triggered an alert.
Hundreds of them, many dead, several near-duplicates, and no naming convention. Finding the live one for an account is guesswork, which quietly pushes people back to email.
Permission sets from a rollout two years ago, apps with scopes nobody would approve today, and guests whose projects ended. Nothing revokes itself.
An Apex class or a middleware recipe built before someone knew a Flow action existed. It works, it carries a maintenance cost forever, and retiring it is usually cheaper than continuing to own it.
A Salesforce Slack optimization is a scoped engagement that inventories a live estate, measures what it actually does against what people actually do with it, ranks the gap by severity, and fixes it. The first deliverable is the findings list. The fixes follow from it, and some of them are deletions.
How it differs from a support arrangement. This has an end date and a defined outcome. Managed services is ongoing availability. Buying the retainer without doing this first means paying to maintain the problems, which is why we will usually recommend the audit before a support agreement rather than alongside it.
Evidence, not opinion. Alert volumes, response behaviour, error and retry counts, channel activity and mapping integrity. “The channel is too noisy” is a complaint; a count of what fired against what was acted on is a finding, and only one of them can be prioritised against your other work.
What Twopir does. We produce the inventory, gather the evidence, rank the findings, separate the quick wins from the structural work, and fix what you choose to fix — including recommending retirement where something is not worth carrying forward. We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges.
The fourth column is the one clients care about. Three of these six routinely produce quick wins that cost nothing to act on, which is usually enough to pay for the audit before the structural work starts.
| Area | Evidence gathered | Typical finding | Time to fix |
|---|---|---|---|
| Automation inventory | Every Flow, workflow rule, trigger, Apex class and connector touching Slack, with run counts and error rates. | Duplicates, orphans, and at least one thing erroring on every run. | Quick win — retire and consolidate. |
| Alert volume and response | Messages per channel per week, against opens and replies where the data exists, plus which channels are muted. | A large share of volume nobody has ever acted on. | Quick win — switching it off is free. |
| Silent failure check | Error queues, retry backlogs, rate-limit headroom, and mapping integrity per user. | At least one delivery path that stopped working months ago. | Quick win to fix, structural to prevent recurrence. |
| Channel structure and ownership | Channel count, naming consistency, activity, duplicates and whether any owner is recorded. | Sprawl, no convention, and no owner on the channels that matter. | Structural — needs a policy, not just a cleanup. |
| Access and drift | User mapping, permission sets, app scopes, guests and live Slack Connect channels. | Access wider than intended, from roles that changed and apps nobody reviewed. | Mixed — revocation is quick, the model is structural. |
| Build-versus-configure review | Custom code and middleware paths, checked against what the platforms now do natively. | Something custom doing a job a Flow action would now do. | Structural — but retirement lowers cost permanently. |
Areas covered in every audit; depth varies with the size of the estate
Everything that connects the two platforms, including the parts nobody remembers commissioning. Most clients have never seen this list, and producing it frequently changes what they thought the problem was.
Volumes, error counts and response behaviour rather than impressions. It converts 'the channel is too noisy' into a number that can be prioritised against everything else competing for the same quarter.
A meaningful share of what we find should be switched off rather than carried forward. Deleting is the cheapest fix available and the one least often on anybody's list.
Severity attached to each item and quick wins separated from structural work, so the fix programme is yours to scope. We are equally happy handing the list to your own team.
Six workstreams. The first three are the audit and produce the findings; the last three are the fix programme, which you can scope down or take in-house.
Every integration point, automation, channel class, app and custom component, documented — generally the first complete picture the organisation has had.
What fires, how often, into which channels, and what people do about it, including which channels have been muted and by how many people.
Severity per finding, quick wins separated from structural work, each with a recommendation and an estimate. This is the deliverable even if you stop here.
Switching off what nobody acts on, tightening entry criteria, and converting instant pushes to digests. Usually the largest single improvement and frequently the cheapest.
Merging duplicate automation, replacing custom code where the platforms now do it natively, and deleting what is dead. Lowers the permanent maintenance cost.
Named owners per channel and alert, a naming convention, and a runbook — so the estate does not decay back into the state we found it in.
Four phases. The first two are read-only, so you can stop after them with something useful in hand.
We look, we do not change anything. Every automation, channel, app and integration point catalogued with run counts and error rates where the platform records them.
Volumes against response, mute rates, channel activity and mapping integrity. This is what turns impressions into findings that can be ranked.
Severity per finding, quick wins separated from structural work, each with a recommendation. You can hand this to your own team — it is written to be actionable without us.
Noise reduction first because it is cheapest and most visible, then consolidation and retirement, then the structural items. Scoped to whatever you decide is worth doing.
A delivered Slack Sales Elevate engagement where six rollout problems were found and fixed during testing. 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.
Six problems surfaced by deliberate testing rather than by users complaining: user mapping, permission sets, over-triggered conditions, manual update habits, thin visibility and ownership.
An engagement that built 30, 60 and 90-day optimization into the plan rather than treating go-live as the end of the work.
Over-triggered workflow conditions do not arrive as a support ticket. People mute the channel, which solves it individually and hides it organisationally — so it only surfaces when someone counts what fires against what anyone acted on.
The fastest improvement available to most estates costs nothing and involves switching things off. It is also the recommendation a vendor selling a rebuild is least likely to make.
Ranked, evidenced and written to be actionable by your own team. If you take it and do the work in-house, the engagement still did its job.
Volumes, error counts, mute rates and response behaviour. A number can be prioritised against the rest of your quarter; an impression cannot.
A meaningful share of what we find should be switched off rather than migrated. Deletion is the cheapest fix and it permanently lowers what you maintain.
Three of the six audit areas routinely produce free fixes. Doing those first usually pays for the audit before the structural programme begins.
Named owners, a naming convention and a review cadence — otherwise the estate returns to the state we found it in, and you buy this engagement again in two years.
A ranked findings list: every automation, channel and integration point that touches Slack, what it does, what it costs, what has silently stopped, and what nobody acts on — each with a severity and a recommendation. It is written to be actionable by your own team, so taking it and doing the work in-house is a legitimate outcome we are happy with.
This is a project with an end date that makes the estate better. A support retainer is an ongoing arrangement that keeps it working. Buying support without doing this first means paying monthly to maintain the problems, which is why we usually recommend the audit first and the retainer afterwards if you want one.
Not for the audit. The first two phases are read-only — we inventory and gather evidence without changing anything, which also means you can stop after them. Write access is only needed for the fix phase, and only for the fixes you choose to have us make.
Almost always switching off what nobody acts on. In most estates a large share of the alert volume has never produced a response from anyone, and removing it costs nothing, takes effect immediately and makes the remaining alerts credible again. That is usually the first thing we recommend and it frequently pays for the audit on its own.
Usually, yes. Silent failures are one of the six things we look for specifically — error queues, retry backlogs, rate-limit headroom and user mapping integrity. A mapping that broke or a condition that stopped matching produces no visible error, so the only way to find it is to go looking, which is what the audit does.
It varies and we will tell you which after looking, not before. 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 — and sometimes the answer is to retire a component entirely rather than to do either.
By fixing the mechanism, not just the symptoms. Named owners per channel and alert, a naming convention, and a scheduled review of thresholds against response behaviour. Without those the estate drifts back as volumes grow and people change roles, and you end up buying this engagement again in two years.
The audit is read-only and produces a ranked findings list you can act on with or without us. Most clients find the quick wins alone justify it before the structural work is even scoped.
Findings first, fixes second, deletions encouraged
