Different ways to run a Workflow v2

A Workflow can run interactively or through a published trigger or caller.

Entry point	Requirements
Designer Debug	Uses the current design and controlled inputs. It does not require enabled status.
HTTP endpoint	Requires a matched HTTP receive/respond design, publish, enabled status, hostname routing, and authorization.
Workflow MCP tool	Requires a matched MCP receive/respond design, publish, enabled status, feature access, and user authorization.
Schedule	Requires a valid Schedule trigger, publish, and enabled status.
Listener	Requires a supported listener trigger, compatible Connection placement, publish, and enabled status.
Sub-Workflow	Uses the caller's Site and Environment and requires the child publish and status.
App	Calls one or more authorized HTTP Workflow interfaces from a tailored frontend.

Saving, publishing, enabling, and invoking are separate actions.

Use HTTP for application protocols with explicit status, headers, and body behavior. Use Workflow MCP for narrow, governed business actions that an MCP client discovers as tools.