Slack Workflow Builder Custom Step Variable Mapping Prompt
Design the input/output variable contract for a custom Workflow Builder step (Steps from Apps) so no-code workflows can wire your app's data without breakage.
- Target user
- Platform engineers exposing app actions to Workflow Builder
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior platform engineer who has exposed app functions to Slack Workflow Builder and learned how brittle a poorly-typed variable contract becomes once non-engineers wire it into live workflows. I will provide: - The action my custom step performs ([create ticket / trigger deploy / look up on-call / etc.]) - The data it needs in and the data it produces out - Who builds the workflows (engineers, support, managers) and how technical they are - My SDK/runtime ([deno-based next-gen platform / Bolt with function listeners]) Your job: 1. **Input variable schema** — define each input: name, type (`text`, `number`, `boolean`, `user_context`, `channel_id`, `slack#/types/user_id`, etc.), required vs optional, and a human-readable description that shows in the Builder UI. Flag which Slack-native types let builders pick values visually versus free-text that invites typos. 2. **Output variable schema** — define outputs the same way, so downstream steps can map them. Explain that outputs must be declared up front; you cannot return ad-hoc keys. 3. **Type-safety boundary** — show where Builder's no-code mapping ends and your handler's validation begins; never trust that a `text` input is well-formed. 4. **Failure semantics** — how to call `complete`/`fail` (or return errors) so the workflow surfaces a clear message rather than hanging, and what a builder sees when your step errors. 5. **Versioning** — how to evolve the variable contract without breaking workflows people have already built (additive-only inputs, never rename/remove an output in place). 6. **Manifest/definition** — the function definition (manifest entry or SDK `DefineFunction`) wiring it all together. Output as: (a) input schema table, (b) output schema table, (c) validation boundary notes, (d) complete/fail handling, (e) versioning policy, (f) function definition code. Safety: validate every input server-side; a no-code builder can wire any upstream value into your step.
Why this prompt works
The thing that breaks Workflow Builder integrations is almost never the code that runs the action — it’s the variable contract between your step and the no-code canvas. Once a support lead has wired your “create ticket” step into a live workflow, renaming an output variable is a breaking change you’ll discover via an angry message, not a failing test. This prompt puts the input/output schema first and demands that every variable carry a type and a human-readable description, because those descriptions are the UI that non-engineers actually see when they map data.
It also forces the AI to name the type-safety boundary explicitly. Workflow Builder’s visual mapping creates a false sense of safety: a builder can wire any upstream text value into your input, and the no-code layer does nothing to guarantee it’s well-formed. By requiring a clear statement of where Builder’s guarantees end and your handler’s validation begins, the prompt produces a design that treats every input as untrusted — which is the only safe posture when arbitrary people are assembling the pipeline.
Finally, the versioning section is what separates a step that survives contact with real users from one that doesn’t. Declaring outputs up front and evolving additively is a discipline the model won’t volunteer unless asked, and this prompt asks. The result is a contract a human can review for backward compatibility before exposing it to a workspace full of citizen automators.