If you came here expecting an answer to a question that you did not find, please let us know.
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.
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.
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.
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.
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:
api.slack.com, configuration information and documentation resourcesdownloads.slack-edge.com, where binaries and other static resources are hosted by Slackslack.com, where most of the individual APIs reside called by the CLI and your appslackb.com, general logging for your triggers, functions, and workflowsslackd.com, where we send information about errors, warnings, and other special conditionsdeno.land, where the Typescript runtime, Deno, resolves & retrieves dependencies and versionsFor more information, refer to team collaboration.
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.
At this time, apps that run on Slack are built with Typescript in a Deno runtime environment.
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.
An example of how to do this is shown in the GitHub Issue tutorial, but the long and short of it is this:
.env file could look like this.github_name = slackbotsbestpal
github_token = ABC123DEF
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(
MyFunctionDefinition,
async ({ inputs, env }) => { // Add this
const headers = {
Authorization: `Bearer ${env.GITHUB_TOKEN}`,
"Content-Type": "application/json",
};
try {
const endpoint = "https://api.github.com/users/repos";
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.
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 "https://deno.land/x/mock_fetch@0.3.0/mod.ts";
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.
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.
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.
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.
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.
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.
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.
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
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.
The slack deploy command performs two operations:
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.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.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.