Looking to the future of apps in Slack
Improving the way Slack apps are built, installed and distributed
Update — August 1, 2017: Help shape the future of these features by joining our API Preview period. You can try out in-preview features as we release them, give us feedback on our documentation, and install Lunchtrain — our open-source example app — which has been updated with new functionality. Learn more.
When it comes to the future of our APIs, we want to share with you early and often. That’s why today, we’re introducing you to some upcoming features that will help you distribute your app to more people, simplify app development and maintenance, and extend your app’s user experiences.
Two main components will make this possible: a new access token tied to a whole team rather than individual users, and a new Permissions API that will allow you to ask for permissions progressively.
On August 1, we’ll invite you to join our API Preview period, where you’ll be able to try out these new features and give us feedback. In the meantime, let’s take a deeper look at what’s coming.
TL;DR — We’ve got a lot to share, so here’s a quick summary.
- We’re working on improvements to the way apps connect with teams in Slack. Two key components will make this possible: a workspace-based app token and a Permissions API.
- On August 1, we will launch the API Preview period. At that time, you’ll be able to read our documentation, try out the features, and help shape the future of these APIs.
- The new app token ties your app to whole teams rather than individuals, and it encompasses bot user and app functionality. The Permissions API allows you to ask for fewer permissions up front, and opens up new use cases for you to interact with customers — like gating features behind a paywall or guiding users down an onboarding flow.
- Prior to our general availability date, roughly targeted for Q1 of 2018, we will give you tools and a migration guide for your app to take advantage of these features.
Apps connected to teams, not individuals
We are building a new type of access token which connects apps to whole teams, or workspaces, rather than individual installers. Apps will be granted just one access token per workspace, making them usable and discoverable by anyone in a company with only one installation.
The workspace-based token will offer a more consistent experience for users. For one, apps won’t break unexpectedly if the original installer leaves the team. As you release new features, you will be able to update your app’s scopes without requiring users to re-install your app.
Workspace tokens encompass both bot user and app functionality, meaning you won’t need to maintain a separate bot user to converse with your users. You will have the flexibility to add bot functionality to your app at any time.
How apps access data
To understand where we’re going, it’s helpful to review the user-centric model of apps today.
Your app’s token currently represents an individual installer’s identity within their Slack team. That means it can access the same Slack channels and direct messages as the users who install it.
As a developer, you receive one access token for every installation, each with potentially different scopes. It can be confusing for developers to reason with multiple tokens on the same workspace — and if your app contains a bot user, you have yet another token to juggle.
Workspace tokens, in contrast, have access to a straightforward set of channels and direct messages which are granted to them by users.
This model will unblock access to customers who previously couldn’t use apps because of security or compliance restrictions. There are fewer surprises on either end, for you or your customers.
Making apps first-class citizens of Slack
Like bots today, workspace-token apps will be listed under the new Apps header in the Slack sidebar. When someone clicks an app from that list, they will be taken to a dedicated space where they can interact with it one on one, view its video and screenshots, and learn more about how it works.
Think of this space as a canvas for future app functionality. You could imagine how it could function for non-conversational apps — as a notification inbox, or a place to onboard users, teach customers about new features, or manage trials.
These apps will be more discoverable in other ways, too. When someone clicks on a channel name to discover more about it, they’ll see that channel’s apps listed in the right-hand pane alongside its pinned items, details, and members list.
Adding apps to channels
Customers can add workspace-token apps to Slack channels by choosing a few select channels, or every channel in their workspace. For instance, an engineering manager could add an incident monitoring app to their #ops, #triage-devops, and #security channels, or add it to every channel at once. An engineer could later add it to channels related to specific features they’re building.
People will be able to easily discover your app, even in channels it’s not in. Workspace-token apps are added to channels like humans are: when somebody starts typing text your app responds to, like its name or commands, Slack will prompt the user to add it to that channel.
An API for more flexible permissions
Let’s say you’ve built a feature that requires a new permission. Soon, you will have the option of using the Permissions API to ask for new scopes within Slack whenever you want — without forcing users to re-authenticate your app. This way, you can ask for fewer permissions up front, and ask for more later when someone is familiar with your app and understands its value.
As well as encouraging more installations with fewer up-front permissions, the Permissions API allows you to engage with people in new ways. For instance, you could use it to guide new users toward more advanced features as they proceed through your app’s onboarding funnel. If your app uses a freemium model, you could use the Permissions API to unlock features that are behind your paywall.
It’s totally optional to adopt a progressive permissions flow, but we have found that as our customers grow in size and complexity, this level of granularity can help you win more app usage.
Join our API Preview
We hope you’ll make impact on the future of these APIs by participating in our API Preview period on August 1.
We will release new functionality and documentation as they are ready, and we’ll ask for your input along the way. You can play around with the features, create a workspace-token version of your existing app, or build something entirely new.
You’ll have ample time to migrate your app before we make workspace-token apps available in our App Directory (roughly targeted for Q1 of 2018). Before this general availability date, we will provide you with tools and a detailed guide with everything you need to migrate your app to the workspace token.
Don’t worry — the user-based app model isn’t going away anytime soon. At some point in the next couple of years, this way of building apps will be represented on our API site as “legacy.”
Workspace-token apps will support all the core functionality your app uses today, from the Events API, to slash commands, and interactive features like message menus. We’re looking forward to hearing your feedback!
A previous version of this blog referred to workspace tokens as team tokens. You can follow us on Twitter or install the Platform News App to get notified about API Preview updates.
