In the Beginning
I first started using Slack in 2014 when some team members recommended it. I was pretty ho-hum about messaging apps at the time. They seemed like extra noise in an already-busy world. People would exchange messages, but it rarely felt like action was taken. At least with email, you could look at the to and cc fields to see if you needed to read and respond.
To my surprise, Slack was “pleasant” to use. I think it was the generous whitespace and use of channels to control chatter. It included integrations with outside services that alerted you to important events. And it was easy to share documents with the team. But mostly I used it for messaging like everyone else.
Fast forward to the present and not much has changed from a UI perspective. Like Google’s search page, there’s a lot of attention paid to keeping the white space high and the feature-overload low. But this obscures a range of new capabilities hidden behind slash commands, menus, and expanded APIs.
In fact, the scale of change in Slack over time is large enough that it’s possible to now use Slack as the centerpiece of an enterprise workflow strategy. It now exposes a range of event hooks, extensions and input fields, allowing for a fully orchestrated experience. It’s reminiscent of HTML where early versions only described how to render a static Web page while HTML5 now describes a complex system for creating apps.
These are just a few of the user interface controls available. Couple these with event triggers, baked-in user identity, and multiple extension points and it’s easy to see that the building blocks necessary are all in place to deliver enterprise workflows in Slack.
The Conversational Challenge
Slack has a well-documented API that’s easy to use. It only takes an hour to work through the introductory tutorials and get a slash command working. You receive the slash event and respond with a message. As a developer you quickly learn that simple, one-step message exchanges form the backbone of most Slack integrations.
But this is where it gets tricky. While it’s easy to send a single message by calling a single API, the challenge lies in engaging users in multi-step workflows. To efficiently model the user interactions in Slack, the core Slack API must first be augmented to make it conversational. It’s a nuanced point that is often overlooked by integration vendors, because at first blush an API seems like an API.
The challenge is that engagement APIs are complicated to use when it comes to getting the actual “answer” you need. With traditional APIs that connect to systems, the API and the backend system are one-and-the-same. Calling the API provides an immediate answer.
Integration vendors from IFTTT to MuleSoft all handle system API calls like this quite well. But with systems of engagement like Slack, the system isn’t the intended target . Slack doesn’t have the answer you need. People do.
From a modeling perspective, this means that engagement APIs like Slack that serve as a conduit to people must be extended before being incorporated into a modeling tool. The vendor must hide the complexity of this three-party interaction, so that the interaction pivots around the interaction with the person, and not with Slack.
Ultimately, a proper conversation modeling system should provide a unified toolset for asking questions and getting answers. It should be possible, for example, to conduct a survey over slack and model it at the level of human conversation. It should be no more complex to model a database interaction than it is to model a human one.
Conversational Slack in Action
Most Slack users are familiar with slash commands. Even if you skip their tutorials, you’ll eventually type a forward slash on accident and expose a menu of commands and extensions. Slash commands are one of the earliest event types exposed for programmatic interaction on Slack, and several more have been added including button clicks, menu selections, and dialog form submissions. You can even design solutions that process every message in a channel using Natural Language Processing (NLP).
To illustrate conversational workflow principles, the example shown here will conduct a survey in Slack. It begins when a user enters the /survey slash command.
In response to the user’s action, the system asks them if they want to start immediately or delay the survey. This is the first conversational moment in the interaction. It’s more than a one-way message. It’s a question.
From a conversation modeling standpoint the above message is treated as a single unit in the modeling environment even though it combines multiple Slack APIs behind the scenes. When the activity is run, it sends a message to Slack and then pauses the flow. It only continues when the question has been answered by the person at which point it takes one of two paths.
If the user chooses to be reminded tomorrow, the system will follow up with a reminder message the next day.
This reminder exchange is managed by a second flow that loops each time the user delays the survey. The loop only ends when the user clicks the Start survey button.
When the user chooses to start the survey, they are presented a dialog with multiple fields for collecting their feedback. Here they are prompted to provide their ratings and comments.
Once again, the interaction is conversational. A single activity is used to prompt the user for their input and await their response. To model this interaction a third flow is used that includes activities for collecting, reviewing, and submitting the survey responses. It begins by launching the dialog to collect the answers and concludes by writing the answer to the database and sending a thank you message.
Modeling Slack at the level of human conversation is what keeps workflows readable, intuitive, and maintainable. Instead of breaking up processes into multiple files to adhere to Slack’s base API, conversational systems model the business case using higher-level activities that reflect how people converse.
It’s both easier to develop and easier to maintain when the workflow is modeled conversationally. The differences between engagement- and system-APIs fades away as all interactions are modeled the same. It’s no more difficult to model human conversation, than it is to model writing to a data store.
In addition to being more readable and easier to maintain, conversational APIs make it easier to monitor the flow of information when activities are run, providing insight at the level of the business process.
Here is a log of the running process as provided by the engine. Because all activities are tracked as a unit, it’s possible to provide insight spanning users and flows. Here we can see that the user delayed taking the survey at first and then filled it out quickly in under a minute.
It’s even possible to traverse the process in any direction from a single starting activity and see the JSON message exchange as well. The unified process view is what makes this possible.
Engagement APIs Done Right
The official Open API Specification for Slack’s REST API is robust, but it mainly describes low-level activities like posting and updating messages.
To be efficiently used within a workflow modeling environment, the API needs to be extended to include activities that reflect human interactions. It’s not about sending messages to Slack. It’s about using Slack to send messages to people.
For example, consider this curated version of the Slack API with several extensions. Many of the activities listed represent multiple Slack API calls (which are managed by the orchestration layer). By hiding the mechanics of the conversation in this manner, the modeling system allows developers to storyboard at the level of the business process.
Integration platforms are focused on fast, efficient processing of API calls (and they should be). This is the right approach for integrating most APIs. But engagement APIs are different. Unless the integration vendor accounts for their unique conversational quality, the modeling environment soon becomes cluttered with conversational anti-patterns. You find logic spread across multiple files. You keep the logic for sending a message in a different file than the one that receives it.
If you’re interested in learning more about our approach to conversation modeling, please drop us a line at email@example.com. There’s a new approach to workflow with Slack at the center. And it begins with conversational APIs.