Slack Modal View Stack Multi-Step Navigation Prompt
Design a multi-step Slack modal flow using views.push, views.update, and the view stack so ops forms can branch, go back, and carry state without losing user input.
- Target user
- Engineers building multi-step Slack modal wizards
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior platform engineer who has built multi-step Slack modal wizards and learned exactly how the view stack, private_metadata, and the push/update/clear actions behave under pressure. I will provide: - The flow ([access request / incident intake / deploy config / etc.]) and its steps - Branching logic (step 3 depends on a choice in step 2) - State that must survive across steps - Whether steps need server validation between them Your job: 1. **Stack mechanics** — explain `views.open` (root), `views.push` (stack a new view, up to 3 deep), `views.update` (replace current view in place), and what the "Back" affordance does to the stack. Be explicit about the 3-view stack limit. 2. **State carrying** — design how state flows across steps. Compare `private_metadata` (string, ~3000 char cap, serialized JSON) versus reconstructing from prior `view.state.values`. Note that pushed views do NOT inherit the parent's state automatically. 3. **Branching** — show how a selection in one step changes the next view (push a different view, or update with different blocks), and how to keep already-entered values when re-rendering. 4. **Validation between steps** — use `response_action: "update"`/`"push"` on submission to advance, and `"errors"` to block and show field errors without losing input. 5. **Final submission** — collapse the accumulated state into the action, then `response_action: "clear"` to close the whole stack. 6. **Pitfalls** — losing state on update, exceeding the stack depth, stale `private_metadata`, and the user closing the modal mid-flow. Output as: (a) stack-operation reference, (b) state-carrying design with private_metadata schema, (c) branching logic, (d) per-step submission handling table, (e) final submit + clear, (f) pitfall checklist. Safety: re-validate the full accumulated state on final submit; intermediate steps are advisory, not trustworthy.
Why this prompt works
Single-screen modals are easy; the moment a flow needs a second step that depends on the first, developers collide with the view stack’s quirks — and the docs scatter views.push, views.update, private_metadata, and response_action across several pages without ever showing how they compose. This prompt assembles them into one coherent design and pins down the constraints that actually bite: the 3-view stack depth and the fact that a pushed view does not inherit its parent’s entered values. Those two facts alone explain most broken multi-step modals.
State carrying is the hard problem, and the prompt makes the model commit to a strategy rather than hand-waving. private_metadata is a serialized string with a size cap, and reconstructing state from prior view.state.values only works while those views remain on the stack. Forcing an explicit private_metadata schema and a comparison of the two approaches yields a design that survives a user clicking “Back,” changing an earlier answer, and resubmitting — the sequence that breaks naive implementations.
By requiring a per-step submission table mapping each step to response_action: "update", "push", "errors", or "clear", the prompt produces a flow that uses Slack’s native navigation correctly instead of fighting it. And the final-submit re-validation requirement keeps the human’s safety instinct intact: intermediate steps are convenience, not trust boundaries, so the accumulated state gets validated once, completely, before anything happens.