Requests that are just messages
“Can someone look at the Acme renewal?” is a request, but it has no owner, no due date and no record. It gets answered when someone happens to scroll past, and it is invisible the moment it drops off the screen.
Slack · Workflow Automation
The work starts in Slack. So should the workflow.
Requests, escalations and intake do not begin with someone opening Salesforce — they begin with someone typing in a channel. Slack Workflow Builder turns that into a structured process with no code: a form that asks the right questions, a connector step that creates the Salesforce record, and routing that reaches a person rather than a channel nobody watches. Built by ops, owned by ops, documented either way.
12+
500+
250+
15+
Trusted by 500+ organizations — including service, field and operations teams whose work arrives as a message before it ever reaches a record.
What We Automate With
- Salesforce Partner
- Slack Workflow Builder
- Salesforce Connector Step
- Workflow Forms
- Custom Steps
- Slack Connect
- Canvas
- Channel Governance
What happens when the process lives in a thread
Slack is where the request arrives. Without structure behind it, that is also where the request stays — and every one of these is the result.
The same five questions, every time
Whoever picks up the request has to ask for the account, the urgency, the contract number and the context, one message at a time. The requester answers three of them, disappears, and the thread stalls for a day over information a form would have collected in ten seconds.
Escalations routed to a channel
Posting to #support-escalations assumes somebody is watching. Routing to a named person with the context attached assumes nothing, and is the difference between a response time you can quote and one you cannot.
Ad-hoc channels with no lifecycle
An incident spawns a channel, the incident ends, the channel remains. Two years later the workspace has four thousand channels, half of them dead, and nobody can find the live one.
Nothing reaches the CRM
The conversation solves the problem and Salesforce never learns it happened. There is no case, no activity, no pattern to report on, and the next person to hit the same issue starts from nothing.
Workflows built once and abandoned
Someone builds a Workflow Builder workflow, leaves the company, and nobody else knows it exists until it breaks. Slack-side automation needs an owner and documentation exactly as much as Salesforce-side automation does.
What Slack-side workflow automation actually is
Slack workflow automation is process that begins in Slack — someone clicks a link, submits a form, reacts with an emoji or an event fires — and runs a sequence of steps that can collect information, take action in other tools, and create or update Salesforce records. It is built in Slack Workflow Builder, without code, by whoever owns the process rather than by a developer.
Where the boundary sits. Automation that originates in Salesforce — a record change, a scheduled job, a bulk load — is a different discipline with different tools, different owners and different limits. That is Salesforce Slack automation, built in Flow or Apex. Most estates need both, and the two meet at a documented handoff rather than overlapping.
What the platform does. Workflow Builder provides triggers, forms and steps, including connector steps that take action in other services — Salesforce among more than seventy apps — and the Salesforce connector can run a Salesforce Flow. Where a business process involves internal tools with no connector, developers can build custom steps and make them available to the same no-code builders. Slack documents the connector catalogue here.
What Twopir does. We design the forms so they ask once and ask correctly, wire the connector steps to the right Salesforce objects, route to people rather than channels, and leave the workflow documented with an owner. We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges.
Five triggers — and what each one suits
Choosing the trigger is most of the design. A process that should have been a form and became a scheduled reminder will be ignored, and the reverse floods people with prompts.
| Trigger | What starts it | Best for | Watch out for |
|---|---|---|---|
| Link trigger | A person clicks a workflow link, from a channel, a canvas or a bookmark. | Intake and requests — the most common starting point, and the easiest to publicise. | Discoverability. A link nobody can find is a workflow nobody uses; bookmark it in the channel. |
| Form submission | A person completes the workflow's own form. | Anything needing structured data before work can start: account, urgency, contract, context. | Form length. Every additional required field measurably reduces completion. |
| Emoji reaction | Someone reacts to an existing message with a chosen emoji. | Escalating something already said, without asking the person to retype it. | Accidental triggers, and the same emoji meaning different things in different channels. |
| Scheduled | A date and recurrence set on the workflow itself. | Recurring prompts, standups, and reminders that a queue needs working. | Becoming background noise. A scheduled post everyone ignores is worse than none. |
| Channel event | A person joins a channel, or a new channel is created. | Onboarding, and provisioning access or records when a deal or account channel opens. | Firing on every join, including bots and re-joins, unless conditions are set. |
Trigger types verified against current Slack documentation
Intake → Salesforce record
A form in Slack collects what the process needs, the Salesforce connector step creates the case, lead or task fully formed, and the requester gets the record link back in the thread. Nothing is retyped and nothing depends on someone scrolling past at the right moment.
Slack → run a Salesforce Flow
Where the logic already exists in Salesforce, the connector step runs the Flow rather than duplicating its rules in Slack. One place to change the business logic, two places to start it.
Escalation → a named person
Reactions or a form route the escalation to an individual with the record context attached, rather than broadcasting into a channel and hoping. The difference is a response time you can actually report on.
Custom steps for your own systems
Where a process involves an internal tool with no connector, a developer builds a custom step once and it becomes available to the no-code builders like any other. The specialist work happens once; the workflows on top stay owned by ops.
The workflow work inside an engagement
Six workstreams. Most engagements start with intake, because a structured request is the thing that makes everything downstream measurable.
Intake and request workflows
Forms that collect what the process actually needs, wired to create the Salesforce record directly, with the link returned to the requester. The end of 'can someone look at' as a request format.
Escalation and routing
Routing to named individuals with context attached rather than broadcasting to channels, including who is on call and what happens when they do not respond.
Incident and swarm workflows
Declaring an incident creates the channel, invites the right roles, posts the context and opens the record — as one action rather than six manual ones taken under pressure.
Salesforce Flow launched from Slack
Using the Salesforce connector step to run existing Flow logic, so the business rules stay in one place and Slack becomes another way to start them rather than a second copy of them.
Custom steps for internal tools
Where no connector exists for a system your process depends on, we build the step so your ops team can keep building workflows without us.
Governance and lifecycle
Channel naming and archival rules, a named owner per workflow, and documentation — so the workspace does not become four thousand channels with no map.
From a thread to a process
Four phases. The first is the one most often skipped and the one that decides whether anyone uses what gets built.
Watch the request actually happen
We read the channels where requests currently arrive and count what people actually ask for. The form you design from real messages is a different form from the one designed in a workshop.
Design the form and the routing
What must be collected before work can start, what can be optional, and who the output goes to by name. Every required field is justified, because each one costs completion rate.
Build and connect
The workflow built in Workflow Builder, connector steps wired to the right Salesforce objects, and Flow reused rather than reimplemented wherever the logic already exists in the CRM.
Publish, own and document
Bookmarked where the requests actually arrive, with a named owner, documentation, and a review after the first weeks of real use — because the first version of a form is always slightly wrong.
Workflows we have already built
Two delivered Slack engagements. The figures are the ones published on each case study, with their original scope intact.
Slack Workspace · 75+ Field Crews
A Slack workspace structured around sites, crews and client accounts for a mostly non-desk field workforce, with automated case notifications and swarming built in rather than bolted on.
75+ Field and office staff onboarded
5,000+ Businesses served by the client
Slack Sales Elevate · Salesforce Integration
Deal channels created automatically for active opportunities, bringing sales, pre-sales, finance and customer success into the same conversation on live deals.
5 User groups aligned on one system
5 Systems connected into one workflow
★★★★★
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.
Twopir Project Lead SaaS technology client · 2025 Slack Sales Elevate
Structure beats a generic org chart
The failure mode on a field-service workspace is always the same: a channel structure copied from the org chart rather than from how the team actually works. Channels were organised around sites, crews and client accounts instead.
4 Operational gaps closed
We design the form before we build the workflow
Workflow Builder is genuinely no-code, which means the constraint is never the tool. It is knowing what to ask, who to route to, and what happens in Salesforce afterwards.
We read your channels first
The form that works is designed from the requests people actually send, not from a workshop. Those two forms are rarely the same, and only one of them gets completed.
We route to people, not channels
Broadcasting assumes someone is watching. Routing to a named individual with context attached assumes nothing, and turns response time into something you can report on.
We reuse Salesforce logic rather than copying it
Where rules already exist in Flow, the connector step runs them. Reimplementing business logic in a second place is how two systems start disagreeing about the same process.
We are Salesforce architects
The Slack half of this is the easy half. Knowing which object the record should land on, what the sharing rules will do to it, and how it reports afterwards is the part that needs CRM depth.
We leave an owner and a document
Slack-side automation decays exactly like Salesforce-side automation when nobody owns it. Every workflow we build has a name attached and a note explaining what it does.
Answers before the first call
Direction and ownership. This page covers processes that start in Slack — a form, a link, a reaction, a channel event — built in Slack Workflow Builder by whoever owns the process, with no code. Salesforce Slack automation covers automation that originates in Salesforce from a record change or a scheduled job, built in Flow or Apex and living under Salesforce governor limits. Most estates need both, and they meet at a documented handoff.
Not for most of it. Workflow Builder is designed for the person who owns the process, and the connector steps — Salesforce among more than seventy apps — cover a wide range of actions without code. A developer is needed in one case: when your process depends on an internal tool with no connector, someone builds a custom step once, after which your ops team can use it in workflows like any other step.
Yes. The Salesforce connector step takes action in Salesforce as part of the workflow, and it can also run a Salesforce Flow — which is usually the better choice where the logic already exists, because it keeps the business rules in one place rather than duplicating them in Slack.
The team whose process it is, which is the main advantage of building them in Slack rather than in Salesforce. We assign a named owner per workflow and document what it does, because a workflow whose author has left and whose purpose nobody remembers is a liability whichever platform it runs on.
It will if nobody sets the rules, which is why channel naming, creation and archival policy is part of the engagement rather than an afterthought. Workflows that create channels — for incidents, deals or accounts — need a lifecycle defined at the same time, otherwise they are a channel-sprawl engine with good intentions.
Usually by not using one. A scheduled prompt that arrives whether or not there is anything to do becomes background noise within weeks. Where the requirement is really 'act when something is true', the right answer is an event-driven alert from Salesforce rather than a recurring post — which is why we look at both sides of the boundary before choosing.
In a Slack Connect channel, yes, with the usual governance caveats about what external members can see. One constraint worth planning for early: external people cannot be invited into Salesforce channels specifically, so customer-facing collaboration belongs in a Slack Connect channel alongside the internal record channel rather than inside it.
Next Step
Show us where the requests arrive, we will give them a shape
A discovery call covers how work currently reaches your team in Slack, what gets lost between the message and the record, and which two or three processes are worth structuring first.
Salesforce architects who know which half of the boundary you are on
