Automation platform FAQ

If you came here expecting an answer to a question that you did not find, please let us know.

Slack developer questions

What does beta platform mean, exactly?

During this openly accessible beta period, we will continue to evolve and add to the new Slack platform. We'll also try to ensure we don't make any significant breaking changes that require large amounts of refactoring of your work.

However, this is still a beta, and you should be forewarned that things can and probably will change, and those changes could be major.

What are the requirements to join the beta?

Slack customers on any paid plan can participate in the beta. Before you begin, an admin or owner of your workspace needs to have accepted the Slack Platform and Beta Service Terms here.

To do this, navigate to Workspace > Settings & administration > Workspace settings and select the Permissions tab. Scroll down to Slack Platform Beta and click the Expand button. Select the check box next to I have read and agree to the Slack Platform Beta Service Terms.

What do I need to do before building on the next generation Slack platform?

For any paid workspace you want to build for, make sure an admin or owner of your workspace has accepted the Slack Platform and Beta Service Terms as discussed above. This will get your workspace ready to participate in the beta.

How do I set up my developer environment?

Head to the Quickstart guide to use our automated installer script— or download the latest version of the slack CLI and follow instructions to install it manually.

Once your workspace is ready, head to the Quickstart guide to use our automated installer script— or download the latest version of the slack CLI and follow instructions to install it manually.

Using a combination of your favorite text editor, the slack CLI tool, and the included future generation SDK, you will program in TypeScript for a Deno-based runtime.

Which hosts are involved in the creation and execution of apps created with the CLI?

The new Slack platform is closely tied to specific language runtimes and SDKs. As you install and utilize your developer tools, you should expect requests from your network to the following non-exhaustive list of hosts:

  •, configuration information and documentation resources
  •, where binaries and other static resources are hosted by Slack
  •, where most of the individual APIs reside called by the CLI and your app
  •, general logging for your triggers, functions, and workflows
  •, where we send information about errors, warnings, and other special conditions
  •, where the Typescript runtime, Deno, resolves & retrieves dependencies and versions

How can two or more developers collaborate on an app?

For more information, refer to team collaboration.

How do I build a slash command in the next generation platform?

Workflows can be started manually by users via link triggers. There are multiple ways to invoke a link trigger, and one of them is with a / keystroke via the Shortcut menu.

In other words, you can use a slash command to invoke a link trigger that will kick off a workflow.

Which languages are supported for Run on Slack?

At this time, apps that run on Slack are built with Typescript in a Deno runtime environment.

What's the difference between slack run and slack deploy?

When you use slack run, the local development version of your app connects to Slack via socket mode directly from where you're developing. As you use Slack (or other tools) to interact with your app's triggers, workflows, and functions, data is sent back and forth against your latest saved code. Use this while you're still tweaking things. Your development app is generally only shared with other collaborators, though you can test the full range of trigger options anyway.

When you use slack deploy, the fine computer instructions you've written are packaged up and deployed to Slack. As users interact with your app, data is swiftly and securely sent back and forth between Slack servers. Treat this instance of your app with care, especially as your userbase grows.

The local and deployed environments have different triggers associated with them. Triggers you create in a local context will not automatically be created in a deployed context when you deploy your app.

How do I call a third-party API from my next generation Slack app?

An example of how to do this is shown in the GitHub Issue tutorial, but the long and short of it is this:

  • Store API credentials as local environment variables. In the GitHub tutorial, for instance, your .env file could look like this.
github_name = slackbotsbestpal
github_token = ABC123DEF
  • Use the env context property to call environment variables from within your function.
import { DefineFunction, Schema, SlackFunction } from "deno-slack-sdk/mod.ts";

export const MyFunctionDefinition = DefineFunction({
  callback_id: "my_function",
  title: "my function",
  source_file: "functions/my_function.ts",
  input_parameters: { properties: {}, required: [] },
  output_parameters: { properties: {}, required: [] },

export default SlackFunction(
  async ({ inputs, env }) => { // Add this
    const headers = {
      Authorization: `Bearer ${env.GITHUB_TOKEN}`,
      "Content-Type": "application/json",
    try {
      const endpoint = "";
      const response = await fetch(endpoint, { method: "GET", headers });
      if (response.status != 200) {
        // In the case where the API responded with non 200 status
        const body = await response.text();
        const error =
          `Failed to call an API (status: ${response.status}, body: ${body})`;
        return { error };
      // Do cool stuff with your repo info here
      const repos = await response.json();

      return { outputs: {} };
    } catch (err) {
      const error = `Failed to call GitHub API due to ${err}`;
      return { error };

That's all! When you run your app, it will use the environment variables stored within your .env file. Of course, you won't be using your .env file when your app is deployed (nor should you ever commit that file to source control), so the real power of Run on Slack app environment variables is seen when you use the env Slack CLI helper. Once your app is deployed using slack deploy, add your environment variable with the following command:

slack env add github_token ABC123DEF

If your token contains non-alphanumeric characters, wrap it in double quotes. Environment variables added via the slack env add command can be accessed via the env CLI helper, which also allows you to update and remove them.

Can I import additional libraries and SDKs into my next generation Slack app?

Yes, you can! To use a Deno Third Party Module, Deno imports modules using URLs. You can see how we do this for a test file in the Deno GitHub functions sample app

// /functions/create_issue_test.ts

import * as mf from "";

How can I integrate the CLI into a pipeline

In addition to being useful for setting up new projects and for local development, the CLI can be integrated into test and deployment pipelines for continuous integration and continuous deployment (CI/CD) and other "headless" automation.

Running in a headless mode first requires authorization using the --auth flag, and passing along a user token. The token, however, will require implementing logic to continually rotate it, since tokens obtained via slack login will expire after a certain amount of time. This will generate the authorization credentials required in a ~/.slack directory. Removing this directory will remove the authorization.

Once authorized, any slack command can be run as normal, and will use the established authorization.

Slack administrator questions

Even some Slack developers are themselves Slack administrators, but of course if you're an admin you might find yourself here wondering these very same questions. If you don't find the answer to your administrative questions here, do consult the Slack help center for more user and admin-facing content.

What's new?

  • Previously, workflows could only be created with Workflow Builder. Now, developers can build and publish workflows for anyone in their Slack workspace or Enterprise Grid organization to use. They can also build custom functions that people will soon be able to add to workflows they create with Workflow Builder.
  • When developers build workflows and functions, they can set access permissions to determine who can run a workflow or add a function to a workflow. Admins can further restrict access to functions, if they’d like.
  • You can now view some workflows on the published workflow dashboard. Workflows built with Workflow Builder will still need to be viewed and managed from the All Published Workflows tab in Workflow Builder, but we’re working to move all workflows to the dashboard.

How do I turn off developer access to functions and workflows?

The new custom functions and workflows introduced to the Slack platform cannot be completely disabled. Instead, you can manage their installation via the app approvals feature.

How do I discover and manage which functions and workflows are installed in my workspace?

From the published workflow dashboard, you can view a list of workflows in your workspace or Enterprise Grid organization. You’ll also see a banner at the top of the dashboard page showing how much of your premium workflow allotment has been used.

How will I be charged for using the platform?

For the most up to date information about pricing, please consult this help center page on pricing.

These changes to our platform are designed to simplify and streamline development through new capabilities, like reusing custom functions and running your app on our managed infrastructure. To reflect that added value, our next-generation platform has a paid component.

Whether a workflow is standard or premium depends on the type of functions it includes, and usage is determined by how many times a workflow is run. Paid Slack plans include standard workflow runs and an allotment of premium workflow runs.

Note: Premium workflows are chargeable. If you exceed your allotment of premium workflow runs, pricing is based on how many times you run a premium workflow.

Learn more about pricing

Is there a promotional pricing period?

From April 24, 2023 to October 31, 2023, customers will not be charged for any premium workflow runs. Starting November 1st 2023, you’ll be charged for any premium workflow runs that exceed your plan’s allotment. If you don’t exceed your allotment, you won’t be charged.

What makes a workflow standard or premium?

Currently, workflows are considered standard if they use Slack functions and premium if they include at least one custom function. Right now, developers and customers in our Workflow Builder pilot program can build workflows using custom functions.

How do I know when our workspace will be charged for premium workflow runs?

If you’re a Workspace Primary Owner or admin with permissions, you can also go to your Billing page to see how many premium workflow runs included in your plan’s allotment have been used. Questions? Let our Support team know, or reach out to your account executive

Will existing custom integrations and Slack apps continue working?

Your existing apps will continue working as expected. Some classic or traditional Slack apps might even produce activity in Slack you can build custom functions and workflows around. That said, the next generation automation platform is meant to co-exist with our existing platform and your existing integrations and customizations.


Deployment and installation

The slack deploy command performs two operations:

  1. Deploys all functions associated with your app to the platform, and
  2. Installs your app into the selected workspace.
  • Slack is currently optimized for the first-party developer use case, in which the expectation is that the developer has access to the workspace in which they’re building the app.
  • When the app is installed as part of slack deploy, the workflows that belong to that app are also “installed” (made available) in that workspace. Currently, there is no way for a coded workflow to be "installed" (via the parent app being installed) by anyone other than the developer. However, coded workflows do not have to be deployed alongside a trigger; since triggers don't belong to apps, all deployment and installation happens first and then a trigger is created separately afterward.
  • Workspace owners and administrators cannot run slack deploy to deploy apps when a workspace has admin-approved apps turned on. Use an alternative non-admin or non-owner account to build, test, and deploy beta apps.
  • JSON or YAML-based app manifests are no longer how your app's configuration is canonically defined. Instead, both your app's configuration and your function definitions will reside in manifest.ts.

Have 2 minutes to provide some feedback?

We'd love to hear about your experience building modular Slack apps. Please complete our short survey so we can use your feedback to improve.