Save and Organise Workflows

Save and Organise Workflows

Saving a workflow makes it available for later use.

In Feluda, saved flows can be reopened in Studio and run through RunFlows.

Clear names and descriptions also make it easier to understand what each workflow does, what input it expects, and whether it is still ready to use.

This guide explains how to:

• choose a useful workflow name;
• write a clear description;
• save changes;
• find saved flows;
• reopen a flow for editing;
• keep similar flows organised; and
• review workflows over time.

Save early

Save the workflow after the basic structure is in place.

You do not need to wait until the flow is complete.

Saving early helps you:

• confirm that the workflow appears in Feluda;
• reduce the risk of losing work;
• test the saved version;
• return to the flow later; and
• build the workflow in smaller stages.

Save again after important changes.

Give the workflow a clear name

A good name explains the outcome.

Use names such as:

• Summarise Meeting Notes;
• Classify Customer Requests;
• Extract Invoice Details;
• Prepare Weekly Project Update; or
• Create Article Outline.

Avoid names such as:

• Test;
• New Flow;
• Workflow 1;
• Final;
• Final Final; or
• Untitled.

A clear name makes the flow easier to find in Studio and RunFlows.

Name the result, not the technology

Focus the name on what the workflow helps the user do.

Prefer:

Prepare Customer Reply

Instead of:

LLM Workflow with Extract and Output

The user usually needs to know the result, not the internal block list.

Technical details can remain inside the workflow description when they are genuinely useful.

Keep names short but specific

A useful name should be easy to scan.

Compare:

Too broad	Better
Summary	Summarise Meeting Notes
Extract	Extract Contract Dates
Email	Draft Customer Follow-Up
Report	Prepare Weekly Sales Report
Classification	Classify Support Requests

Include the source or result when it helps distinguish the workflow from others.

Use consistent naming

Choose one naming pattern for similar flows.

For example:

• Summarise Meeting Notes;
• Summarise Research Notes;
• Summarise Customer Interviews.

Or:

• Customer Support — Classify Request;
• Customer Support — Draft Reply;
• Customer Support — Prepare Handover.

Consistent names make groups of related workflows easier to recognise.

Add a useful description

A description should explain the workflow in plain language.

Include:

• what the workflow does;
• what input it expects;
• what result it returns; and
• any important requirement.

For example:

Receives meeting notes and returns a short summary, decisions, action
items, owners, deadlines, and unanswered questions.

Another example:

Classifies a customer message as Question, Complaint, Request, or Other,
then prepares a draft response for review.

Keep the description focused on user needs.

Mention important requirements

Include a requirement when the flow depends on something that may not always be available.

For example:

• requires a configured cloud provider;
• requires Ollama to be running;
• uses a tool from a specific Gene;
• needs a Journal connection;
• expects an attached document; or
• needs a person to approve the final result.

This helps users understand what must be ready before they run the flow.

Explain the expected input

A saved workflow is easier to use when the input is clear.

Describe whether the flow expects:

• plain text;
• meeting notes;
• a customer message;
• a contract;
• an article brief;
• a list of items; or
• another supported value.

For example:

Input: one customer message in plain text.

Avoid descriptions such as:

Enter data.

Explain the expected output

Describe what the workflow returns.

For example:

Output: a short summary and a table with Owner, Action, and Deadline.

Or:

Output: one label and a draft reply for human review.

This makes it easier to confirm that the workflow completed successfully.

Save from Studio

In Studio:

1. review the workflow name;
2. review the description;
3. confirm that the main blocks are connected;
4. select Save in the header;
5. complete any requested details; and
6. confirm the save.

The flow is stored locally and becomes available elsewhere in Feluda.

Save again whenever you make an important change.

Confirm that the flow was saved

After saving, check for a confirmation in Studio.

Then open RunFlows and confirm that the flow appears in the local flow list.

If it does not appear:

• return to Studio;
• confirm that the flow has a name;
• save again;
• refresh RunFlows; and
• search for the exact name.

A flow that has not been saved cannot be used as a saved RunFlows item.

Find a workflow in RunFlows

RunFlows shows saved local flows and flows made available through installed Genes.

Use the search bar to find a flow by name.

Available filters may help you browse:

• all flows;
• local flows;
• Gene flows; or
• recent flows.

Clear names make these search and filter options more useful.

Distinguish local and Gene flows

A local flow is a workflow you created and saved in Studio.

A Gene flow is a workflow made available through an installed Gene.

These flows may appear together in RunFlows, but they come from different sources.

Before editing or relying on a flow, confirm whether it is local or Gene-provided.

A Gene flow may depend on tools, prompts, resources, or settings included with that Gene.

Reopen a saved workflow in Studio

Use Studio’s option for loading a previous flow.

Select the saved workflow you want to continue editing.

After it opens:

• review the name;
• confirm the correct flow loaded;
• inspect the canvas;
• check the provider and model settings;
• review tools and connections; and
• save after making changes.

Avoid editing a flow when you are not certain it is the correct version.

Review before changing a saved flow

Before making a major change, understand what the flow currently does.

Check:

• the input;
• the main path;
• decision branches;
• model choices;
• tool actions;
• error paths;
• output blocks; and
• any external requirements.

Run the current version once when possible.

This gives you a clear comparison after the change.

Make one major change at a time

Update one part, then test the workflow.

For example:

• change the instruction;
• change the model;
• add one field;
• add one branch;
• add one tool; or
• change the output format.

Save and test before making the next major change.

This makes it easier to identify which change caused an improvement or a problem.

Use clear block names inside saved flows

Workflow organisation also depends on the canvas.

Name blocks by their purpose.

Use:

• Receive Notes;
• Classify Request;
• Extract Dates;
• Draft Reply;
• Save Journal Entry; or
• Return Review Message.

Avoid:

• LLM 1;
• LLM 2;
• Block 3;
• New Output; or
• Test Step.

Clear block names make future editing faster.

Keep the canvas readable

Arrange the saved workflow so another person can understand the process.

Keep:

• the starting block easy to find;
• the main path in one direction;
• decision routes separated;
• error paths visible;
• outputs at clear endpoints; and
• connection lines as simple as possible.

A saved flow should not require the original builder to explain every line.

Avoid unclear duplicates

You may create a copy when testing a major new direction.

Use names that show the purpose of each version.

For example:

• Summarise Meeting Notes;
• Summarise Meeting Notes — New Format;
• Summarise Meeting Notes — Local Model Test.

Avoid:

• Copy;
• Copy 2;
• Latest;
• New Latest; or
• Final 3.

Once the preferred version is clear, remove or rename old test copies so they do not cause confusion.

Use version notes when needed

When a workflow changes significantly, note the change in its description.

For example:

Updated to return a table of action items and route missing deadlines to
human review.

Or:

Uses a local model for classification and a cloud model for final
analysis.

Keep the description useful for the current workflow.

Do not turn it into a long history of every small edit.

Organise workflows by purpose

Group related workflows through consistent names.

Possible groups include:

• Customer Support;
• Research;
• Content;
• Meetings;
• Documents;
• Security;
• Sales; or
• Internal Reporting.

Example:

• Research — Collect Sources;
• Research — Compare Findings;
• Research — Prepare Brief.

This helps users recognise which flows belong to the same area of work.

Organise workflows by stage

Some workflows form a sequence.

Use names such as:

• Content 1 — Prepare Brief;
• Content 2 — Draft Article;
• Content 3 — Review Article.

Use numbering only when the order is important.

Avoid numbering unrelated flows.

Keep test flows separate

Test flows are useful during development, but they can clutter RunFlows.

Give temporary flows clear names, such as:

• TEST — Summary Prompt;
• TEST — Local Model Comparison; or
• TEST — Journal Tool.

Remove or rename them when testing is complete.

Users should be able to distinguish production-ready flows from experiments.

Mark human-review workflows clearly

When a workflow prepares a result that needs approval, make that clear in the name or description.

For example:

• Draft Customer Reply — Review Required;
• Contract Summary — Human Review;
• Security Finding — Analyst Approval.

This reduces the chance that a draft or recommendation will be treated as a final decision.

Review provider and model dependencies

A saved workflow may stop working when:

• a provider is removed;
• an API key is replaced incorrectly;
• a model is no longer available;
• a local model application is not running; or
• a different model behaves differently.

Review the provider and model settings when reopening an older flow.

Test the workflow again after changing a model.

Review Gene and tool dependencies

A workflow may rely on a tool supplied by a Gene or connection.

Record this requirement in the description when it is important.

Before using an older flow, confirm that:

• the Gene is still installed;
• the tool is available;
• required settings are complete;
• the connection is active; and
• the tool still performs the expected action.

Removing a Gene may make a dependent workflow incomplete.

Review local requirements

A local-model workflow may require:

• Ollama;
• LM Studio;
• a particular downloaded model; or
• another local service.

Add the requirement to the description.

For example:

Requires Ollama and the selected local model to be running.

This helps another user understand why the flow may appear unavailable.

Review privacy before reuse

A saved workflow may send information to several providers, models, or tools.

Before reusing it with sensitive information, check:

• whether each model is local or cloud-based;
• which tools receive information;
• whether any external service is involved;
• where outputs are saved; and
• whether unnecessary details can be removed.

Do not assume an older flow still matches current privacy needs.

Review workflows regularly

A workflow can become outdated even when it still opens.

Review saved flows when:

• the task changes;
• the input format changes;
• a provider changes;
• a model is replaced;
• a Gene is updated or removed;
• a tool changes;
• users need a different output; or
• repeated errors appear.

A short periodic review helps keep the flow useful.

Archive or remove unused flows

Old flows can make it harder to find the correct workflow.

Before removing one, check whether it is:

• used regularly;
• part of a larger process;
• referenced by a schedule;
• dependent on a Gene;
• needed for comparison; or
• the only working version.

When a flow is no longer useful, remove it through the available Feluda controls or move it out of active use when an archive option is available.

Keep only flows that users can identify and trust.

Check schedules before changing a flow

A saved workflow may be used by Schedule Manager.

Before making a major change, check whether the flow runs automatically.

A change to:

• input requirements;
• model selection;
• tool actions;
• output format; or
• maximum runtime

may affect the scheduled result.

Test the updated flow manually before the next scheduled run.

Test after every important save

Saving confirms the workflow is stored.

It does not confirm that the flow works.

After an important change:

1. save the workflow;
2. run a small test;
3. check every affected path;
4. review tools and outputs;
5. open RunFlows;
6. run the saved version; and
7. confirm that the result matches the Studio test.

This confirms that the saved flow is ready for reuse.

A practical naming template

Use this format when helpful:

[Area] — [Action] — [Result or Review State]

Examples:

• Support — Classify Request;
• Support — Draft Reply — Review Required;
• Research — Compare Sources;
• Meetings — Extract Actions;
• Content — Prepare Article Outline.

Not every workflow needs all three parts.

Keep the final name readable.

A practical description template

Use this template:

Purpose:
[What the workflow does.]

Input:
[What the user should provide.]

Output:
[What the workflow returns.]

Requirements:
[Any provider, model, Gene, tool, or review requirement.]

For a short workflow, combine these into one paragraph.

Final workflow organisation checklist

Before treating a saved flow as ready, confirm that:

• the name explains the outcome;
• the description explains the input and output;
• important requirements are listed;
• block names are clear;
• the canvas is readable;
• the flow appears in RunFlows;
• the saved version has been tested;
• related flows follow a consistent naming pattern;
• test copies are clearly marked; and
• outdated flows do not create confusion.

Good organisation makes workflows easier to find, safer to reuse, and simpler to maintain.