Running a workflow from chat is different from talking to the Assistant. A workflow is a graph you built and deployed; it runs your fixed steps in order. The Assistant is an agent that decides its own next step. This page is about running a workflow you already built. For a side-by-side of the two, see Chat overview.
What you need first
A workflow can only be run from chat once it has a live deployment. Deploying takes a snapshot of the current canvas and marks it as the version that runs.A built workflow
Build it on the visual canvas, or generate it from a prompt with the AI Composer.
A live deployment
Deploy the workflow so chat has a fixed version to run. A workflow with no live deployment cannot be run from chat yet.
You need the owner or admin role in the organization to run a workflow. The older
member role has been retired. If you do not see the option to run, ask an organization owner about your role. See Roles and permissions.Start a run from chat
1
Open a chat and choose the workflow
Start a new chat or open an existing one, then pick the workflow you want to run. Chat loads the workflow’s live deployment, so you always run the deployed version, not whatever is open on the canvas.
2
Type your inputs and send
Your message is the run’s input. Fill in the values the workflow expects, such as a question to research or a customer name to look up, then send. ModuleX writes your input into the conversation as the turn you just sent.
3
Watch the run work
A working indicator appears and the steps stream into the thread as they complete. You do not refresh or wait for a page to reload; updates arrive on their own. See Watch the run.
4
Read the result
When the run finishes, its output renders inline below your input as the reply for that turn. The whole exchange stays in the chat history so you can revisit it. See Read the result.
What happens when you send
When you send a workflow run from chat, ModuleX records the whole exchange as a turn in the conversation so nothing is lost. Three things appear in the thread:Your inputs
What you sent is saved as your message in the thread, so you can always see exactly what the run was asked to do.
A reply placeholder
A reply slot appears right away and shows the run as working, then fills in with steps and the final result as they arrive.
A live stream
ModuleX opens a live connection so step updates flow into that reply without you doing anything.
Watch the run happen
While the run is in progress, the chat shows a working state and updates the reply as each step finishes. You can keep scrolling, read earlier turns, or jump back to the latest activity. If your connection drops mid-run, ModuleX reconnects on its own and replays what you missed, so you do not lose track of where the run got to. A run ends in one of three ways:Finished
The run completed and its result is in the reply. This is the normal, successful ending.
Paused for you
The run reached a step that needs your input or approval before it can continue. See When a run pauses for you.
Stopped or failed
You stopped the run, or a step ran into a problem. The reply shows that it stopped, and you can send it again. See If a run stops or fails.
Stop a run
If a run is taking too long or you sent the wrong inputs, you can stop it from the chat. Stopping is graceful: the step that is already running finishes first, then the run halts and the reply shows it as stopped. You can then send a fresh run with corrected inputs.When a run pauses for you
Some workflows include an interrupt step that pauses the run to ask a human something, such as approving a plan or choosing between options before the run continues. This is called human-in-the-loop. When a run pauses, the chat shows a question or an approval card right inside the thread, and the run waits for you. Answer it in chat and the same run picks up where it left off; you do not start over and you are not charged a second time. If you close the chat and come back later, the open question is still there waiting for your answer.Interrupt step
How a workflow author adds a pause-for-a-human step to a workflow.
Human-in-the-loop resume
The technical detail of how a paused run is resumed once you answer.
Read the result
When the run finishes, its output becomes the reply for that turn, sitting directly below the inputs you sent. The exchange stays in the conversation, so you can scroll back to any earlier run and re-read both the inputs and the result. Because every run is a turn in a thread, you can keep going. Send another message to run the workflow again as the next turn in the same conversation, building up a history of runs you can compare side by side. To organize these conversations later, see History and folders.Private and shared runs
By default, a workflow run you start in a shared chat is visible to your organization, the same as any other chat. You can also keep a run private to yourself. For who can see what, and the difference between personal and organization chats, see Private and org chat.Runs use credits
Running a workflow from chat uses credits. Each run is charged a single run credit, no matter how many steps it has. Pausing and then resuming a run is still one run, so answering an in-chat question does not cost you a second credit. If your organization is out of credits or has hit a usage limit, the run is refused before it starts, and the chat tells you why instead of creating an empty reply. To understand what a credit is and what uses them, see Credits and metering; for the limits that can block a run, see Usage gating and limits.A run that is refused for billing reasons is stopped before anything is created: there is no half-finished reply to clean up. The most common reasons are running out of plan credits, hitting a rate limit, or a wallet that cannot cover overage. See Errors and troubleshooting.
If a run stops or fails
If a step runs into a problem, the run stops and the reply shows that it failed rather than a result. A few things to try:The run says the workflow has no deployment
The run says the workflow has no deployment
The workflow has not been deployed yet, so chat has no fixed version to run. Open the workflow and deploy it, then try again. See Deploy and versions.
A step failed partway through
A step failed partway through
A step hit an error, for example a connected service was unreachable. Send the run again. If it keeps failing, open the workflow in the builder to inspect the failing step. See Error handling and retries.
The run was refused before it started
The run was refused before it started
This usually means a billing or usage limit. Check your plan and credits, then try again. See Usage gating and limits and Errors and troubleshooting.
You do not see an option to run
You do not see an option to run
Running a workflow requires the owner or admin role. Ask an organization owner to check your role. See Roles and permissions.
Run it from code instead
Everything on this page happens through one underlying operation, and you can call it yourself from a script or app. The developer guide covers the exact request, the inputs you send, the live event stream you read to watch the run, and every error you can hit.Run from chat (developer reference)
The technical contract for the same feature: request body, identities returned, the event stream, and errors.
Run via API
Trigger a workflow programmatically, with or without attaching it to a chat thread.
Related
Chat overview
The chat surface: talking to the Assistant, running workflows, and querying knowledge.
Model selection
Choose the model a chat uses, including managed models and your own keys.
Chat with your knowledge
Ask questions answered from your connected knowledge bases.
Workflows and runs
What a workflow is, what a run is, and how they relate.