Hello developers,
The original version of Workflow Builder is retiring on September 26, 2024. We will also retire “legacy workflow Steps from Apps” in September 2024, as previously announced. Developers with legacy steps distributed to more than one organization are particularly impacted by this retirement.
There is no direct migration path for legacy steps nor for the workflows that utilize them. You won’t be able to create legacy steps, add them to workflows, or run workflows containing legacy steps after September 26, 2024.
The new version of Workflow Builder features connectors, a new way to integrate with the most commonly used services paired with Slack. Today, Slack builds these connector steps. If a legacy step you used has a connector step in our directory, it might be a good replacement in new workflows you create. You can use them in coded workflows too.
The new version of Workflow Builder also features coded steps. If you built a legacy step for your team or organization, you might be able to rebuild it as a coded function. If you’d like to host your code on Slack, we recommend rewriting your function in TypeScript running on our Deno-based runtime.
If you want to host on your own infrastructure, we have beta support for custom function development in our Bolt for Python and Bolt for JavaScript SDKs. We expect this support to become generally available later this year.
We know this isn't a lot of time if you intend to port your steps to the new framework before the retirement deadline. Prototyping now and providing us feedback will help us deliver the best experience together.
There is currently no way for developers to distribute functions or install them via the Slack app directory, though you can share your creations as open source for others to adopt and deploy.
Once you have created and deployed a coded function, workflows your team used with legacy Workflow Builder must be rebuilt using the new version of Workflow Builder or by building your workflows in code and deploying them with the Slack CLI.
We recommend migrating the legacy custom steps you rely on to our new automation platform as soon as possible. If you’re comfortable using beta software, our Bolt SDKs provide the shortest, but still quite rocky, migration paths. Our Deno-based platform is production-ready for the enterprise and it provides a smooth developer, user, and admin experience.
Please alert us to your questions, comments, and concerns at feedback@slack.com.
Thank you, Slack platform team
In this FAQ, we restate, clarify, and illuminate information also found in our detailed deprecation changelog.
Legacy Steps from Apps will no longer be supported starting September 26th, 2024. If you have an app that exposes legacy steps to your users via Workflow Builder, all of those steps will disappear on September 26th, 2024.
There is no 1-for-1 migration path; not all features in the new platform support what was possible with Legacy Steps from Apps.
Apps that distribute steps as part of being a distributed app — installed on more than one organization or as part of the Slack app directory cannot be ported to the new workflow system at this time.
If you want to port your app intended for your workspace or organization, you must:
Our automation platform does have financial implications that were not part of the legacy Workflow Builder ecosystem.
In the old model, when steps were added or modified or removed from a workflow, you would get a unique event dispatched to your app. In particular, you could pop up a configuration modal to collect important details your step needed to run for that workflow. You would then receive an event each time your step was executed as part of a workflow, allowing you to execute your business logic.
In the new model, your app will only receive an event when your function is executed. However, unlike legacy steps, functions take arguments and arguments are provided from either the previous step, the triggering action, or information you already have at your disposal. If you need to collect configuration information, you'll need to do so in a conversation or some other secured interface. While your custom function might have side effects like using APIs to post messages or take other actions, most steps provide return values for another step to take over.
In the old model, workflows were frequently closely associated with a channel and a specific workspace.
In the new model, workflows are installed enterprise-wide and are only loosely associated with the channels they are used in.
The new model brings many other enhancements. You might even find your custom step is no longer necessary.
| Old event | New event | Comment |
|---|---|---|
workflow_step_execute |
function_executed |
Very different payloads. |
workflow_published |
No equivalent | You can't track when a workflow is published containing your function. |
workflow_unpublished |
No equivalent | You can't track when a workflow containing your function is unpublished. |
workflow_deleted |
No equivalent | You can't track when a workflow containing your function was deleted. |
workflow_step_deleted |
No equivalent | You can't track when your function has been removed from a workflow. |
view_submission |
No equivalent | You can't use an event to trigger a configuration step when you function is added to a workflow. |
Unfortunately every workflow containing a legacy step will need to be rebuilt by hand in the Workflow Builder or through.
Here are some tutorials to help you get started:
Yes, get started here and discover our tutorials and samples here.
If you want to provide your users with an alternative way to obtain, deploy, and utilize custom steps for your service, we recommend developing custom functions as a template project for the Slack CLI. The Slack CLI reduces friction in getting started with open source templates authored in TypeScript for our Deno runtime.
For inspiration on sample projects, check out our sample repository on GitHub.
For example, if you hosted a collection of functions or workflows at https://github.com/mycompany/slack-automation, you could instruct your users to clone, customize, run, and then deploy your solution for their workspaces.
$ slack create automate-mycompany -t mycompany/slack-automation
If you have open sourced automation projects on GitHub, we'd like to know more and help your users find them. Drop our developer relations team a message through Slack support.
Workflows will no longer be accessible after September 26, 2024. You won't be able to view or edit them. They won't be executable. If you can't port your steps or workflows containing steps before September 26, 2024, you should make a record of your important workflows and steps now.