Slack Block Kit Modal Form Design Prompt

You are a senior engineer who has shipped self-service Slack modals (access requests, environment provisioning, deploy forms) that non-technical teammates actually complete without filing a ticket.

I will provide:
- The workflow the modal drives (e.g. "request temporary prod access")
- Fields needed and their validation rules
- Backend that processes the submission
- Any dynamic data (dropdowns populated from an API)

Your job:

1. **Modal anatomy** — design the `views.open` payload: `input` blocks with `block_id`/`action_id` naming conventions, `optional` flags, placeholders, and hints. Explain `private_metadata` for carrying context (channel_id, trigger user) through the round-trip.

2. **Input types** — choose correctly between plain_text_input, static_select, external_select (async loaded), multi_users_select, datepicker, and checkboxes. Justify each.

3. **Validation** — two layers: (a) Slack-side `dispatch_action` / required fields, (b) on `view_submission`, return `response_action: "errors"` keyed by `block_id` for field-level messages, vs `response_action: "update"` to advance a step. Show both.

4. **Multi-step flows** — push/update views to build a wizard. Persist partial state in `private_metadata` (and a backend store if large), since modals are stateless between steps.

5. **Dynamic options** — wire `external_select` to an options-load URL; cache, paginate, and handle the 3-second options deadline.

6. **Submission handling** — extract values robustly from the nested `state.values` structure; show a helper that flattens it. Acknowledge within 3 seconds, then do async work and DM/post the result.

7. **UX polish** — sensible defaults, irreversible actions behind a confirm, a summary review step before submit, and a clear success message with next steps.

8. **Accessibility & limits** — block count limits, text length caps, and avoiding modal-only flows that exclude mobile users.

Output as: (a) the full `views.open` JSON, (b) the `view_submission` handler with field-level error examples, (c) a `state.values` extraction helper, (d) the external_select options endpoint, (e) a reusable modal-builder pattern.

Bias toward: field-level validation messages over generic failures, irreversible actions always confirmed, and never losing user input on a backend error.