An admin’s guide to app management

Apps help your team unlock productivity by making essential tools accessible in Slack where your team is already working. As an admin, your role is to balance giving employees the flexibility to use apps, while also maintaining control over how apps operate in the organization.

To that end, we’ve compiled best practices for how to make it simpler and smoother for you to manage apps for your organization securely and at scale.

Introduction to app management

Let’s start by breaking down app management into four steps:

  1. Requesting an app
  2. Approving or restricting an app
  3. Installing an app
  4. Authenticating your account with an app

For each of these steps, there are specific decisions you can make to adjust app management to your organization’s needs.

As we walk through each step, think about the type of governance you want to apply to app management. Should decisions be made top-down, that is, set by org admins and owners to apply across all workspaces in the organization?

Or is it better to have a bottom-up approach, so that workspace admins are responsible for making decisions for their respective workspaces? 

Each organization will have a different approach to decision making—so there’s no “right” answer. In fact, many organizations use a hybrid approach where some decisions are made top-down and others are made bottoms-up. 

Step 1: Requesting an app

Turning on app approvals is an important step to ensure that you have control over which apps are used in your organization and, more importantly, what data becomes available to apps once they’re installed. 

Turning on app approvals for a workspace

You can turn on app approvals for each workspace by going into the App Management Settings. This is a bottom-up approach in that the workspace owners will turn on app approvals and choose whether they’d like to configure where app requests are sent. You can also designate team members to serve as app managers—people who have the ability to review app requests.

Turning on app approvals for an organization

Org admins can add an organization policy that automatically turns on app approvals for all existing workspaces and any workspaces created in the future. 

Organization policies allow you to make app management decisions that apply across all workspaces in the organization. These policies act as safeguards to ensure that your workspaces are consistently following the same rules.

Step 2: Approving or restricting an app

Once app approvals are turned on, the next step in the app management process is approving or restricting an app. In order to create structure and add predictability to what apps get approved or restricted, it helps to take a step back and work as a team to translate internal security practices into guiding principles for why an app should get approved or rejected. 

Each organization will have different security practices and risk tolerance. By determining this information upfront, you can help set precedence for how apps operate in your organization. 

Evaluating Slack permissions

The first set of criteria you can assess is what permissions the app is requesting to access in your Slack workspace. It’s important to understand the risks and benefits of allowing apps certain permissions—apps can transform workflows in your organization, but it will come at the cost of sharing data.

Apps will request certain permissions to unlock the ability to do three things in Slack: 

  • View information
  • Post information
  • Perform actions

Let’s run through an example using the Jira Cloud app. Below is a conversation about an error being identified by the team. After Arcadio logs the bug, the Jira Cloud app posts back into the channel so the full team has visibility into the issue. 

An app’s permissions are governed by API scopes and methods, which the app has access to. Let’s dissect what permissions and scopes are required in order for the Jira Cloud app to work.

  • View information

The first set of permissions relates to viewing information. Here, the Jira Cloud app is specifying that it’s Arcadio who created the bug. In order to do this, the app needs permissions to “view people in the workspace” so it can map their Slack user IDs back to their Jira user IDs. 

By granting this permission, the Jira Cloud app makes it easy to quickly see who created a bug and send the user a follow-up message in Slack—no need to pull up Jira to search for those details.

  • Post information

The second type of permission an app will request is the ability to post information. The Jira Cloud app posts in channels, and in order to support this, the app needs permission to send messages as Jira Cloud.

By granting access to this permission, the Jira Cloud app pipes real-time notifications into a channel, giving the team visibility into bugs so they can quickly respond to issues.

  • Perform actions

Lastly, apps will request permission to perform a variety of actions in Slack. The Jira Cloud app allows users to take action from a notification, like watching the issue or assigning it to someone.

By granting access to this permission, there’s no need to open Jira, search for an issue or assign it to a person—all of that can be done in a few clicks, right in Slack.

A new granular model for Slack permissions

With this Jira example, you can start to see how certain permissions are fundamental for an app to function. However, sometimes an app requests a broader set of permissions—and those permissions don’t always clearly map to the functionality of the app. Rather, it seems like the app is requesting an unnecessary amount of data. 

To address this concern, we launched a new granular permissions model, which enables app developers to request only the scopes their app needs to function.

As more app developers adopt the granular permissions model, you’ll notice that apps will start requesting a narrower set of permissions that map back to the app’s functionality, resulting in an altogether smaller security footprint.

As an admin or app manager, this should make the process of approving and restricting apps more transparent and specific, so it’s easier to evaluate apps for permissions that don’t meet your security standards, and swiftly approve ones that are compliant. 

Reviewing an app’s security details

In addition to permissions in Slack, admins also want to trust the app developer’s security practices too. Developers can now feature their security and compliance details in a new tab in their App Directory listing, from SOC and HIPAA compliance certificates to data retention policies and more.

Instead of searching across disparate resources, you can access critical security and compliance details about an app in one place, right from Slack’s App Directory.

Managing org-wide app approvals

The next natural question is how do you operationalize app approvals in a way that’s scalable and efficient? With Slack’s admin features, it’s simpler to manage app approvals at scale.

First, we have a new dashboard for org-wide app approvals built specifically for Enterprise Grid admins who are managing apps across multiple workspaces. 

This dashboard is designed to streamline the process of reviewing app approvals, allowing admins to approve or restrict apps in bulk across the organization.

This means you can spend less time managing a queue of requests. Plus, you can maintain a bird’s-eye view of what apps are requested, restricted and approved across workspaces in one place—which is handy for checking that app management practices are enforced across the organization.

Automating app approvals using Slack’s API

Some admins have more nuanced criteria for app approvals or simply want to further optimize the app approval process. The admin APIs for app management provide the infrastructure to build a custom app that automates parts (or all) of the app approval process.

Using Slack’s API, a developer can define criteria and set rules to automate app approvals and rejections across all workspaces in a Grid organization.

Once you have that playbook of rules for app management for your org, Slack’s API will give you the ability to take action on those rules and architect a custom solution based on your org’s specific needs.

Not everyone will have resources internally to build a custom app. If you’re looking to hire a developer, we recently launched a new services partner program with highly qualified companies that can help you build a solution with the APIs. 

Step 3: Installing an app

Once an app is approved, the next step is installation. The user who submitted the original request will receive a message from Slackbot letting them know that the app is approved to be installed in the workspace they requested. At this point, they’ll be directed to visit the App Directory to install the app on the requested workspace.

Installation flows will vary across apps—because each app requires a different combination of permissions and additional configuration for the app to get set up from end to end. There are two primary inputs that determine the installation flow:

  • What access to data does the app need? Does it need access to data from Slack, data from the third-party service or both? 
  • What extra configuration does the app need? Are there additional steps to get the app set up in Slack, in the third-party service or both? 

Let’s run through a few examples of each of these scenarios to help put these inputs in context. 

Granting access to data

When it comes to what data is being accessed—some apps only need permissions from Slack to function. The app Simple Poll facilitates basic surveys and only really needs responses from users, which is data solely in Slack. 

However, other apps will need third-party permissions from whatever service is being integrated. For example, the Google Calendar app needs access to a user’s calendar data in order for the app to perform its primary function—sending meeting reminders and syncing a user’s Slack status with their calendar.

Configuring an app

After granting permissions, the next step is completing any extra configuration. Not all apps require configuration, but for the apps that do, it’s typically because there’s some form of manual input required from the user. For example, if you’re using the Twitter app, you’ll need to configure what channel to post tweets in. 

Other apps will require much more in-depth configuration from the third-party service, usually when there’s another app marketplace involved. For example, in order to install the Salesforce app, you’ll need to enlist the help of your Salesforce admin to take action from the Salesforce AppExchange and install the right Salesforce package. 

It’s important to look out for this level of nuance because if you approve an app, it doesn’t mean it’s immediately working in Slack. When you’re reviewing an app request, look out for callouts that state that there’s additional configuration required—like Salesforce, Workday or Zoom do, to name a few. 

Step 4: Authenticating an app

Lastly, once an app is installed, it’s available for anyone in that workspace to discover. However, depending on the installation flow, some apps will require each individual user to run through an extra authentication step.

Specifically for apps that deal with user-level data, each user needs to grant the app permission to their individual account details by authenticating with the third-party service. This gives users the choice to share more personal data—like calendar details—rather than having data automatically shared with the app.

Best practices from Slack’s security team

Now that you have a foundation for app management, here are a few practical tips and tricks from Slack’s security team:

Document guiding principles for app reviews

Work with your security team on determining guiding principles for why an app should get approved or rejected. Clear guardrails will empower admins and app managers to make smarter decisions about an app without needing to consult the team.

Educate your organization about app requests

A great way to improve the quality of app requests is to create and socialize a FAQ document—because if people already know what they might or might not be allowed to install, you’ll get better requests.

For example, if you’ve decided to restrict any permissions as absolute no-gos, what are they? Let users know, and let them know why.

It’s also helpful to give guidelines about what they should look for when they’re considering apps. You might tell them about trusted developers they can start with, or specific apps that have already been restricted.

Drive discovery of approved apps

In order to reduce our threat surface, Slack’s security team tries to minimize the repetition of apps. For example, it might not be necessary to have three types of polling apps if each serves a similar use case.

We evaluate and identify an app that works best for a specific use case—then recommend our employees to use that particular app (unless there’s a business need for a similar app).

We also find that users request apps because they’re searching for a solution and might not know what’s already available.

There’s now a dedicated Apps page—accessible from the sidebar right in Slack—where users can find apps that are already installed in their workspace. Direct users to this page and give them a chance to get familiar with approved apps before requesting new ones.

More of an auditory learner? We’ve put together this content in the form of a webinar, Managing apps securely and at scale

Was this resource useful?

0/600

Awesome!

Thanks so much for your feedback!

Got it!

Thanks for your feedback.

Oops! We're having trouble. Please try again later!

Related Resources