Will Slack's new workflow automation tools spawn a new generation of Slack-native ISVs?

One of the most intriguing aspects of last week's Slack Frontiers event is that it's as though Salesforce had never bought Slack. While the two companies are fully enmeshed behind the scenes, what was presented at the event had already been in Slack's roadmap well before last year's acquisition, while most of the real impact of the two companies coming together still lies in the future. Slack was always going to add more workflow automation capabilities, and last week's additions are significant. But for the moment the two companies are keeping their developer ecosystems separate — it'll be when they bring them together that things really get exciting.

For now, though, it's a case of introducing these new capabilities at a time when businesses are still adapting to unfamiliar ways of working as we all become more digitally connected. These are new habits, even for early adopters like Slack itself. One welcome change has reduced the amount of time people have to spend in web meetings. Tamar Yehoshua, Chief Product Officer at Slack, told me how her team has been able to replace a weekly meeting where product managers used to give updates on their projects. They now pre-record those presentations as a 10-minute video clip and post them to a Slack channel. Participants can view the clips — with the option to skim through them at speed — and post questions to the channel. What used to take everybody 30 minutes can now be done in much less time, but with more focus.

Another recent innovation is the ability to quickly open up an audio chat for everyone in a channel. Yehoshua says this has been invaluable for a quick check-in, for example after finishing a call with a customer, instead of having to formally schedule a debrief meeting. It's much more efficient to quickly have a two-minute 'huddle' there and then.

Both these features are recent additions to Slack, and both require an adjustment to people's habits. Before my call with Yehoshua, Slack had sent a pre-recorded executive video briefing on the upcoming announcements. Given that so many briefing calls consist of 15-20 minutes sitting through a canned presentation, I welcome how this frees up time on the call to drill into strategy and other issues. But it does require me to allow extra prep time beforehand, which on this occasion, I failed to do. Not to worry, I still plowed in with my questions having skimmed the press release in advance, but the anecdote underlines that these new more efficient ways of working won't deliver their full impact until people adjust their behavior to match. The old habit of looking at the briefing materials for the first time when you sit down to start the meeting won't cut it any more.

New workflow automation capabilities

Similarly, the new workflow automation capabilities unveiled by Slack last week will take a while to filter through. I've long argued that the big value of Slack isn't the conversations themselves, but the ability to embed functionality into this conversational layer. The messaging app then becomes the medium through which people access a whole gamut of enterprise applications, without ever having to visit those individual applications. This will save all the time and effort people currently spend switching between applications and manually transferring snippets of data. But it will take time to create the integrations and then adapt to the new, speedier workflows. Much of that work can now start in private beta following last week's announcements.

These updates to the Slack workflow builder aren't due for full release until next summer, but they significantly expand its scope, particularly in integrating to third-party applications, while making these automations much easier to plug into apps and workflows, even for non-coders. In the past, the workflow builder was more about building processes within the Slack front-end. The new capabilities focus on back-end building blocks, along with new functions that make it much easier to pull in data and workflow from external applications. Along with a new developer toolkit, this has made it a whole lot easier to build and deploy apps and functions to Slack. Yehoshua told me:

It goes from weeks to minutes that you can actually deploy your apps in Slack and take advantage of all of the security and compliance of Slack. You can even store your data in Slack.

Slack has significantly upgraded its underlying infrastructure so that people can use their Slack credentials to sign into external applications, while developers can store data and processes in Slack as well as sending metadata from external applications. The new features include the ability to sign into an external app simply by clicking on a link in Slack, and to subscribe within Slack to notifications from the app. Any of these capabilities can be embedded into reusable components that a user can simply drag-and-drop into a new workflow in a Slack channel.

Finding new 'killer apps'

It'll be a while before it becomes obvious what this all means in terms of practical outcomes, but Slack has been testing out the new capabilities with some early adopters. There are already examples of how message metadata can be used to automatically set up cases from PagerDuty or Jira, or how subscribing to notifications from Smartsheet or Mural can keep project collaborators on the ball. The ability to sign in to an app from a link has already produced some particularly appealing metrics for ISVs, with one partner reporting a 54k surge in new user accounts within a month of introducing the feature — more than a 40% boost on top of the existing users that connected from Slack.

There's a multi-stage process that has to be followed here. First of all the integrations have to be built, then people have to become aware of them, and finally they start to be adopted as organizations adjust to new ways of working. Partner ISVs will play a huge role in fostering adoption, particularly in those cases where they can benefit from increased user sign-ups. But most important of all are the 'killer apps' that spread virally simply because they're so much more effective than the old patterns they replace.

All of the above becomes even more interesting in the context of Slack Connect, which allows sharing of apps and workflow between organizations. Currently the number of organizations in a Slack Connect channel is limited to 20, but early next year that will rise to 250, and later on it will rise to unspecified "thousands". The ability to have automated workflow and information sharing that runs across huge communities of organizations opens up entirely new avenues of collaboration. It's going to be fascinating to see what transpires then.

My take

I had my briefing with Yehoshua in advance of last week's event. Then a bout of COVID struck and I had to take some time out, although fortunately I'm double vaxxed so it was relatively mild. Now that the brain fog is gradually lifting, I've been trying to figure out the bigger picture here. What I'm grappling with is the intersection of these two developer communities.

Salesforce has its longstanding AppExchange ecosystem, which includes some very powerful applications that either connect to or directly run on the Salesforce platform. Some of these have grown to become massive businesses in their own right, from Xactly and Conga to Veeva and nCino. Slack has been growing its own ecosystem, including some ISVs that have built their apps natively with Slack's developer tools. The latest announcements massively expand the scope of such applications and the ease with which they can be built. Coupled with Slack Connect, it opens up the potential for a new generation of Slack-native apps that connect business processes across enterprise boundaries, automating the handling of transactions such as purchase orders, service tickets or sourcing contracts.

So why not bring these new Slack-native apps into the AppExchange? I pressed Yehoshua on this point when we spoke, but it was clear that there's currently no intention to merge the two ecosystems, beyond encouraging AppExchange partners to connect their apps into Slack. Maybe the decision to keep the two separate is down to pragmatic realities around licensing and other terms of trade. It's also worth recognizing that these are two very different types of application. The classic AppExchange app is essentially based on a traditional forms-and-database architecture, with the common data model of the Salesforce platform providing much of the platform value. A Slack app is event-driven, with much of its value coming from the ability to connect processes and data across integrations between multiple apps. Therefore there's an argument for letting this newer ecosystem gain more substance and maturity to give a chance for its unique needs and characteristics to become clearer.

Bearing in mind how long it took for Salesforce-native ISVs to find their feet, it probably makes sense not to rush this process in the case of Slack-native ISVs. The next couple of years are going to be fascinating as we start to see what developers are able to do with the new tools Slack has just made available to them. Chances are, they'll be creating even more new habits for organizations and people to adopt, and that takes time.