Subworkflow and Slack: Centralized Notification Service Template

Build one reusable Spojit workflow that takes a channel and a message and posts to Slack, so every other workflow calls a single notification path instead of repeating Slack logic.

What It Builds

This template builds a small child workflow with a Manual trigger whose input is a channel and a message. A Connector node on the slack connector posts that message to the named channel, and a Response node returns the result. Any parent workflow then drops in a Subworkflow node, passes {{ channel }} and {{ message }}, and gets a Slack post without re-wiring Slack each time. Change the notification logic once and every caller picks it up immediately.

The Prompt

Paste this into Miraxa, the intelligent layer across your automation, and it builds the workflow and connects the tools for you:

Build a reusable workflow with a Manual trigger that accepts a channel name and a message. Add a Connector node on the slack connector in Direct mode that sends the message to that channel, then add a Response node that returns whether the post succeeded and the channel it went to. Name the workflow "Slack Notification Service" so other workflows can call it as a subworkflow.

Connectors Used

  • slack - posts the message with the send-message tool in Direct mode (deterministic, no AI cost). Trigger: Manual, since the child runs only when a parent invokes it.
  • code - optional, for shaping the message text (for example with execute-javascript) before it is sent, so callers can pass raw fields and let the service format them.

Customize It

In the prompt, change the input fields to match what your callers send: add a title or urgency field, or accept a Slack thread reference so replies land in a thread. You can also have the child look up a channel by name with list-channels, or use a code step to prefix the message with an emoji per urgency level. To call it from a parent, add a Subworkflow node, pick Slack Notification Service under Workflow, and map channel and message in the Input field.

Tips

  • Keep the Slack Connector node in Direct mode: a single known send-message call is predictable and spends no AI credits.
  • The child runs through its own trigger and nodes, then returns its final output to the parent, which pauses meanwhile. Add the Response node so callers can branch on success or failure.
  • Edit the child once and every parent inherits the change instantly, so put shared formatting (timestamps, mention syntax) inside the service rather than in each caller.

Common Pitfalls

  • The Slack connection must be authorized for the workspace and able to post to the target channel. A private channel the connection has not joined will reject send-message.
  • Avoid deep nesting: calling a subworkflow that calls another subworkflow that posts to Slack is harder to trace. Keep the notification service one level deep.
  • Pass channel values consistently. Decide whether callers send a channel name or an ID and stick to it, or add a lookup step inside the service so both work.

Related

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.