Problem

From Zabbix 7.0, the user input for manual host/event actions (frontend scripts) was introduced. The operator can be prompted for one value before execution (string with validation regex, or dropdown), passed to the script via {MANUALINPUT}.

Real operational runbooks often require more than one parameter, and frequently require an operator decision in the middle of execution, based on what the script has already discovered. Current workarounds:

• Packing multiple values into one string (e.g. service;timeout;force) and parsing it in the script - defeats validation and is error-prone for L1/L2 operators.
• Splitting one procedure into several separate scripts the operator must run in the correct order, with no shared context.
• Moving the workflow to an external tool (Rundeck, AWX, ServiceNow), taking the operator out of the Zabbix problem view.

Use cases

1. Service restart with parameters: select service (dropdown), enter graceful timeout (number), tick "force kill if not stopped" (checkbox) - three inputs of different types.
2. Interactive remediation: step 1 lists the largest files/directories on a full filesystem; operator selects which to clean up from a dropdown populated from step 1 output; step 2 performs the cleanup.
3. Network device action: step 1 queries interfaces currently down on a switch; operator picks one and confirms; step 2 bounces it.
4. Confirmation gates: script shows what it is about to change and requires explicit Yes/No before applying.
5. Queue/DB operations: step 1 lists stuck messages/queues (e.g. IBM MQ); operator selects targets and action (purge/move); step 2 executes.

Proposed solution

Part 1 - Multiple named inputs (static form)

• Allow defining N input fields per script, each with:
  • name/key, label
  • type: string, number, dropdown, multi-select, checkbox, password/secret (masked, not logged), date/time
  • default value, validation regex/range, required/optional flag
• Expose each value via a named macro: {MANUALINPUT.<name>}. Keep {MANUALINPUT} for backward compatibility (maps to the first input).
• For Webhook (JavaScript) scripts, additionally pass all inputs as a parameters object.
• Allow dropdown options to contain macros (host/item/user macros) for host-specific choices.

Part 2 - Interactive multi-step execution

• Allow a script to be defined as an ordered list of steps. Each step has its own execution target (server/proxy/agent), type (script, webhook, SSH, etc.) and an optional input form shown before it runs.
• Make step N output available to later steps via {STEP.<N>.OUTPUT} (and as a structured result object for webhooks).
• Dynamic inputs: a step may return structured output (e.g. JSON {"prompt": {...}, "options": [...]}) that the frontend renders as the next step's input form, so dropdown options can be populated from live data gathered by the previous step.
• Frontend step-by-step dialog: output of each step, next prompt, Continue / Abort buttons. Configurable operator-response timeout, after which execution is aborted.
• Optional: conditional branching (next step selected by previous step's exit code or output).

Part 3 - Audit and permissions

• Record each step, input values (secrets masked), operator and timestamps in the audit log and the event's action history.
• Keep the existing permission model (user groups, host groups, required host permissions). Optional per-step "requires confirmation" flag.
• Expose the same capability via API (script.execute with multiple inputs and a step/session context) so external tools can drive the same workflows.

Benefits

• L1/L2 teams can run guided remediation runbooks directly from the problem view, safely and with validation.
• Less reliance on external automation tools for common operational tasks.
• Better auditability than parsing a single concatenated string.
• Brings Zabbix closer to what other monitoring/AIOps platforms offer for operator-driven remediation.

Backward compatibility

Existing single-input scripts and {MANUALINPUT} keep working unchanged; multi-input and multi-step behaviour are opt-in.