Slack integrations make it easy to hide complexity.
Complex systems are everywhere today. APIs and web applications hide complexity, but as this tweet mentions, if you have tools for different purposes, you end up context switching between a number of them. You can end up in a complicated thicket that wastes your time and prevents real work.
A Slack facade can layer a convenient interface over systems and can integrate them into once place. Less technical people can access systems from a familiar interface. All team members can benefit from less context switching. The Slack interface is primarily text and has the strengths of other text based interfaces:
These two attributes do lead to a discoverability issue for commands in Slack (just as exists for the command line). Luckily, smart help messages and good documentation can help. In addition, some kinds of integration can exist in the workspace independently; 'bots' prompt user exploration.
There are three broad categories of of Slack integration:
What kind of systems does it make sense to put behind a Slack integration?
You can browse our Slack example applications (and view their code) to see the wide variety of Slack integrations that we've found useful.
It's also worth noting that you can build more rich UIs in Slack using Block Kit. One of the benefits of a Slack integration is that everyone can create good looking and consistent interfaces.
Here are two example applications that have made the complex simple. Chatting up CloudWatch discusses how to layer on a conversational interface to the CloudWatch data. This allows looking up application events from within Slack. This is a great example of taking a complicated backend data source and making it easily accessible within the Slack application, as mentioned above.
This CloudTrail to Slack bot (
UmbrellaBot because it protects you from stuff coming from the Cloud, yuk, yuk) both pushes interesting external events to Slack and has a bot presence to allow a user to dig in deeper. Because it is creating chat messages about CloudTrail events regularly, there is an audit trail. The events are pulled from an S3 bucket, enriched by calling other APIs and applying business rules and then stored in a format accessible for querying.
If you are interested in hiding complexity using Slack, start small. Pick a task that you do regularly that meet the criteria above and write a Slack command to do it. This will get you familiar with the mechanics, but also give you immediate value. There are several toolkits to use to write this (Transposit is one!), but think about:
This Slack guide gives step by step instructions on how to create any of the various Slack integrations in Transposit.
After you've had a small success, think about a larger system that has a relatively simple output, perhaps with a bit of user flow. This could be as simple as a report you run regularly or a vacation request tracker. You'll need to make sure that you can access the data via an API, file in a publicly accessible location or other means. If you are running infrastrcture on AWS accessing a resource via an AWS Lambda function may be easier.
It's important to realize that while this is software, it is similar to a shell script. Therefore extensive testing isn't required, especially at first. However, if you do end up needing to test your Slack integration because it becomes crucial to running your systems, unit testing and integration testing are possible. Depending on the tools you choose, you can easily set up a test Slack workspace or use a tool like slack-mock.
These processes are not well suited to being put behind a Slack facade:
Chances are you already live in Slack for much of your day. You have complicated processes that may be amenable to automation. Having them at your beck and call from the Slack application "command line" can make your life easier and the processes be more consistent.