Allow testing Chat Trigger via its production URL without publishing the workflow

Feature Requests
1

The idea is:

Allow the Chat Trigger node’s chat interface to be tested via its production URL without requiring the entire workflow to be published/activated first — similar to how webhook nodes already separate “test” and “production” modes.

My use case:

I’m building a personal AI assistant workflow with a Chat Trigger as the entry point for voice/dashboard input, feeding into an AI Agent with multiple tools. While developing and iterating on the agent’s logic, I want to test the full chat flow end-to-end using the actual chat interface — not just by manually setting mock data on individual nodes.
Currently, opening the chat interface for an unpublished workflow throws an error saying the workflow isn’t active yet. This forces me to either publish an unfinished, untested workflow just to test it via chat, or manually wire in a temporary node to inject test data in place of the trigger, then rewire everything back afterward.

I think it would be beneficial to add this because:

Both current workarounds are time-consuming and error-prone, especially during iterative development of multi-tool AI Agents where you want to quickly test “does the agent correctly call Tool X given this chat input” without going live. A test mode for the Chat Trigger would let builders test realistic chat-based AI Agent flows safely, and would speed up iteration on chat-driven agent workflows significantly.

Any resources to support this?

N/A — sharing from hands-on experience building an AI Agent workflow with a Chat Trigger entry point.

Are you willing to work on this?

NO

2

Voted – this is a real friction point for iterative agent development.

Workaround that helps in the meantime: keep the Chat Trigger workflow permanently active but minimal – it just calls an Execute Workflow node pointing at a separate “logic” workflow by ID. You iterate freely on the logic workflow (which never needs to be published), and the chat URL stays live the whole time. When you’re ready to ship, you just update the logic workflow – no republish of the trigger needed.

Tradeoff: you manage two workflows instead of one, but the chat URL never breaks and you never have to publish unfinished work just to test a real chat interaction.

Still a workaround, not a fix – the feature you’re describing (a stable test URL tied to the trigger, separate from the activated state) would be the clean solution.