Run a Workflow
RunFlows is where you use workflows that have already been built and saved.
This guide will help you:
- find the correct workflow;
- review what it expects;
- choose how to start it;
- provide its input;
- monitor the run;
- review the final output; and
- correct common problems.
Test a workflow with non-sensitive sample information before using it for important work.
Before you begin
Make sure that:
- Feluda is installed and open;
- the workflow has been saved in Studio or added through a Gene;
- any required AI provider is connected;
- any required local model application is running;
- required Gene or tool settings are complete; and
- you understand what input the workflow expects.
A workflow may appear in RunFlows even when one of its models, tools, or connections is unavailable.
Review its requirements before starting the run.
Step 1: Open RunFlows
Select RunFlows from the Feluda sidebar.
RunFlows shows the workflows currently available in your setup.
These may include:
- local workflows created in Studio; and
- workflows included with installed Genes.
The page also contains the area where you start a flow and monitor its output.
Step 2: Find the workflow
Use the search bar when you know the workflow name.
You may also browse available views such as:
- All;
- Local;
- Genes; and
- Recent.
Select Local when you want a workflow you created in Studio.
Select Genes when you want a workflow included with an installed Gene.
The Recent view is useful when you regularly use the same group of flows.
Step 3: Select the correct flow
Select the workflow card you want to run.
Before continuing, confirm:
- the workflow name;
- whether it is local or Gene-provided;
- the description;
- the expected input;
- the expected output;
- any model or provider requirement;
- any required tool or Gene setting; and
- whether the result needs human review.
Similar workflow names can cause mistakes.
Confirm the full name before adding information.
Step 4: Start the flow
Use the Run button on the workflow card or select the flow and choose Run Flow.
Feluda may show different ways to start the workflow, depending on how it was designed.
Choose the start option that matches the flow.
A workflow beginning with an Input block normally asks you to provide a starting message or other information.
Step 5: Provide the starting input
Enter the information requested by the workflow.
For example, a summary workflow may ask for:
Meeting Notes
You could provide:
The team approved the revised homepage.
Sam will prepare the final design files by Friday.
Mia will confirm the customer interview dates.
The launch date has not been decided.
Read the input label carefully.
A workflow designed for meeting notes may not handle an invoice, contract, or unrelated message correctly.
Provide complete input
Before starting the run, check that the input:
- contains the information required for the task;
- is in a format the workflow can understand;
- does not include unrelated content;
- does not contain unnecessary sensitive details; and
- is not too large for the selected model or process.
Missing information should remain visible in the result.
The workflow should not be expected to invent names, dates, amounts, or other details that were not provided.
Step 6: Start the execution
Confirm the input and start the workflow.
Feluda now follows the blocks and connections saved in the flow.
Depending on its design, the workflow may:
- send information to an AI model;
- classify the input;
- extract structured fields;
- follow a decision path;
- use a tool;
- show intermediate output;
- create an image; or
- return one or more final results.
Keep Feluda open while the on-demand run is active.
Step 7: Watch the status
RunFlows shows the current state of the workflow.
Common states may include:
| Status | What it means |
|---|---|
| Running | The workflow is still processing |
| Completed | The workflow reached an intended endpoint |
| Failed | A step could not complete |
| Stopped | The run ended before normal completion |
The exact wording may vary.
A completed status confirms that the workflow finished without a blocking error. It does not confirm that every detail in the output is correct.
Watch output in real time
The output panel can show information as the blocks execute.
You may see:
- the current output;
- progress messages;
- intermediate results;
- warnings;
- error details; and
- the final result.
A short workflow may complete quickly.
A longer workflow may take more time when it uses:
- several AI blocks;
- a large input;
- a local model;
- image generation;
- external tools; or
- a slow connected service.
Allow the run to finish before deciding that no result was returned.
Review intermediate output
Some workflows include Emit blocks that show a result before the process ends.
For example:
Input
→ Extract Details
→ Emit Extracted Details
→ Prepare Report
→ Output
Intermediate output can help you confirm that:
- the input was received;
- an early step produced the expected information;
- the correct path was followed; and
- the next step received usable content.
Do not confuse intermediate output with the final result.
Step 8: Review the final result
When the flow completes, compare the output with the original input.
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 clear and confident result can still contain mistakes.
Review important names, dates, amounts, decisions, and actions against the source.
Confirm the path that ran
A workflow may have several branches.
For example:
Customer Message
→ Question → Draft Answer
→ Complaint → Draft Apology
→ Other → Human Review
Confirm that the output matches the path the input should have followed.
If the workflow selected the wrong path, return to Studio and review the classification labels, Expression rule, or branch connections.
Confirm tool actions
Some flows use tools to retrieve, create, update, or save information.
For a read action, confirm that:
- the intended source was used;
- the returned information is complete;
- the result is current enough; and
- the AI interpreted it correctly.
For a write action, check the destination.
For example:
- open the Journal and review the new entry;
- open the expected file;
- check the connected service;
- confirm that the correct item was changed; or
- verify that the result was saved.
Do not rely only on a success message.
Run more than one workflow
Feluda can run multiple workflows at the same time.
Each run has its own output and status.
Use the active-flow area to move between running workflows.
When running several flows:
- confirm which input belongs to each run;
- use clear workflow names;
- review every output separately;
- avoid repeating write actions; and
- do not assume one completed run means the others also completed.
Begin with one active flow while learning RunFlows.
Review completed runs
Completed runs may remain available in the RunFlows sidebar for review.
Use them to:
- return to a recent result;
- compare two runs;
- check whether a flow completed;
- review an earlier error; or
- confirm which workflow was used.
Do not treat the run list as the only permanent place for important results.
Save important information in the intended destination when the workflow is designed to do so.
Pin an important run
When the option is available, pin a run that you need to keep visible.
This can help when:
- several workflows are active;
- a long run is still processing;
- you need to compare outputs; or
- an important result needs further review.
Unpin it when it no longer needs special attention.
Repeat the workflow
After reviewing one result, you can run the same workflow again with new input.
The saved process remains the same.
This is useful for repeated tasks such as:
- summarising new meeting notes;
- classifying support requests;
- extracting fields from documents;
- preparing regular updates;
- reviewing reports; or
- creating content from new briefs.
Review each important output.
A workflow that worked correctly once can still receive unusual or incomplete input later.
If the workflow does not appear
Check that:
- the flow was saved in Studio;
- it has a clear name;
- you are viewing the Local or All filter;
- a Gene flow has been installed and synced;
- RunFlows has been refreshed; and
- the workflow was not removed or renamed.
Return to Studio and save a local flow again when needed.
If Run Flow is unavailable
The run option may be unavailable when:
- the flow is not fully selected;
- a required starting block is missing;
- the workflow has not been saved correctly;
- the flow contains an invalid connection; or
- a required setup step is incomplete.
Open the flow in Studio and review its validation and starting path.
If the workflow asks for the wrong input
Confirm that you selected the correct workflow.
If the correct flow uses an unclear input label, return to Studio and rename the Input block or update the workflow description.
The starting input should tell the user what information to provide.
If the run remains active for too long
A long run may be caused by:
- a large local model;
- limited computer memory;
- a long input;
- several AI steps;
- image generation;
- an unavailable external service; or
- a request that has timed out.
Review the visible status and output.
Avoid starting the same workflow repeatedly while the first run may still be active.
For a local model, confirm that its application and model service are still running.
If the workflow fails
Read the complete error message.
Common causes include:
- an unavailable provider;
- an inaccessible model;
- an inactive local model service;
- an incomplete Gene setting;
- a tool connection problem;
- unsupported input;
- a timeout;
- a missing block configuration; or
- an incorrect connection.
Identify the first step that did not produce the expected result.
Correct that step in Studio or in the relevant provider, Gene, or connection setup.
If the output is empty
Check whether:
- the workflow received the input;
- the first block completed;
- the correct path was followed;
- an Output block exists at the end of the path;
- an earlier step returned an empty value; and
- the run reported a warning or error.
Return to Studio and trace the workflow from Input to Output.
If the output is incorrect
An incorrect result may be caused by:
- unclear input;
- a weak instruction;
- the wrong model;
- an incorrect label;
- a missing extraction rule;
- information lost between blocks;
- the wrong branch; or
- an unsuitable tool result.
Find the earliest incorrect intermediate result.
Improve one block or connection at a time, then run the same example again.
Avoid duplicate actions after an error
When a workflow uses a write tool and the run reports a timeout or unclear failure, check the destination before retrying.
The first run may have completed the action even when the confirmation was delayed.
Repeating it could create:
- duplicate Journal entries;
- duplicate files;
- repeated messages;
- repeated updates; or
- another unintended result.
Confirm what happened before starting another run.
Run a workflow with a local model
Before starting a flow that uses Ollama, LM Studio, or another compatible local provider:
- open the local model application;
- start its model service;
- load the required model when necessary;
- confirm the model appears in Feluda; and
- keep the application running.
A workflow step cannot use a local model when its service is unavailable.
Run a workflow with a cloud model
A cloud-model flow normally needs:
- an internet connection;
- a configured provider;
- an active API key;
- access to the selected model; and
- an account that can complete the request.
If the cloud model fails, test it in Workbench.
This helps you determine whether the issue is the provider connection or the workflow.
Review privacy before running
Check the complete workflow before entering confidential information.
Confirm:
- which models receive the input;
- whether each model is local or cloud-based;
- which tools are used;
- whether an external service receives information;
- where results are returned or saved; and
- whether unnecessary details can be removed.
A workflow may combine local and online steps.
Review every step instead of assuming the complete process follows the privacy level of one model.
Keep human review where needed
A workflow can prepare a result without making the final decision.
Human review is especially important when the output affects:
- customers;
- employees;
- money;
- contracts;
- legal rights;
- health;
- safety;
- security; or
- access to important services.
Review drafts, recommendations, extracted details, and write actions before they are treated as final.
Run manually before scheduling
RunFlows is the best place to confirm that a workflow works on demand.
Before creating a recurring schedule:
- run the workflow several times;
- test normal and unusual input;
- confirm every branch;
- review model and tool requirements;
- make errors visible;
- check write actions; and
- decide who reviews the result.
A workflow that is unreliable during a manual run is not ready for a schedule.
A practical first run
Use this process for your first workflow execution:
- Open RunFlows.
- Select Local.
- Find the workflow saved from Studio.
- Review its name and description.
- Select Run Flow.
- Choose the appropriate start option.
- Enter non-sensitive sample input.
- Start the workflow.
- Watch its status and output.
- Review the final result against the source.
- Confirm any tool action at its destination.
- Return to Studio when the process needs to change.
Final run checklist
Before accepting the result, confirm that:
- the correct workflow was selected;
- its requirements were available;
- the input matched the expected type;
- the correct 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; and
- human approval is included where needed.
Running a flow starts the process.
Reviewing the run confirms whether the result is ready to use.