What is RunFlows?
RunFlows is the Feluda workspace where you use workflows that have already been created and saved.
Studio is where you design and edit a workflow.
RunFlows is where you select that workflow, provide the requested input, start it, and review the result.
Use RunFlows when you want to repeat a tested process without reopening the Studio canvas each time.
What you can do in RunFlows
RunFlows helps you:
- find saved workflows;
- browse local and Gene-provided flows;
- provide the information a workflow needs;
- start a workflow on demand;
- watch output as the flow runs;
- review intermediate results;
- identify errors;
- repeat a workflow with new input; and
- open related scheduling options when needed.
The available flows depend on what you have created, saved, or installed in Feluda.
RunFlows and Studio are different
Studio and RunFlows support different parts of the workflow journey.
| Area | Main purpose |
|---|---|
| Studio | Build, connect, configure, test, and edit workflows |
| RunFlows | Select saved workflows, provide input, run them, and review results |
A common journey is:
- test the task in Workbench;
- build the process in Studio;
- save and test the workflow;
- open RunFlows;
- provide new input; and
- review the output.
Return to Studio when the workflow itself needs to change.
Stay in RunFlows when you only need to run the existing process again.
Where RunFlows gets its workflows
RunFlows can show different types of flows.
Local flows
A local flow is a workflow you created and saved in Studio.
It is stored with your Feluda setup and becomes available in RunFlows after it has been saved.
Local flows can be reopened in Studio when you need to edit them.
Gene flows
A Gene flow is a workflow included with an installed Gene.
It may depend on:
- tools supplied by the Gene;
- prompts or resources included with the Gene;
- required settings;
- an external account;
- a supported AI provider; or
- another connection.
Read the Gene description and requirements before running one of its flows.
Open RunFlows
Select RunFlows from the Feluda sidebar.
The page shows the available workflow list and the area used to run the selected flow.
If no workflows appear, you may need to:
- create and save a flow in Studio;
- install and sync a Gene that includes a flow;
- refresh the flow list; or
- confirm that you are viewing the correct filter.
Find a workflow
Use the search bar when you know the workflow name.
Enter part or all of the name.
Clear workflow names make this easier.
For example, search for:
Meeting Notes
to find a workflow named:
Summarise Meeting Notes
Select the matching flow card to prepare it for execution.
Browse workflow tabs
RunFlows may provide tabs or filters such as:
- All — shows all available flows;
- Local — shows workflows saved from Studio;
- Genes — shows workflows included with installed Genes; and
- Recent — shows flows you used recently.
These filters help when the available workflow list becomes large.
Confirm the source of the flow before running it, especially when local and Gene-provided flows have similar names.
Review the flow before running it
After selecting a workflow, review the available information.
Check:
- the workflow name;
- its description;
- whether it is local or Gene-provided;
- what input it expects;
- what output it should return;
- whether it requires a particular provider or model;
- whether it uses tools or an external service; and
- whether the result needs human review.
Do not run an unfamiliar workflow with sensitive information before you understand what it does.
Provide the requested input
The workflow may ask for text, a document, a message, or another supported input.
Follow the labels shown in RunFlows.
For example, a meeting-summary flow may request:
Meeting Notes
A customer-support flow may request:
Customer Message
Give the workflow the type of information it was designed to receive.
A flow created for short meeting notes may not handle a full legal document correctly.
Use clear and complete input
The workflow can only work with the information it receives.
Before starting the run, check that the input:
- is complete enough for the task;
- uses the expected language or format;
- does not include unrelated information;
- contains the required names, dates, or fields when available; and
- does not include private details that are unnecessary.
When important information is missing, the workflow should make that gap visible rather than guessing.
Start the workflow
After selecting the flow and providing the input, use the available run control to start it.
Feluda follows the blocks and connections defined in the workflow.
The process may:
- pass the input into an AI model;
- classify or extract information;
- follow a decision path;
- use a tool;
- return an intermediate result; and
- produce one or more final outputs.
Keep Feluda open while an on-demand flow is running.
Watch output in real time
RunFlows can display output while the workflow is executing.
You may see:
- progress updates;
- intermediate results;
- the current stage;
- returned information;
- warnings;
- errors; and
- the final output.
A short workflow may finish quickly.
A longer workflow may take more time when it uses several models, large inputs, image generation, or external tools.
Understand intermediate results
Some workflows use Emit blocks to show useful information before the final result is ready.
For example:
Input
→ Extract Details
→ Emit Extracted Details
→ Prepare Report
→ Output
RunFlows may show the extracted details while the report is still being prepared.
Intermediate output can help you:
- understand progress;
- confirm that an early step worked;
- see how information changes;
- identify the first incorrect result; and
- troubleshoot a later failure.
Intermediate output is not always the final answer.
Review the final output
When the workflow finishes, compare the result with the input and expected outcome.
Check whether it:
- completed the intended task;
- used the correct source information;
- followed the expected format;
- included the required details;
- handled missing information clearly;
- avoided unsupported claims; and
- is suitable for its intended use.
A workflow can complete successfully and still produce a result that needs correction.
Review every output path
A workflow may have more than one possible endpoint.
For example:
Customer Message
→ Question → Draft Answer
→ Complaint → Draft Apology
→ Other → Human Review
Confirm which path the workflow followed.
The final output should match the meaning of the input and the intended branch.
If the wrong path was selected, return to Studio and review the classification or decision step.
Understand successful completion
A completed run usually means the workflow reached an intended endpoint without reporting a blocking error.
It does not automatically mean that:
- the AI response is accurate;
- extracted fields are correct;
- the right branch was selected;
- a tool result is complete;
- an external action affected the intended item; or
- the output is ready to publish or send.
Review the content, not only the completion status.
Review warnings
A warning may mean that the workflow completed but encountered something that deserves attention.
For example:
- a field was missing;
- part of the input was unclear;
- a fallback model was used;
- a tool returned incomplete information;
- the result needs review; or
- an optional step could not complete.
Read warnings before using the final result.
Do not remove a warning from the output unless the underlying issue has been resolved.
Review errors
An error means a step could not complete as expected.
Common causes include:
- an unavailable AI provider;
- a model that cannot be reached;
- a local model application that is not running;
- a missing Gene setting;
- a tool connection problem;
- incomplete input;
- an unsupported file or action;
- a timeout; or
- an incorrect workflow connection.
Read the complete error message.
It often indicates which step failed and what should be checked.
Find the first failing step
A final error may be caused by an earlier problem.
Review the output in order.
Ask:
- Did the workflow receive the input?
- Did the first processing step produce a result?
- Did the correct branch run?
- Did the tool or model return usable information?
- Did the next step receive the expected format?
- Where did the first unexpected result appear?
Correcting the first failing step is usually more effective than changing the final output.
Return to Studio when the flow needs changes
RunFlows is for execution, not full workflow editing.
Return to Studio when you need to:
- change a block instruction;
- choose another model;
- add or remove a block;
- repair a connection;
- change a label or extraction field;
- add an error path;
- change the output format; or
- update the workflow description.
Save and test the updated flow before running it again with important information.
Repeat a workflow with new input
A main benefit of RunFlows is reuse.
After one run finishes, you can select the same workflow and provide new input.
The workflow follows the same saved process each time.
This is useful for repeated tasks such as:
- summarising meeting notes;
- classifying customer requests;
- extracting document fields;
- preparing project updates;
- reviewing reports;
- drafting structured content; or
- organising research material.
Review each important result, even when earlier runs were successful.
Use recent flows
The Recent filter can help you return to workflows used most recently.
This is helpful when you repeatedly run the same small group of flows.
Confirm the selected workflow name before entering new information.
Similar names can lead to the wrong process being used.
Keep the workflow list organised
RunFlows becomes easier to use when workflow names are clear.
Use names such as:
- Meetings — Summarise Notes;
- Support — Classify Request;
- Support — Draft Reply — Review Required;
- Research — Compare Sources; or
- Documents — Extract Contract Dates.
Mark temporary test flows clearly.
Remove or rename outdated duplicates so users do not need to guess which version is current.
Run a Gene flow
Before using a Gene-provided flow:
- read the Gene description;
- review what the flow is designed to do;
- confirm required settings;
- check whether an external service is involved;
- confirm the required provider or model is available;
- use non-sensitive test input; and
- review the complete output.
A Gene flow can save setup time, but it still needs to be understood and tested.
Confirm tool actions
Some workflows use tools to retrieve, create, change, or save information.
When a tool performs a read action, confirm that the result came from the intended source.
When a tool performs a write action, check the destination.
For example:
- open the Journal and review the new entry;
- check the expected file;
- inspect the connected service;
- confirm the correct record was changed; or
- verify that the expected result was saved.
Do not rely only on the workflow saying that the action succeeded.
Avoid duplicate write actions
If a run times out or reports an unclear error during a write action, check the destination before running it again.
Repeating the workflow could create:
- duplicate Journal entries;
- duplicate files;
- repeated updates;
- repeated messages; or
- another unintended action.
Confirm whether the earlier run completed before retrying.
Use local models in RunFlows
A saved flow can use a local model through a compatible provider such as Ollama or LM Studio.
Before running it:
- open the local model application;
- start its model service;
- load the required model when needed;
- confirm that the model is still available in Feluda; and
- keep the application running during the flow.
If the local provider is unavailable, the step that depends on it cannot complete.
Use cloud models in RunFlows
A cloud-model workflow needs:
- an internet connection;
- a configured provider;
- an active API key;
- access to the selected model; and
- a provider account that can complete the request.
Provider requirements are managed by the provider.
If a cloud step fails, test the same model in Workbench to confirm whether the problem is the provider or the workflow.
Understand privacy before running
Review the complete flow before using sensitive information.
Check:
- which providers and models receive the input;
- whether each model is local or cloud-based;
- which tools are used;
- whether an external service receives information;
- whether outputs are saved; and
- whether unnecessary details can be removed.
A workflow can combine local and online steps.
Selecting one local model does not make the complete flow local.
Use sample information first
When running a workflow for the first time, use a realistic but non-sensitive example.
Confirm that:
- the expected path is followed;
- the model returns the required format;
- tools use the correct destination;
- warnings are understandable;
- errors remain visible; and
- the final output can be reviewed.
Move to real information only after the test succeeds.
Stop and review unexpected behaviour
Stop relying on the output when:
- the workflow follows the wrong path;
- important information disappears;
- the model adds unsupported claims;
- a tool affects the wrong destination;
- an error is hidden behind normal output;
- the result cannot be checked; or
- the workflow behaves differently across similar inputs.
Return to Studio and correct the process.
Do not continue repeating a flow that you do not understand.
RunFlows and Schedule Manager
RunFlows is for starting a workflow on demand.
Schedule Manager is for arranging a supported workflow to run at a selected time or on a recurring schedule.
Manual RunFlows testing should come first.
Before scheduling a workflow:
- run it several times manually;
- test normal and unexpected input;
- confirm model and tool requirements;
- make errors visible;
- review write actions;
- define where results are stored; and
- decide who checks scheduled output.
A workflow that is unreliable when run manually is not ready to be scheduled.
When RunFlows is the right place
Use RunFlows when:
- the workflow is already built;
- the flow has been saved;
- you want to provide new input;
- you want to repeat a known process;
- you need to review live output; or
- you are testing the saved version outside Studio.
Use Studio instead when the process itself needs to change.
Use Workbench when the task is still exploratory or needs conversation.
A practical first RunFlows session
For your first run:
- open RunFlows;
- select the Local filter;
- find the workflow you created in Studio;
- select its flow card;
- read the description;
- enter non-sensitive sample input;
- start the workflow;
- watch the output;
- review the final result; and
- return to Studio if anything needs to change.
This confirms that the saved workflow is ready to be reused.
Final review checklist
Before accepting a RunFlows result, confirm that:
- the correct workflow was selected;
- the input was complete;
- the expected path was followed;
- intermediate results were reasonable;
- no warning was ignored;
- every required step completed;
- tool actions were confirmed;
- the final output matches the source;
- unsupported details were not added; and
- human approval is included where needed.
RunFlows makes a saved workflow easy to reuse.
Careful review makes that reuse dependable.