Salesforce for Slack handles accounts, opportunities and cases well. It handles your custom objects, your renamed fields and your particular approval shape less well, because it was never told about them. Customization is the work of extending what the standard apps surface, shaping the message around the decision being made, and stopping before it becomes a development project. Tailored where it pays, standard everywhere else.
Trusted by 500+ organizations — including teams whose real work lives on objects Salesforce never shipped.
What We Tailor
None of these mean the standard apps are wrong. They mean your business does something the default configuration was not designed to describe.
The team manages projects, matters, shipments or subscriptions on an object Salesforce did not ship. The standard channel experience covers accounts and opportunities beautifully and knows nothing about the thing your business actually runs on.
A default notification carries whatever the layout offers rather than the four fields required to make the decision. The reader skims, misses the one that mattered, and gradually stops reading.
The record is an Opportunity in Salesforce and a deal, a matter, a job or a booking to everyone who works on it. A surface that uses the platform's nouns instead of the team's adds a translation step to every single message.
Updating the record requires a field from a second system, so the user leaves Slack, opens Salesforce, opens the other tool, and returns. The integration removed the first hop and left the other two.
Finance, sales and support need different things from the same record. A single shared message shape means it is slightly wrong for everyone, and each group quietly builds a workaround.
Someone tailored it heavily, left, and documented nothing. Now the team is afraid to touch it, which is a worse position than having never customised it at all.
Salesforce Slack customization is the work of extending what the standard Salesforce for Slack experience surfaces — which objects appear in channels, which fields travel with a message, what actions a user can take in place, and what the whole thing is called — so it describes your business rather than a generic one. Most of it is configuration and declarative design. Some of it is not, and knowing which is which is the point.
What the platform does. Salesforce lets an admin choose which objects are available for Salesforce channels, including custom objects, and controls how much record detail is exposed; Flow shapes what a message contains and what actions it offers. Slack provides the surfaces those actions appear on. Salesforce documents the object setup here.
Where it becomes development. Tailoring what standard surfaces show is configuration. Building a surface of your own — a modal, a slash command, an app with its own logic — is development, done with the Apex SDK for Slack or a Bolt app, and it belongs on our Slack API and development page. We name that line explicitly on every engagement rather than letting a project drift across it.
What Twopir does. We extend the object coverage, design the message around the decision rather than the layout, put the team's own vocabulary on it, and say plainly when a requirement has stopped being configuration. We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges.
Almost every customization request we receive can be answered at one of the first three levels. Establishing which level a requirement sits at, before anyone starts, is the single most useful thing this page can give you.
| Level | What it covers | Who owns it | What it cannot do | Maintenance cost |
|---|---|---|---|---|
| Object and field coverage | Choosing which objects — including custom ones — are available for Salesforce channels, and how much record detail is exposed. | Salesforce admin | Change the shape of the standard experience, only what it is pointed at. | Low. A setup change. |
| Message design in Flow | What a notification contains, which fields travel with it, and which actions it offers. | Salesforce admin | Create an interactive surface of its own, such as a multi-step form. | Low to moderate. Versioned with your Flows. |
| Workflow Builder surfaces | Forms, intake and multi-step processes that start in Slack, using connector steps. | Ops lead in Slack | Reach systems with no connector step available. | Low. Owned by the process owner, not IT. |
| Custom steps and apps | Your own modal, slash command, or an app with its own logic, built with the Apex SDK for Slack or Bolt. | Salesforce or Slack developer | Nothing much — which is exactly why it is the last option, not the first. | High. Tests, a release process and a named owner. |
Levels applied per requirement — most estates need the first three and not the fourth
Your projects, matters, shipments or subscriptions get the same channel treatment as a standard opportunity: a channel tied to the record, the fields that matter, and the people who work on it. Configuration, not code, for the great majority of cases.
Four fields that answer the question, not fourteen that describe the record. Designed by asking what the reader has to do next, which is a different question from what the layout happens to contain.
Finance, sales and support get what each needs from the same record rather than one shared compromise. Usually achieved with routing and separate message designs rather than by building anything.
A modal that collects structured input, a slash command your team will actually remember, or a step for an internal system with no connector. We build these — and we tell you first that they carry tests, a release process and an owner, forever.
Six workstreams. The last one is the one clients least expect and most often thank us for.
Extending Salesforce channels to the objects your business actually runs on, with the record detail setting chosen deliberately rather than left at its default.
Designing what travels with each notification around the decision the reader has to make, per audience rather than one shape for everyone.
Your team's nouns on the surface they use, so nobody has to translate Salesforce's object names into the words the business actually says.
The two or three actions a user genuinely needs on a record, available in the message, running under their own Salesforce permissions rather than a shared integration user.
Modals, slash commands and custom Workflow Builder steps, built with the Apex SDK for Slack or Bolt when configuration genuinely cannot reach the requirement.
Removing customization that no longer earns its keep. A meaningful part of most engagements is taking things away, which lowers maintenance cost and makes the rest comprehensible.
Four phases. Phase one frequently ends the project early, in the client's favour.
Every requirement placed against the four levels above. A surprising share of what arrives as 'we need this built' turns out to be an object setup change and a Flow edit, and we say so before anyone budgets for development.
What appears, for whom, in what words, with which actions. Designed against the decision the user has to make, not against the fields the record happens to have.
Everything achievable declaratively is done declaratively. What is left — and it is usually a short list — is built with tests and documentation, and identified plainly as code you will own.
What was customised, why, and who owns it, plus a pass to remove anything that has stopped earning its place. Undocumented customization is the reason teams end up afraid of their own configuration.
Two delivered Slack engagements on Salesforce. The figures 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.
Sales Home, deal channels and opportunity notifications configured per role, so sales, pre-sales, managers, finance and customer success each saw what their role required.
A workspace structured around sites, crews and client accounts rather than a generic department layout — the customization that decided whether a non-desk workforce used it at all.
The failure mode on these builds is always the same: a channel and surface structure copied from the organisation chart rather than from how the work is actually done. Customization exists to close that gap, not to add features.
Every piece of customization is a maintenance obligation you take on permanently. The useful consultant is the one who tells you which ones are worth it.
Against four levels, with the maintenance cost of each stated. A requirement that turns out to be a setup change should not be priced as development, and we will say so.
What does the reader have to do next? That question produces a four-field message. Asking what the record contains produces a fourteen-field one that nobody finishes reading.
Surfaces labelled in the words your team already uses. It sounds cosmetic and it removes a translation step from every interaction, which is not cosmetic at all.
Most engagements on an existing estate include taking customization away. Lower maintenance cost, and a configuration people are no longer afraid to touch.
What was changed, why, and who owns it. Undocumented customization is how a team ends up unable to modify its own system without calling somebody.
Yes. An admin chooses which objects are available for Salesforce channels in Salesforce Setup, and that includes custom objects — so the thing your business actually runs on can get the same channel treatment as a standard opportunity. It is a setup change rather than a development project, which is often the single most useful thing a team learns on a first call.
Configuration covers which objects and fields are surfaced, what a message contains and which actions it offers, and multi-step processes built in Workflow Builder. Development starts when you need an interactive surface of your own — a modal that collects structured input, a slash command, or a step for an internal system with no connector — which is built with the Apex SDK for Slack or a Bolt app. We place every requirement against that line before quoting it.
Declarative customization generally travels well, because it is configuration the platforms expect you to change. Code is different: it carries tests, a release process and an owner indefinitely, and it is the part most likely to need attention when a platform changes. That asymmetry is exactly why we exhaust the configuration options before writing anything.
Yes, and they usually should. Finance, sales and support need different fields from the same opportunity, and a single shared message shape is slightly wrong for all three. This is normally achieved through routing and separate message designs rather than by building anything — and the underlying record access is still governed by Salesforce, because actions run in the acting user's own context.
With an inventory, and an expectation that some of it will be removed. We document what was customised and why, identify what no longer earns its maintenance cost, and simplify before extending. A team that is afraid to touch its own configuration is in a worse position than one that never customised it, and the fix is subtraction before addition.
On the Slack surfaces, largely yes — what a message says and how it is labelled is under your control. Inside Salesforce, object and field labels can also be renamed, though that has wider consequences we would want to scope properly. Using the team's own nouns removes a translation step from every message, which matters more than it sounds.
Someone has to own the code, yes. That is the trade we make explicit before building one: a slash command is genuinely useful and it is a permanent maintenance obligation with tests and a release process. Where the same outcome can be reached with a Workflow Builder link trigger owned by your ops team, we recommend that instead, and it is a closer substitute than most people expect.
A discovery call covers what the standard apps are not covering, what your teams are working around, and which of it is a setup change rather than a build. You leave knowing what this should cost.
Tailored where it pays, standard everywhere else
