Schedule a Workflow

Schedule a Workflow

Schedule Manager lets you arrange for a saved Feluda workflow to run at a selected time.

You can create a one-time schedule or repeat the workflow on a daily, weekday, weekly, or monthly pattern.

This guide explains how to:

• choose a tested workflow;
• create a schedule;
• select the frequency;
• set the time and timezone;
• provide the starting input;
• choose a maximum runtime;
• review the next planned run; and
• confirm that the schedule is ready.

Schedule only workflows that have already been tested manually in RunFlows.

Before you begin

Make sure that:

• the workflow has been saved in Studio;
• the workflow appears in RunFlows;
• it has completed several manual runs;
• its normal and unusual input has been tested;
• every branch has been reviewed;
• provider and tool errors are visible;
• any write action has been confirmed at its destination; and
• someone is responsible for reviewing the scheduled result.

One successful manual run is not enough.

A scheduled workflow should already behave predictably before it runs without someone starting it by hand.

Step 1: Open Schedule Manager

Open RunFlows from the Feluda sidebar.

Then select the Schedule Manager option in the RunFlows header.

Schedule Manager shows:

• active schedules;
• paused schedules;
• upcoming runs;
• recent run history;
• status information; and
• conflict warnings.

Select the option to create a new schedule.

Step 2: Choose the workflow

Select the saved flow you want to schedule.

Before continuing, confirm:

• the full workflow name;
• whether it is local or Gene-provided;
• what input it expects;
• what result it returns;
• which provider and model it uses;
• whether it depends on a Gene;
• whether it uses tools;
• where its result is shown or saved; and
• whether the output needs human approval.

Do not schedule an unfamiliar workflow.

Open it in Studio or run it manually first when you are not certain what it does.

Step 3: Choose the schedule pattern

Select the frequency that matches the task.

Available patterns include:

Pattern	Use it for
Once	One future execution
Daily	A workflow that should run every day
Weekdays	A Monday-to-Friday workflow
Weekly	A workflow that runs on one selected day each week
Monthly	A workflow that runs on one selected day each month

Use the least frequent schedule that still meets the need.

A repeated run uses providers, models, tools, computer resources, and review time.

Use a one-time schedule

Choose Once when the workflow should run only one time.

For example:

• prepare a report before a future meeting;
• process a document at a planned time;
• create a one-off project summary; or
• run a task while you are away from the computer.

Select the required date and time.

Review the schedule after saving to confirm that the next run is the exact moment you intended.

Use a daily schedule

Choose Daily when the workflow should run every day.

Examples include:

• a morning briefing;
• a daily operations summary;
• a recurring source check;
• a daily Journal entry; or
• an end-of-day report.

Make sure the source information is available before the run starts.

A daily workflow should not begin before the day's required data exists.

Use a weekday schedule

Choose Weekdays when the workflow is needed from Monday through Friday but not at the weekend.

This may suit:

• business-day handovers;
• team summaries;
• weekday monitoring;
• customer-support reviews; or
• internal reporting.

Review public holidays and days when the computer may be unavailable.

The weekday pattern does not automatically understand your organisation's holiday calendar.

Use a weekly schedule

Choose Weekly when the workflow belongs to one specific day each week.

Examples include:

• a Friday project review;
• a Monday planning brief;
• a weekly research summary; or
• a recurring content report.

Select the correct weekday and time.

Make sure the result will be ready before the meeting or activity that needs it.

Use a monthly schedule

Choose Monthly for work such as:

• a monthly performance summary;
• a recurring compliance review;
• a monthly research brief;
• a monthly content report; or
• a regular management update.

Select the intended day of the month.

Consider what should happen in shorter months when the selected date may not exist.

Review the next-run date after saving.

Step 4: Set the date or day

The date fields depend on the selected pattern.

For a one-time schedule, choose the exact calendar date.

For a weekly schedule, choose the weekday.

For a monthly schedule, choose the day of the month.

Check that the selected date matches the source cycle.

For example, a monthly report should not run before the month-end source data is available.

Step 5: Set the time

Choose the time when the workflow should begin.

Consider:

• when the source information becomes available;
• how long the workflow normally takes;
• when the result must be ready;
• whether the computer will be on;
• whether a local model will be running;
• whether connected services are normally available; and
• whether another scheduled workflow may overlap.

Do not schedule the run at the same moment the result is needed.

Leave enough time for execution and review.

Step 6: Confirm the timezone

Select or confirm the timezone used for the schedule.

The timezone matters when:

• you travel;
• the computer timezone changes;
• daylight-saving time begins or ends;
• a team works in several locations; or
• the result is needed in another region.

After saving, review the displayed next-run time.

This is the clearest way to confirm that Feluda interpreted the selected time correctly.

Step 7: Provide the starting input

A workflow beginning with an Input block may need a starting prompt or message.

Enter the input that Feluda should use each time the schedule runs.

For example:

Prepare the weekly project review.

Include:
1. completed work;
2. current blockers;
3. upcoming deadlines;
4. decisions that need attention; and
5. unanswered questions.

Use only information returned by the workflow's approved sources.
If information is missing, write "Not provided."
Do not guess.

The scheduled input should be complete enough to work without a person adding a follow-up message.

Use a stable scheduled prompt

A scheduled prompt should explain:

• the task;
• the source to use;
• the required output;
• the output format;
• important limits; and
• what to do when information is missing.

Avoid prompts such as:

Do the usual report.

Feluda cannot rely on information that is not included in the workflow or scheduled input.

Use a prompt that remains understandable weeks or months later.

Understand changing source information

The scheduled input may stay the same while the source information changes.

The workflow may collect new information from:

• a local file;
• a Journal entry;
• a connected tool;
• an approved online source;
• an external service; or
• another supported destination.

Confirm that the source will be available when the schedule runs.

A schedule cannot create new source data by itself.

Step 8: Set the maximum runtime

Choose how long Feluda should allow the scheduled run to continue.

Maximum runtime helps stop a workflow that becomes stuck because:

• a provider does not respond;
• a local model stops;
• a tool becomes unavailable;
• an external service is slow;
• a branch does not complete; or
• the input takes longer than expected.

Set the limit based on observed manual runs.

It should be:

• longer than the normal execution time; and
• short enough to make an abnormal run visible.

Do not choose a very short limit for a workflow that uses large models, image generation, or several external tools.

Step 9: Review dependencies

Before saving the schedule, confirm that the workflow's requirements will be available at run time.

Depending on the flow, Feluda may need:

• the desktop application to be open;
• the computer to be on;
• an internet connection;
• a configured cloud provider;
• a valid API key;
• access to the selected model;
• Ollama or LM Studio to be running;
• the required local model to be loaded;
• installed Genes;
• active tools or MCP connections;
• accessible files; and
• available external services.

Scheduling does not remove any of these requirements.

Step 10: Review write actions

Check whether the workflow creates, updates, sends, saves, or removes information.

A scheduled write action may:

• create a Journal entry;
• save a report;
• write a file;
• update a record;
• send a message; or
• change something in a connected service.

Confirm:

• the destination;
• the item name;
• whether repeated runs create duplicates;
• whether existing information may be overwritten;
• what happens after a timeout; and
• who confirms the final action.

Keep high-impact actions behind human review when appropriate.

Step 11: Save the schedule

Review the complete schedule before saving.

Check:

• workflow;
• frequency;
• date or weekday;
• time;
• timezone;
• starting input;
• maximum runtime;
• provider and tool requirements;
• output destination; and
• review owner.

Save or activate the schedule.

The schedule should now appear in Schedule Manager.

Step 12: Confirm the next run

Find the new schedule in the list.

Confirm:

• that it is enabled;
• the correct workflow is selected;
• the next-run date is correct;
• the next-run time is correct;
• the timezone is correct;
• no warning is shown; and
• the schedule does not conflict with another run.

Correct any mistake before the first scheduled execution.

Review conflict warnings

Schedule Manager may warn you about overlapping or competing work.

A conflict may involve:

• two workflows starting at the same time;
• several local models competing for memory;
• two flows writing to the same file;
• repeated updates to the same record;
• one run continuing into the next scheduled start; or
• several workflows using the same limited service.

Resolve the conflict by:

• changing one schedule time;
• increasing the spacing between runs;
• shortening the workflow;
• using separate destinations;
• reducing simultaneous local models; or
• changing the process design.

Do not ignore a warning when the flows can affect the same destination.

Test the schedule with a one-time run

A one-time schedule can be a useful final test.

Set it for a near-future time using non-sensitive input.

Confirm that:

• Feluda starts the workflow;
• the expected provider and model are available;
• the starting input is correct;
• the workflow follows the intended path;
• tools complete;
• the result appears in the expected place; and
• the run history records the outcome.

After this test, create the intended recurring schedule.

Keep Feluda available

Schedule Manager runs through the Feluda desktop application.

The scheduled workflow cannot start normally when Feluda is not available at the planned time.

For important schedules:

• keep the computer on;
• keep Feluda running;
• prevent sleep when necessary;
• keep local model software open;
• maintain the required network connection; and
• review what happened after any period when the computer was unavailable.

Pending schedules may be evaluated when Feluda is opened again, depending on their configured cadence.

Review the run history rather than assuming a missed time was completed.

Schedule a local-model workflow

For a workflow that uses Ollama or LM Studio:

• install the required model in advance;
• confirm the provider works in Workbench;
• keep the local model application running;
• make sure enough memory is available;
• avoid overlapping large local-model runs; and
• test the schedule under normal computer load.

A local schedule can run without an internet connection when every required model, tool, source, and destination is also local.

Schedule a cloud-model workflow

For a cloud workflow, confirm:

• the internet connection will be available;
• the provider is configured;
• the API key is active;
• the selected model remains accessible;
• the account can complete the request; and
• the external provider is permitted for the information used.

Provider-side changes can cause a previously working schedule to fail.

Review recent history regularly.

Schedule a Gene workflow

Before scheduling a Gene-provided flow:

1. review the Gene description;
2. confirm what the flow does;
3. complete its settings;
4. test the flow manually;
5. verify required tools and services;
6. use non-sensitive sample input;
7. confirm the final destination; and
8. review the scheduled result.

Removing or changing the Gene may affect the schedule.

Schedule a Journal workflow

A workflow may write scheduled results to the Journal.

This can be useful for:

• daily briefings;
• weekly reports;
• monitoring results;
• research summaries; or
• recurring review notes.

Confirm:

• the Journal tool is available;
• the workflow uses the correct title;
• each run can be identified;
• repeated entries will not cause confusion; and
• someone checks the Journal after the run.

Use dates in entry titles when repeated reports need to remain distinct.

Avoid duplicate scheduled output

Repeating schedules can create duplicate items when:

• the workflow runs twice;
• an earlier timeout is retried;
• the destination name does not change;
• two schedules use the same flow and input; or
• overlapping runs write to the same place.

Reduce duplication by:

• checking active schedules;
• using unique output names;
• including dates where appropriate;
• avoiding overlapping starts;
• confirming timeouts before retrying; and
• removing outdated duplicate schedules.

Decide who reviews the result

Assign responsibility before activating the schedule.

The reviewer should know:

• when the workflow runs;
• where the result appears;
• what a normal output looks like;
• how missing information is shown;
• which warnings require action;
• what to do after an error; and
• when the schedule should be paused.

A scheduled workflow should not run indefinitely without oversight.

Review the first scheduled run

After the first run, check:

• whether it started at the expected time;
• whether the correct timezone was used;
• whether the starting input was correct;
• whether every required step completed;
• whether warnings or errors appeared;
• whether tool actions reached the correct destination;
• whether the final output is accurate; and
• whether the runtime was appropriate.

Correct the schedule or workflow before the next run when needed.

Pause after unexpected behaviour

Pause the schedule when:

• the wrong workflow ran;
• the wrong input was used;
• the result followed the wrong path;
• a tool affected the wrong destination;
• repeated errors appear;
• a provider is unavailable;
• the result cannot be reviewed; or
• the workflow needs editing.

Pausing prevents future starts.

It does not reverse actions from earlier runs.

Resume after testing

Before resuming:

• correct the problem;
• test the workflow manually;
• confirm providers and tools;
• review the scheduled input;
• check the next-run time;
• resolve conflicts; and
• assign a reviewer.

Resume only after the flow is dependable again.

A practical weekly schedule

Imagine that you want a weekly project review every Friday afternoon.

Use:

• Workflow: Prepare Weekly Project Review
• Pattern: Weekly
• Day: Friday
• Time: 15:00
• Timezone: Your working timezone
• Input: Prepare the weekly project review from the approved sources
• Maximum runtime: Based on tested execution time

Before saving:

1. run the workflow manually;
2. confirm that Friday's source data is ready before 15:00;
3. review the output format;
4. test missing project updates;
5. confirm where the result is saved; and
6. assign the reviewer.

Final schedule checklist

Before activating the schedule, confirm that:

• the workflow is tested;
• the correct flow is selected;
• the recurrence matches the task;
• the date or weekday is correct;
• the time and timezone are correct;
• the scheduled input is complete;
• the maximum runtime is realistic;
• all providers and tools will be available;
• overlapping runs are controlled;
• write destinations are correct;
• the next run is displayed correctly; and
• someone will review the result.

A schedule removes the need to start the workflow manually.

It does not remove the need to test, review, and maintain the process.