Workflow Executions
A workflow execution is one run of a workflow. It holds its own copy of the workflow's name, description, tasks and tags, so a run's history stays faithful to what actually ran even after the workflow it came from is edited or deleted.
Open Workflow Executions in the admin sidebar to browse them. Unlike the other sections, a run is a history rather than a record to edit, so there is no edit form — its screens either show the run or let you join it. Its Tags column and field are read-only for the same reason — see Workflow execution and approval tags.
| Screen | How to get there | What it shows |
|---|---|---|
| Workflow Executions list | Admin sidebar → Workflow Executions | Every run, with its status, and per-row actions |
| Workflow session | The Open Workflow Session action on a row | The chat the run happens in — join it, watch it, answer it |
| Workflow Tasks | A row's tasks link | The run's tasks and their statuses, read-only, as a Table or a Graph |
| Tool Invocations | The run detail header | The MCP tool calls the run made, and how each was decided |
Mocked marks a run that stubbed any of its tools with a tool mock.
The Columns menu offers two more columns that start hidden. Workflow shows the run's parent workflow under its current name and links to it — each row's own name is a snapshot fixed when the run started, so this column is how you see what that workflow is called today. Draft shows a checkmark for a test run — one started from a workflow that was still draft, or from the unpublished edits of a modified one. Either way it exercised a design nobody had approved, so it is left out of the operations metrics; the column works as a Yes/No filter to hide them.
A run's detail page shows its Version: the published version of the workflow it copied its tasks from, such as v3, or — for a test run, which ran a design no version recorded. See Version history and rolling back.
Run status
A run starts running and settles once it has at least one task and every task has reached a terminal state — completed, failed or skipped. A run whose tasks include a failure ends failed. The finish time is stamped at that moment and is never moved by a later edit, and a run with no tasks at all stays running. These are the numbers the operations metrics count.
While an unfinished run has nothing to do but wait for a time — a task asked to wait, its session shows Scheduled until …, and every other session is idle or done — the run shows scheduled instead of running. It goes back to running as soon as a session resumes, whether the time has come or someone sent it a message. The operations metrics count a scheduled run as active, just like a running one.
When a task fails, any task still waiting on it — directly or down the chain — is set to skipped, since it can no longer run; that is what lets the run settle rather than hang on a task that will never start. Tasks on branches that do not depend on the failed one are unaffected, so a run can still be running for a while after a failure until they too finish.
The workflow session screen
The workflow session is the chat one run happens in. It opens with the run's kickoff message and the agent already working — the run starts as soon as it is created, whether or not anyone opens this screen.
Who shares it
A run's chat is shared by its participants, not private to whoever started it:
| Who | What they get |
|---|---|
| The initiator who started the run | The full conversation, and the chat input |
| A designated approver of one of its approvals | The same conversation and state — approving resumes the original run rather than starting a fresh, empty one. Their approval is the one thing that is theirs to act on: an input form the agent renders for any other step — or a confirmation an MCP server asks for — is read-only for them, with a "Waiting for the initiator to respond." note beneath it |
| An Admin of the tenant | Read-only visibility |
| Anyone else | No access |
When an approval is addressed to a group, every member holding approver is a participant, so the chat follows the group's membership: adding someone to an approver group opens every run that group has been asked to approve, and removing them closes it again. That is the direct consequence of "any member can settle it" — deciding is what the chat access exists to enable. A member who does not hold approver gets nothing from the membership.
Sender avatars
Because several people post into one chat — the applicant, the approvers, and the agent — every message carries a sender avatar. Hovering it reveals the sender's name; the agent's badge reveals the workflow name. Clicking a button inside a rendered interactive surface is attributed the same way, showing the acting user's avatar beside that surface once the click resolves.
The task timeline
A collapsible task timeline runs down the left edge: the run's tasks in order, each with a numbered, status-coloured badge, the in-progress one highlighted. The chat wraps each run of consecutive messages belonging to the same task in a task group — a status-coloured left rail with a numbered heading matching the timeline badge — so the boundary of each task is obvious at a glance.
The two are linked both ways:
- Scrolling the chat highlights the task at the top of the viewport in the timeline.
- Hovering either a timeline entry or a chat group highlights its counterpart.
- Clicking a timeline entry scrolls the chat to that task's group.
Live updates
Every participant watching the run sees each reply as it is written — whoever's message started it, and also the turns A2Flow runs on its own, such as the kickoff, the resumption after an approval, and the resumption of a session that was waiting for a time. The view follows new messages to the bottom only when you are already scrolled near the bottom.
A message you send waits for the agent: while it is still working on a turn, the message is refused and you can send it again once the reply has finished. A session waiting for an approval takes no messages, because the approval's decision is what moves it on. A question you send then goes to a consultation instead.
The design session is a shared chat too, with the same avatars. It is shared by the tenant's Developers rather than by a run's participants, and it refreshes itself every few seconds rather than showing other people's replies as they are written.
Branch sessions
When the run's task graph branches, A2Flow may split the run across several sessions so the branches move forward together — see Parallel branches. A row of tabs then appears under the breadcrumbs, one per session, each labelled with its status:
| Tab | What it is |
|---|---|
| Main | The session the run started in. It works the joins and the tasks that follow a finished branch |
| Branch 1, Branch 2, … | A branch session, forked when a branch became ready while its session was busy |
| Consultation 1, … | A consultation, opened by a question asked while a session waited for an approval |
| Status | Meaning |
|---|---|
| Queued | A turn is about to start |
| Running | The agent is working |
| Waiting for input | An input form is waiting for an answer |
| Waiting for approval | An approval this session requested is undecided |
| Waiting for initiator | The next task will ask the initiator questions while it runs, so it waits for them to resume it from the chat |
| Scheduled until … | A task must wait for a time; the session resumes on its own at the time shown. A message sent to it resumes it early |
| Idle | Nothing to do right now; the session waits for its next task |
| Done | The session finished its work. A finished branch leaves a summary for the main session |
| Error | The last turn failed |
Click a tab to open that session's chat; the view follows the selected session, and the URL keeps it, so a link to the page opens the same tab. A run that never branches and has no consultation shows no tabs.
Consultations
A session waiting for an approval takes no messages, but the request may still raise questions, such as what the instance will cost or why this target was chosen. While the session waits, a note above the chat input says that a question goes to a consultation.
- Type the question in the waiting session's chat and send it.
- A Consultation tab opens with your question, and the agent answers there. It starts from everything the waiting session knew up to the approval request, and it can also read the knowledge bases linked to the workflow. It cannot use the MCP servers' tools, so a question that needs a fresh look at the target system has to wait until the run continues.
- Keep asking in that tab. Everyone who shares the chat can write there, so the approver and the person who started the run can also discuss the request with each other. Each message shows who sent it.
- Decide the approval as usual. The decision closes the consultation: its tab changes to Done and accepts no more messages.
| A consultation | |
|---|---|
| Can | Answer from the request's context, the linked knowledge bases, the run's tasks and approvals, and the files in the session |
| Cannot | Use any MCP server tool, change a task, request an approval, schedule a wait, or add a file |
| Leaves behind | Nothing in the run. The waiting session never sees what was said there; the conversation stays readable in its tab |
Another question asked before the same approval is decided goes to the same consultation.
Suggested replies
When the agent stops to wait for you — it asked a question, wants a value, or needs a go-ahead — a row of suggested replies appears above the chat input: a few short answers it expects, such as Yes, go ahead or Skip this step.
| Clicking one | Puts that text into the chat input. Nothing is sent — edit it, or send it as it is |
| While the agent is working | The row is hidden; it comes back with the agent's next question |
| After you reply | The row goes away, and the next question brings its own suggestions |
| After a reload | The same row is there, for every participant who can send |
The suggestions are the agent's guess at what you would type, not a menu of the only allowed answers — a question with a fixed set of answers is asked as a choice inside the message instead. The row is a workflow session feature; the design session has none.
Confirmations from an MCP server
Some MCP servers stop in the middle of a tool call to ask a person something before they go on — the Azure MCP Server, for one, asks for consent before every operation on a Key Vault secret. A tool like that is marked as asking the initiator in the workflow's design: tell the design agent which task's tool asks, when you generate the workflow or in its design session. A tool that is not marked is not allowed to ask, and its call fails instead of waiting.
A task that uses a marked tool waits for the run's initiator before it starts, so they are there when the questions come:
- When the run reaches the task, its session shows Waiting for initiator, and the initiator gets an
elicitation_requestnotification. Nothing waits on a clock in the meantime. - The initiator opens the run's chat. Above the chat input, a note names the task, with a Resume button. Others see only that the run waits for the initiator.
- Resume sends a message in the initiator's name, and the task starts. Typing any message of their own does the same.
- Each question appears in the chat as a card titled "server asks for confirmation", naming the tool that is waiting on it, with a small form underneath.
| Who answers | The run's initiator only. Approvers and Admins see the question with "Waiting for the initiator to respond." beneath it |
| Accept | Sends the form's values. What they mean is up to the server — the Azure MCP Server's form is a choice between Approve and Reject |
| Decline | Refuses to answer |
| Cancel | Dismisses the question without choosing |
| While it waits | The agent's turn is still running, so the chat input stays disabled |
| If nobody answers | The question expires — after 15 minutes unless the deployment says otherwise — and the server is told it was dismissed |
The card belongs to the turn that asked. Once that turn has ended, the tool call's own line in the chat is what records the outcome.
Files in the session
A workflow session carries files as well as messages. Attach one with the paperclip button beside the chat input, or drop it anywhere on the input box: each file appears as a chip above the box, and the × on a chip removes it. Nothing is sent until you send the message, so removing a chip simply drops that file — it never reaches the run.
The message you send names what went with it, so the transcript still shows the attachment after a reload. The agent is told about the files separately, by the server, and can:
| It can | It cannot |
|---|---|
| List the session's files | Change a file anyone attached |
| Read one, as long as it is text | Delete a file |
| Add a new file of its own | Reach another run's files |
A file the agent writes appears in the chat as a card with a Download button. Because the agent only ever adds, a file it writes under a name already in the session is stored under a numbered variant (report (2).csv) instead of replacing what is there — the card names the file as it was actually stored.
Reading is limited to text. A spreadsheet, an image or an archive is stored and downloaded intact, but the agent cannot read it; give it a text export if it needs the contents.
| Who can attach | The run's initiator and its designated approvers — the same people who can drive the run. An Admin who is only watching cannot attach |
| Who can download | Everyone who can read the chat, Admins included |
| How long they last | As long as the run. Deleting the run deletes its files |
| Size limits | Set per deployment — see Configuration |
Files cannot be removed one at a time once sent, so a session's files go when the run does.
Workflow Tasks
The run's tasks are read-only here: the templates are edited on the workflow, and a run's statuses are advanced by the execution agent and the approval flow.
Each task carries a status — pending, in_progress, completed, failed or skipped — and its dependencies. A Table / Graph toggle switches between the list and the dependency graph, which stacks the tasks in a single vertical column in dependency order, prerequisites above the tasks that depend on them, each branching rightward into the MCP servers it binds tools from and then into the individual tools. The graph pans, zooms and fits; it does not edit.
Tool Invocations
This page lists the MCP tool calls made during the run and what the gateway decided about each one: allowed calls that went upstream, and denied ones a rule vetoed — with the tool, the server, the denial reason, and the tool certificate presented. Arguments appear only as a digest; the raw values are never stored.
Calls to a mocked tool are absent here whichever way they went. The gateway checks a mocked call like any other, but a call that was always going to be answered from a stored response reaches no server, so neither its approval nor its refusal belongs in this record. The run's chat transcript is where a stubbed call is inspected.
Deleting a run
A row's Delete action removes the run after a confirmation prompt: the record, its tasks, and its workflow session all go with it.