Which open-source options replace Slack Workflow Builder?
A team whose approval forms, scheduled reminders and intake questions live in Workflow Builder needs those jobs to survive a renewal, a pricing change or a residency requirement. The short answer: a self-hosted chat server, with Mattermost as the main example, plus slash commands, incoming and outgoing webhooks and an automation tool such as n8n or Windmill covers most Workflow Builder jobs, but none of these pieces is a drop-in copy of it. Workflows are built from parts you assemble and operate yourself, so each one must be redesigned, not exported.
Slack exports do not carry integrations, so every Workflow Builder workflow must be inventoried and rebuilt on the new server. Confirm whether Mattermost Playbooks and any incident or approval features you rely on are available in the edition you plan to run, because the free Team Edition and the paid editions differ in feature set (see the Mattermost editions documentation). Ask a vendor or your own test environment to confirm the exact behavior before you commit.
On the automation side, n8n's Sustainable Use License limits commercial use, and n8n SAML single sign-on is limited to the Business and Enterprise plans, so check the license and identity requirements against your intended use. Windmill's Community Edition is free for internal use, while Enterprise adds SAML, SCIM and audit logs. Plan for the bots and approval flows to run as separate services with their own databases, credentials, backups and upgrade cycles, and budget administrator time to maintain them. Start with a list of every workflow, its trigger, its approvers and its data, then decide which ones need a form or a database record, not just a message.
Mapping Workflow Builder capabilities to open-source options
This table maps the common jobs teams build in Slack Workflow Builder to the self-hosted components that handle them: Mattermost slash commands, Playbooks, incoming webhooks, and an automation tool such as n8n or Windmill. Read the third column first, since it marks where a match is partial and which feature you must confirm in your Mattermost edition or automation tool version. The main takeaway is that chat carries the conversation while the automation tool holds the logic, state and schedules.
| Workflow Builder job | Open-source component | Coverage and what to confirm |
|---|---|---|
| Form-style intake | Mattermost slash command sending input to an n8n or Windmill webhook | Good for short requests. Multi-field dialogs need interactive message support, which you should confirm in your Mattermost version. |
| Approval steps | Mattermost Playbooks for checklists, with n8n or Windmill holding approval state | Partial. Playbooks can track steps, but a durable decision record for audit usually needs a separate store. Confirm Playbooks is enabled in your edition. |
| Scheduled messages | Scheduler inside n8n or Windmill posting to a Mattermost incoming webhook | Full for recurring posts. Confirm time zone handling and which process runs the trigger in your deployment. |
| Posting on a trigger in another tool | n8n or Windmill webhook trigger that forwards events to a channel | Full where the source tool can send webhooks. Confirm the specific connector exists in your automation tool version. |
| Posting to a channel from an outside system | Mattermost incoming webhook targeting a named channel | Full for one-way notices. Confirm the posting bot account is a channel member and plan token rotation. |
| Branching logic, retries and multi-step flows | Windmill flows or n8n workflows with code steps in JavaScript or Python | Full in principle. Confirm retry and error handling behavior in the version you deploy, since Workflow Builder has no direct equivalent to test. |
| Run history and admin visibility | Execution logs in n8n or job history in Windmill | Partial. Slack's history limits do not apply, but you must set retention for execution data yourself and confirm it meets your policy. |
Which automation layer fits a self-hosted Workflow Builder replacement?
Workflow Builder mixes three jobs: simple triggers, structured approval or incident runs, and scripts that call other systems. Each option below covers one of these jobs, and most teams combine two of them. Check each card's trade-offs against your license, edition and staffing before you pick a layer.
Mattermost slash commands and webhooks
Incoming webhooks post messages into a channel from another system, and slash commands let a user type a command that calls an endpoint you run. This covers the simple Workflow Builder cases, such as a scheduled reminder or a request that posts to a channel. Slack-style incoming webhook payloads may work unchanged, but slash commands and any mention forms need testing, because Slack integrations do not migrate automatically. Your developers maintain the receiving endpoint, its authentication and its error handling.
Mattermost Playbooks for structured runs
Playbooks is the option for repeatable, multi-step runs such as incident response or a checklist that must be completed in order, with owners and status tracked in the channel. It fits teams whose Workflow Builder use centered on approvals and recurring process steps rather than one-off messages. Confirm that the Playbooks features you need are available in the edition you run, since the Team Edition and paid editions differ. Your admins maintain the playbook templates and the people who own each run.
n8n for visual workflows
n8n builds workflows on a visual canvas, with custom JavaScript or Python code where the built-in nodes stop. Its catalog of integrations is the main reason to choose it over writing every connector yourself. Check the Sustainable Use License before you use it commercially, since it limits use to internal business purposes and non-commercial use, and check which plan includes SSO (Business and Enterprise) and queue mode scaling (Enterprise for multi-main). Your team maintains PostgreSQL, Redis workers and the shared encryption key that queue mode requires.
Windmill for scripted flows
Windmill runs scripts written in several languages, including Python, TypeScript, Go, Bash and SQL, and composes them into flows or low-code apps. It suits teams whose developers already write scripts and want the logic in version-controlled code rather than in a canvas. The Community Edition is free but caps workspaces, users and groups, and SAML, SCIM and audit logs sit in the Enterprise Edition. Your developers maintain the scripts, the PostgreSQL queue and the workers, which Windmill sizes at about one worker per vCPU with 1 to 2 GB of RAM.
What changes for forms, approvals and scheduled messages
In Workflow Builder, a form-style request is usually a step that collects answers inside a channel and posts them back. On a self-hosted server, intake is rebuilt as a slash command that opens a prompt or dialog, or as a short web form whose submission is sent to an automation workflow, which posts a summary to a channel. The chat thread shows the request, but the structured answers should live in a system the team can query and export.
- Slash command entry: A command such as
/requeststarts intake and collects the fields in order. Confirm which interactive dialog types your Mattermost version supports before you design the flow around them. - Web form for complex intake: Multi-field forms, file uploads and conditional questions often fit better in a web form that calls an n8n or Windmill endpoint, with chat carrying a link and a summary.
- Structured record: Write each submission to PostgreSQL or a ticketing system with requester ID, timestamp and field values, so the thread is not the only copy.
- Validation in the workflow: Required fields, allowed values and date formats must be checked by the workflow, since a chat prompt does not enforce them on its own.
- File handling: Choose where uploads are stored, such as object storage on your own servers, and set retention before launch.
Check who can read submissions, how long they must be kept, and whether uploaded files stay inside your network.
An approval in Workflow Builder is a step that asks a person to decide and then moves the request forward. Self-hosted, the decision is handled by a workflow in an automation tool such as n8n or Windmill. The workflow posts the request to the approver's direct message or a channel, waits for the response delivered by webhook, stores the outcome and notifies the requester. The approval logic and its history sit with the workflow, and chat only carries the notifications.
- Decision recorded outside chat: Store approver, decision, time and stated reason in a database. The chat message is a notification, not the record.
- Approver identity: Confirm that the responder is the designated approver through the identity provider behind your single sign-on, not from a name typed into a message.
- Timeouts and escalation: Define reminders, the wait period and the escalation path for silence. Long waits need durable executions in the automation tool.
- Separation of duties: Requesters should not be able to approve their own requests, and the workflow must enforce this.
- Audit trail: Keep workflow run history with inputs and outputs. The Windmill repository documents audit logs as an Enterprise feature, so confirm which edition you need before relying on them.
Confirm which audit logs, SSO and provisioning features your chosen edition includes before using them as control evidence.
Scheduled messages and recurring reminders move from Workflow Builder's scheduler to a schedule trigger in the automation tool. The workflow posts to a channel through a bot account or an incoming webhook. Once the schedule is a workflow definition instead of a setting in a chat app, it can be reviewed, versioned and tested before it runs for the whole team.
- Posting identity: Post through a bot account with only the channel permissions it needs, so the message is clearly automated and cannot change other settings.
- Time zones and calendars: Set the time zone explicitly and test around daylight saving changes, since chat schedules often assume a single office.
- Single execution: Confirm that each scheduled run fires once. In n8n queue mode, the main instance handles triggers, and multi-main high availability is limited to Enterprise self-hosted deployments.
- Change control: Git-backed environments are included only in n8n's Business and Enterprise plans, according to its pricing page. Without them, record who changed a schedule, its text and its recipients in your own change process.
- Failure alerts: Send failed runs to an alert channel so a missed reminder is noticed by someone.
Check whether scheduled posts must be kept as records and where the message text and recipient lists are stored.
Licensing and security limits when automation touches chat
The license of each layer decides what your team may do with the automation it builds, so review it before you commit to a design. Mattermost licenses its compiled binaries under the MIT license, its source code for custom builds under AGPL v3.0 with a commercial alternative from Mattermost, Inc., and its admin tools and configuration files under Apache 2.0. A team that modifies the server, or distributes a build to a partner, is in different territory than a team that only runs the official binary. On the automation side, n8n is fair-code under the Sustainable Use License, which permits use or modification for your own internal business purposes and distribution only free of charge for non-commercial purposes. Any file with .ee in its name or directory needs a valid n8n Enterprise License. Windmill's prebuilt Community Edition images include proprietary code that is free for internal use, while managed services or reselling require a commercial license. Ask legal to confirm whether an internal approval bot, a service you offer to other business units, or a hosted instance run for a client falls inside each of those terms.
The security questions sit at the join between chat and automation. Every webhook URL that a slash command or workflow exposes is effectively a credential, so confirm how each platform signs or validates inbound requests, who can rotate those secrets, and how often they change. Decide which Mattermost roles and channel memberships may trigger commands that approve access, reset passwords or write to other systems, and restrict those commands to named groups rather than every channel member. For credentials, check where n8n stores the secrets used by its workflows: in queue mode, the main instance's encryption key must be shared with every worker and webhook processor so they can read those credentials from the database, which makes that key one of the most sensitive values in the stack. Windmill's external secret backends, such as Vault or AWS Secrets Manager, are listed as Enterprise Edition features, so confirm whether your edition supports the controls you need. Document these answers before the first workflow goes live.
Running Workflow Builder jobs beside Slack during the transition
Workflow Builder jobs rarely move in one step. The cards below set out the parallel decisions that keep forms, approvals and scheduled posts working while the new flows are built on a self-hosted chat server. Each decision controls a specific risk, so the checks can be run before any team is switched over.
Keep Workflow Builder live until rebuilt
Leave every Slack workflow running until its replacement has passed a documented test. A scheduled message or approval step that is turned off too early leaves a gap nobody notices until a deadline is missed. Before switching off a workflow, list each trigger, form field and downstream action, then confirm the replacement handles each one. The main risk is missed approvals during the gap, so record who is notified and how the request is recorded.
Test new flows in a sandbox channel
Run each rebuilt flow in a private test channel on the self-hosted server before it posts to a live channel. Use an illustrative test workflow, such as a weekly status reminder, to check that the trigger fires once, the message renders correctly and the right people see it. The main risk here is duplicate posts, which happen when Slack and the new flow both fire on the same schedule. Confirm the test channel receives no output from the Slack workflow.
Switch one team at a time
Move one team to the new flows, then wait through a full business cycle before moving the next. A staged cutover limits the blast radius if a webhook URL, token or user mapping is wrong. Keep a short list of owners who can roll a team back to Slack within the same working day. Before each switch, confirm that users, channels and bot accounts exist on the new server, since migration tools do not carry integrations across.
Keep the Slack export for history
Export the Slack workspace data before you turn anything off, and store the export under your retention policy. Slack's export rules depend on the plan: public channels are available on every plan, while private channels and direct messages need an approved Business+ or Enterprise application. Ask which records form requests or approvals will be needed later, and confirm you can still read them. The main risk is lost records when the history you need was never exported.
Assign owners for identity and approvals
Decide who owns each workflow that touches user identity, access requests or approval decisions before it moves. Those flows often depend on a directory lookup or a manager field, so an automation that runs under a departed user's account can keep working in the wrong way. Name an accountable owner, the service account the flow runs under and the approver group. Check that identity data comes from the directory you control, and that the automation tool's login and role settings match that owner's responsibilities.
How to inventory and rebuild Workflow Builder workflows
This sequence turns an unstructured set of Slack Workflow Builder automations into a documented inventory, a tested rebuild on a self-hosted chat server, and a controlled cutover. Each step produces an artifact your team can review before anything changes for users.
Export the workspace and confirm the plan
Ask the Slack workspace owner which plan the workspace is on and whether an export of private channels and direct messages is possible, since that depends on the plan and the approval process described in Slack's export documentation. Run the export and keep it, then note that the export carries messages and files but not Workflow Builder definitions, apps or integrations. The step is done when the owner confirms the export scope in writing and the team knows which workflow sources must be documented by hand.
Build the workflow inventory
Have each workflow owner, or an admin who can view the Workflow Builder list, record every workflow with its name, owner, trigger (such as a channel post, a scheduled time, a form submission or an emoji reaction), ordered steps, data fields collected, and the people or channels that use it. Store the inventory in a shared document the team can edit. The step is done when every workflow has a named owner and a complete row, and unused workflows are marked for retirement.
Classify each workflow by pattern
Group the inventory into the patterns that map to self-hosted tools: simple announcements or reminders that a slash command or webhook can post, form-style requests that need a structured input, approval chains that need a decision record, and multi-system actions that need an automation flow with connectors. Mark any workflow that depends on a Slack-only feature or an app that will not exist on the new server. The step is done when each row has a target pattern and every exception has a documented owner decision.
Inventory integrations and user groups separately
Because Mattermost's Slack import does not carry over integrations, custom emoji images or user groups, list every app, webhook URL, bot account and user group that the workflows reference, and record which channels and members each one touches. If you are moving to Mattermost, note that Slack-style incoming webhooks may need payload checks before reuse. The step is done when a second inventory of integrations and groups exists and each item has a rebuild target or a retirement decision.
Rebuild each workflow on a test server
Stand up a non-production chat server and rebuild each workflow as a slash command, an incoming webhook, or an automation flow in an engine such as n8n or Windmill, which receives the webhook and posts back to chat. Keep credentials in the tool's secret store, and record each flow's trigger URL and owner. For an automation engine, check its license terms for your intended internal use before deployment. The step is done when every inventory row has a tested build on the test server and its configuration is recorded.
Run approval and schedule tests with real owners
Ask each workflow owner to run their workflow in a test channel with a small set of real approvers, covering both approve and reject paths, missing-field inputs and a scheduled trigger that fires at the planned time. Compare the posted messages, recorded decisions and downstream actions against the Slack version, and log every difference. The step is done when the owner signs off on each test in writing and each mismatch has a fix or an accepted change.
Cut over and retire the Slack versions
Announce the cutover date to affected channels, move the live triggers to the production server, and disable the matching Slack workflows instead of deleting them so the definitions remain available for audit. Keep the Slack export archived under your retention policy. Confirm with each owner that the production workflow posts in the right channel and that no Slack trigger is still firing. The step is done when every production trigger is live, every Slack workflow is disabled and recorded, and the inventory shows a final status for each item.
What the self-hosted workflow stack costs to run
The cost of this stack is split across components, and each one has a different payer and a different cadence. Start by listing every component the flows will touch: the Mattermost server and its PostgreSQL database, the automation host and its database, and, if you choose n8n in queue mode, the Redis instance and the worker nodes that pull executions from it. Each of these needs compute, storage, backups and patching, and each may be run by your own platform team or by a partner under a fixed-scope agreement. Ask every bidder to price the components separately so you can see which ones you are actually paying for. Note that n8n queue mode also requires the main instance's encryption key to be shared with every worker and webhook processor, so key handling belongs in the cost model as an operational task, not a footnote.
Commercial licensing is where the recurring line items usually change. Mattermost gates SSO, AD/LDAP sync, high availability clustering and compliance export behind paid plans, and its high availability design needs shared file storage on S3, an S3-compatible service or NAS, which is an infrastructure cost on top of the license. On the automation side, n8n's pricing page places SSO and LDAP, Git environments and log streaming in its Business and Enterprise plans, and multi-main high availability is limited to Enterprise self-hosted deployments. Windmill's pricing page lists a free self-hosted Community Edition with limits of 3 workspaces, 50 users and 4 groups, and a self-hosted Enterprise Edition that starts at $120 per month, priced by developers at $20 per month each and operators at $10 per month each plus compute units, according to its pricing page as of October 2026. Confirm these figures on the vendor pages before you budget, since plan terms change. Check licensing as well: n8n's Sustainable Use License restricts commercial use and does not cover files marked .ee.
The rebuild is the largest one-time cost and the easiest to underestimate. Admin time goes into mapping each Workflow Builder form, approval and scheduled message to a flow, recreating slash commands and webhooks, testing failure paths, and documenting owners for each flow. Ask each partner for a written scope that lists the flows in the inventory, the testing approach, and the handover documentation, and ask for separate recurring estimates for upgrades, monitoring and on-call support. Mattermost publishes a server release on the 16th of each month, so plan for regular patching of both the chat server and the automation platform.
What do buyers ask before replacing Workflow Builder?
How much effort does rebuilding Workflow Builder workflows take?
Effort depends mostly on how many workflows exist, how many forms and approval steps each one has, and how many external systems they touch. Start with an inventory of every Workflow Builder workflow, its trigger, its owner and the channels it posts to, then sort them by risk. Simple scheduled messages are quick to recreate as scheduled jobs in an automation tool. Approval chains that write to ticketing or HR systems take longer because each connection needs credentials, error handling and testing. No supplied fact gives a duration for this work, so ask any partner for an estimate built from your own inventory, and confirm that the scope lists each workflow by name.
Can our internal team rebuild the workflows without a partner?
Yes, if your team already runs automation tools and has someone who can operate a PostgreSQL-backed server. Mattermost slash commands and incoming webhooks are documented, and Windmill and n8n both have documented self-hosting paths. What is harder is the operating model: keeping the automation server patched, rotating credentials, and handling errors when a workflow fails at 2 a.m. Teams that choose to do this in-house should decide who owns each workflow before building it. A partner can take on part of the work under a fixed scope, or a retainer can cover upgrades and monitoring after cutover.
What do we need to provide during the engagement?
You need a named owner for each workflow, a few test users who represent each team that submits forms or approvals, and a sandbox server that mirrors the production chat server. The owner signs off on expected behavior, while test users run approvals end to end before anything goes live. The sandbox lets you test webhook payloads and credentials without touching real channels. Confirm early who can grant admin rights on the Mattermost server, who holds the automation tool's administrator account, and who approves network rules between the two systems.
How long does cutover take, and what sets that time?
Cutover time is set by how many workflows must switch on the same day, how much parallel running you want, and whether any workflow depends on data that was not in the chat export. The Slack export does not carry Workflow Builder definitions or integrations, so each workflow is rebuilt and tested rather than imported. Run the old and new workflows side by side for a period long enough to see each approval type complete at least once. No supplied fact gives a cutover duration, so ask for the plan with dated milestones in the written scope.
Can approvals and audit records be kept after leaving Workflow Builder?
Yes, but the approval record must be designed on purpose. Workflow Builder approvals live in Slack, so the audit trail moves with the workflow only if you write each decision to a system you control, such as a database table, a ticketing system or an append-only log. Mattermost's compliance export and retention features are paid editions, so confirm which edition you need before relying on them for legal evidence. Slack's own export limits also matter: on Free, only file links and history within 90 days are visible, so export history before the old workspace is downgraded.
Which Slack integrations break when workflows move?
Anything that depends on a Slack app identity, Slack-specific fields or Slack-hosted state will break. Mattermost's migration documentation states that integrations do not move with a Slack export, so every bot, slash command and app must be inventoried and re-created. Incoming webhook payloads in a Slack-compatible format may work unchanged, but Slack mention forms and some block layouts may not. Ask the Slack admin for the list of installed apps, then test each one in the sandbox before cutover.
Which licenses limit commercial use of n8n and Windmill?
The licenses differ enough that they must be read before choosing a tool. n8n is under the Sustainable Use License, which allows use only for your own internal business purposes or for non-commercial or personal use, and files with .ee in their name or directory need a valid n8n Enterprise License. Windmill's source compiled without the enterprise feature flag is under AGPLv3 and Apache-2.0, but prebuilt Community Edition images include proprietary code that is free for internal use, and managed services or reselling need a commercial license. Mattermost's server source is AGPL v3.0 with a commercial option, and its admin tools are Apache 2.0. Have legal counsel review the exact terms against your intended use.
Does DeployOpen handle the whole Workflow Builder replacement?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For this work, that can include the automation server, its database, the webhook and slash command wiring to your chat server, and the runbooks your team uses afterward. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from the written scope. Ongoing support and upgrades are available as retainers.
How DeployOpen scopes and delivers a Workflow Builder replacement
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Workflow Builder replacement, we start by mapping which forms, approvals and scheduled messages your teams actually run, then build the automation tier and chat hooks in your environment.
How we scope
- Inventory every Workflow Builder workflow, its trigger, owner, approvers and data fields before choosing a tool.
- Agree scope, deliverables and timelines in writing before work starts, since most engagements are fixed-scope.
- Decide with you whether Mattermost Playbooks, slash commands or an automation tool such as n8n or Windmill fits each workflow.
How we build
- Deploy the chat server, automation tier and PostgreSQL database in your cloud account, data center or air-gapped network.
- Rebuild each workflow as a webhook-driven job, then test triggers, approvals and failure paths with sample data.
- Check license terms for each component against your intended use, including any enterprise-only features your workflows depend on.
How we hand over
- Document each workflow, its credentials, encryption key handling and the owner responsible for changes.
- Deliver runbooks for upgrades, backups and restores so your administrators can operate the stack without us.
- Walk your administrators through the workflow inventory and the decisions recorded during scoping.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Review each new server and platform release against your workflows before applying it in production.
- Retest approval and notification flows after chat or automation upgrades, and record the results.
