A workspace collects hundreds of workflows and many thousands of runs. Searching only what a page has loaded misses
the older ones, so every search of workflows and runs is done by the server, on all of them, and the result is
paginated like any list: a run from last month is found as easily as one from a minute ago.
| Where |
How |
| the app |
the search box of the Executions page |
| REST v1 |
GET /api/v1/executions?query=… |
| MCP |
list_executions with query |
| The search holds |
It finds |
| words, autumn campaign |
the runs of the workflows whose name contains them, ignoring case |
a run’s ID, run_…, or its GUID |
that run — a child run too: a sub-workflow’s run, an attempt of Repeat Until Accepted |
| a number, 23544 |
the run with that internal ID |
a workflow’s ID, wf_… |
the runs of that workflow |
The list shows the runs that were started directly; the runs a step starts for itself are reached from their
parent’s trace, or found by their ID as above. The text of a name is taken literally: % and _ are ordinary
characters. An ID must be complete — the eight characters the app shows under a run are a label, not a search.
| Where |
How |
| the app |
the search box of the Workflows page — in the folder view it searches every folder, and groups the results under each folder’s path |
| REST v1 |
GET /api/v1/workflows?query=… (with status=all to include drafts and archived ones) |
| MCP |
search_workflows with query |
| The search holds |
It finds |
| words, catalogue |
the workflows whose name, description or a tag contains them, ignoring case |
a workflow’s ID, wf_…, or its GUID |
that workflow |
| a number, 2026 |
the workflow with that internal ID, and the workflows whose name contains it (Campaign 2026) |
Search, then read: search_workflows with the words the person used, then get_workflow on the one that matches;
list_executions with the run_… from a report, then get_execution_trace on it. Never page through a whole list
to find one item.
