At TrailblazerDX last month, Salesforce officially announced Salesforce Flow for Slack as part of a larger announcement about Flow expansion and success.

Here’s more detail on what this announcement means and represents.

Four New Flow Capabilities

Flow for Slack encompasses four new Flow & Approval Processes capabilities:

1. A set of Flow Actions that enable flows to carry out common Slack activities like Create Channel and Post Message
2. Screen Flows in Slack, enabling entire screen flows to execute without modification in Slack channels.
3. Orchestrator in Slack, which adds task notification and enables Work Items from Orchestrator to be worked on without leaving Slack
4. Approval Processes send notifications to Slack

These are all part of the newly announced Salesforce Platform for Slack:

Flow Actions for Slack

Flow Actions for Slack are available automatically on every org, as of Summer ’22. Here are some use cases:

Screen Flows in Slack

The basic ideas behind Flow in Slack is that you can build a screen flow in Flow Builder….

….and that screen flow will run equally well in both Slack channels and traditional Salesforce containers like record pages:

Here’s a look at how it fits together:

Thin Work vs. Thick Work

Let’s first discuss why this is such a useful ability. One might argue that the kind of work that gets done in Slack is very different from the kind of work that gets done in Salesforce. This is sometimes referred to as ‘Thin Work’ vs. ‘Thick Work’. If you consider traditional Salesforce applications, there’s some validity to this concern. We don’t hear Slack users asking to carry out, in Slack channels, the substantial analytical work that you use Tableau analytics tools for, or try to use a Field Service Scheduling Console from a Slack channel.

What makes Flow such a good pairing for Slack is the fact that screen flows are already fundamentally Thin Work constructs. Each screen in a screen flow maps nicely to a single Slack message in a Slack channel. Flows are already used to carry out hundreds of millions of thin work transactions each month. And the new Flow Orchestration service extends that further, allowing work to be assigned to individuals and then worked on via these thin screen flows.

Notice the Salesforce Platform for Slack block in the diagram above. This is a new included service from Salesforce that makes it easy for Salesforce tools like Flow to work with Slack:

Looking at the Benefits

Let’s consider the big benefits of Screen Flows in Slack.

Benefit 1: Build Once, Deploy Everywhere

The development environments for ‘native’ Salesforce and Slack apps are very different, and a lot of duplication of effort is necessary to create coded solutions that work in both places. With Flow in Slack, it is now possible for the first time to build a single application that works across the entire Salesforce environment, from record pages to Slack channels, while delivering the exact user experience that each community expects and deserves.

To apply some traditional analogies: one of my first tech jobs was testing printers against some productivity software being created for hardware like the Apple II GS. I happily pulled down 6 of those sweet, sweet 1989 dollars hour after hour, working from a lab full of printers in Mountain View, California. The work was substantial however, because each printer maker provided their own printer driver, and our productivity software had to work with each driver’s nuances and variations. Today, application environments from Microsoft and Apple abstract that away. As a developer you can generally write without worrying about the specific printer support.

Flow provides a similar abstraction. The Flow development time has done the work to create two runtimes, the modern equivalent of those hair-metal-era printer drivers. These are the existing Lightning Runtime for Flow and the new Slack Runtime for Flow. Each of these runtimes talks to the Salesforce org and receives Flow metadata for each new screen. The runtime then translates the metadata into the appropriate presentation. As a Flow user, you probably aren’t even aware of all the work the Lightning Runtime carries out. Each time you load a record page with an embedded flow or pop up a flow modal from a button, this runtime loads as javascript into your browser, and start converting metadata into the web descriptions that Lightning uses to generate things like radio buttons and picklists. The new Slack Runtime actually operates on the backend, but carries out the same function. It converts that same screen metadata into a Salesforce platform construct called a View Definition, and the Salesforce Slack Platform then converts the View Definition into the Block Kit that Slack uses to render those same radio buttons.

But the good news is you need to understand anything from that last paragraph. Because Flow will handle it for you. If you can build a screen flow, you can run it in both places.

Benefit 2: Meet Your Users Wherever They Want To Work

Because flows will now run in both environments, you can look forward to greater compliance and happier users. Those users who want to work from the familiar Salesforce environment won’t have to change their behavior. And those users who never want to leave Slack will be able to get more of their Salesforce work done where they want to do it. Take as an example the perennial challenge of getting Salespeople to update their opportunities. If they can do from lightweight apps deployed as flows onto their mobile phone Slack apps, they’re going to be more compliant and you’re going to have happier managers.

Benefit 3: Stimulating Slack Adoption in the Salesforce Environment

If you’re in an organization that is not 100% on Slack, you can stimulate adoption by incorporating Flow in Slack into your strategy. Key applications that users are used to doing in Salesforce can be made available to them Day 1 in their new Slack environment. IT fears can be allayed by pointing to the ability to Build Once and Deploy in both environments. And to those concerned about a split organization running on two technologies, you can point out how screen flows become a unifying application tool that reduces the impact of the different lower layers.

Benefit 4: Bringing No-Code App Dev to Slack

Slack is a powerful application platform, but 100% of the applications written for it so far have been professional coding jobs. There isn’t a way to create No Code applications that use building blocks and point-and-click logic (The triggered workflows in Slack Workflow Builder are very useful, but because they don’t provide flow control, logical expressions, and enterprise access control, we don’t here consider them to be ‘applications’). Now Slack Applications can be quickly and easily crafted by non-developers, greatly extending the accessibility of the Slack Platform.

Beta Availability in Summer ’22

The Beta of Flow in Slack will be available for use in Summer ’22. It only supports a couple screen components and does not yet work inline, but we encourage the community to try it out.

Sending or Starting a Screen Flow in Slack

In the Summer ’22 release, here’s how you you send a flow to a Slack recipient:

1. Create the screen flow in Flow Builder.
2. Enable it for Slack (see ‘Enabling a Screen Flow to Run in Slack’, immediately below). Save and Activate.
3. You’ll find among your Flow Actions a newly generated Send Message to Launch Flow invocable action (only available on sandboxes in Summer ’22) corresponding to your screen flow.
4. What you do next depends on how you want to trigger the sending of the screen flow to a Slack Channel. An example: Create a Schedule-triggered flow and add your Send Message to Launch Flow action to it.
5. When the parent flow triggers, a message will be sent to the target Slack Channel, and recipients will be able to click to run your screen flow.

Note that the Connect Salesforce with Slack permission is required.

Enabling a Screen Flow to Run in Slack

In the Summer ’22 release, use this new checkbox to publish a flow for use in Slack:

Finding the Generated Action

A separate Flow Action is generated for each Screen Flow that gets ‘made available in Slack’ (see above). This is similar to how Quick Actions are each shown in the action picker in Flow Builder as distinct Flow Actions. Here’s an example of one of these generated actions:

Here’s what the Send Message to Launch Flow action looks like in a Schedule-triggered flow.

…and here’s how it gets configured:

Note that the technology behind this action will soon be available to notify users of Flow Orchestration Work Items. That’s targeted for Winter ’23.

Roadmap

Here’s the larger roadmap for Salesforce Platform integration with Slack