Gene Library Courses Download Pricing Contact Sign in
Documentation

What is Schedule Manager?

automationschedule-managerworkflows

What is Schedule Manager?

Schedule Manager is the Feluda workspace where you arrange for a saved workflow to run at a selected time.

A schedule can run once or repeat on a regular pattern.

Schedule Manager helps you:

  • choose a saved workflow;
  • decide when it should run;
  • provide its starting input;
  • set the correct timezone;
  • limit how long a run may continue;
  • review upcoming runs;
  • check recent run history;
  • identify scheduling conflicts; and
  • pause or resume a schedule.

Use Schedule Manager only after the workflow has been built, saved, and tested manually.

What scheduling changes

Without a schedule, you open RunFlows and start the workflow yourself.

With a schedule, Feluda starts the selected workflow at the configured time.

The workflow itself does not change.

It still uses the same:

  • blocks;
  • connections;
  • AI providers;
  • models;
  • instructions;
  • tools;
  • branches; and
  • outputs.

Schedule Manager controls when the saved process begins.

Studio controls how the process works.

Schedule Manager and RunFlows are different

RunFlows is used for on-demand execution.

Schedule Manager is used for planned execution.

Area Main purpose
RunFlows Start a saved workflow manually and review its live result
Schedule Manager Arrange for a saved workflow to start at a selected time

A good workflow journey is:

  1. test the task in Workbench;
  2. build the workflow in Studio;
  3. save it;
  4. run it several times through RunFlows;
  5. review normal and unusual input;
  6. confirm tools and outputs; and
  7. create a schedule only when the manual runs are dependable.

Available schedule patterns

Schedule Manager can support several common timing patterns.

Pattern What it does
Once Runs the workflow one time at the selected date and time
Daily Runs every day at the selected time
Weekdays Runs from Monday through Friday
Weekly Runs on the selected day each week
Monthly Runs on the selected day each month

Choose the simplest pattern that matches the task.

A workflow that only needs to run once should not be given a repeating schedule.

Examples of scheduled workflows

Schedule Manager can be useful for repeatable work such as:

  • preparing a daily summary;
  • creating a weekday handover;
  • producing a weekly project review;
  • generating a monthly report;
  • checking a source at regular intervals;
  • preparing a recurring research brief; or
  • running a local information-processing task overnight.

The workflow still needs a clear source of input.

Scheduling does not automatically provide new information unless the flow is designed to retrieve or receive it.

What a schedule contains

A schedule normally includes:

  • the workflow to run;
  • the frequency;
  • the date or day;
  • the time;
  • the timezone;
  • the starting input or prompt;
  • the maximum runtime;
  • the current status; and
  • the next planned run.

Review every field before saving the schedule.

A correct workflow with the wrong time or input can still produce an unwanted result.

Choose the workflow carefully

Select a workflow that has already been saved.

Before scheduling it, confirm:

  • the workflow name;
  • what it is designed to do;
  • 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 results are saved; and
  • who reviews the output.

Avoid scheduling an unfamiliar Gene flow before you understand its requirements and actions.

Use a clear workflow name

Scheduled workflows should be easy to identify.

Prefer names such as:

  • Prepare Daily Operations Summary;
  • Create Weekday Support Handover;
  • Generate Weekly Project Review; or
  • Prepare Monthly Research Brief.

Avoid unclear names such as:

  • Test;
  • New Flow;
  • Final;
  • Workflow 2; or
  • Report.

The workflow name should help you recognise the process in the schedule list and run history.

Choose the frequency

The frequency should match how often the work is actually needed.

Use Once for a single future run.

Use Daily when the task is needed every day.

Use Weekdays when weekend runs are unnecessary.

Use Weekly when the work belongs to a particular day.

Use Monthly for recurring monthly reviews or reports.

Avoid creating a frequent schedule only because the option is available.

Every run uses computer resources, providers, tools, and review time.

Choose the time

Select a time when:

  • the required source information is expected to be ready;
  • the computer is likely to be available;
  • local model software can be running;
  • connected services are accessible;
  • overlapping workflows will not cause problems; and
  • someone can review the result when needed.

For example, a daily summary should not run before the day's source information exists.

A weekly report should finish before the meeting where it will be reviewed.

Set the timezone

The timezone determines how Feluda interprets the scheduled time.

Confirm the timezone when:

  • you travel;
  • your computer timezone changes;
  • a team works across several regions;
  • daylight-saving time may apply; or
  • the result must be ready for someone in another location.

Do not assume that a written time such as 09:00 means the same moment for every user.

Review the next-run time after saving the schedule.

Provide the starting input

Some workflows begin with an Input block and need a starting prompt or message.

Schedule Manager lets you define that input in advance.

For example:

Prepare the weekly project review.

Include:
1. completed work;
2. current blockers;
3. upcoming deadlines; and
4. decisions requiring attention.

Use only the information returned by the workflow's approved sources.

The scheduled input should be clear enough to work without a person typing a follow-up message at run time.

Use stable scheduled input

A scheduled prompt should not depend on information that only exists inside your head.

It should explain:

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

For example:

If a required detail is unavailable, write "Not provided."
Do not guess.

Test the exact scheduled input manually before saving it.

Understand where changing input comes from

A fixed schedule can reuse the same starting prompt each time.

The changing information must come from somewhere else in the workflow.

It may come from:

  • a connected tool;
  • an approved external source;
  • a local file;
  • a Journal entry;
  • another supported service; or
  • information that the workflow retrieves during the run.

A schedule does not create new source information by itself.

Confirm that the source will contain the expected data when the workflow starts.

Set a maximum runtime

Maximum runtime limits how long a scheduled execution may continue.

This helps prevent a workflow from running indefinitely when:

  • a model does not respond;
  • a tool becomes unavailable;
  • a local service stops;
  • a branch repeats unexpectedly; or
  • an external source takes too long.

Choose a limit that is long enough for normal execution but short enough to make stalled runs visible.

Test the workflow several times to understand its usual runtime before setting the limit.

What must remain available

A scheduled workflow still depends on its normal requirements.

At the planned run time, Feluda may need:

  • the desktop application or scheduling service to be available;
  • the computer to be on;
  • an internet connection for cloud providers;
  • a valid provider connection;
  • the selected model to remain available;
  • Ollama or LM Studio to be running for a local model;
  • required Genes to remain installed;
  • tools and external services to be accessible; and
  • the intended files or sources to exist.

Scheduling does not remove these dependencies.

Schedule local-model workflows carefully

A scheduled local workflow depends on your computer.

Confirm that:

  • the computer will be on;
  • the local model application will be running;
  • the required model is installed;
  • enough memory is available;
  • the local service address has not changed; and
  • other scheduled runs will not overload the computer.

Test the workflow at approximately the same time and under similar computer load before relying on the schedule.

Schedule cloud-model workflows carefully

A cloud-model schedule needs:

  • an internet connection;
  • an active provider configuration;
  • a valid API key;
  • access to the selected model; and
  • an available provider service.

Provider availability can change.

Review failures and recent history instead of assuming every scheduled run completed.

Scheduled tools and external services

A scheduled workflow may use tools without a person watching the live run.

Before enabling this:

  • confirm what each tool can do;
  • review the information it receives;
  • check the destination;
  • test permission limits;
  • understand whether the action can be reversed;
  • make failures visible; and
  • decide who checks the result.

Read actions are generally easier to review than actions that create, update, send, or remove information.

Use extra care with write actions

A scheduled write action may:

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

Before scheduling it, confirm:

  • the exact destination;
  • the file or record name;
  • whether repeated runs create duplicates;
  • whether existing information can be overwritten;
  • what happens after a timeout; and
  • how the result will be checked.

Keep high-impact actions behind human review where appropriate.

Review upcoming runs

Schedule Manager shows planned executions.

Use the upcoming-runs view to confirm:

  • which workflow will run;
  • when it will start;
  • the timezone;
  • whether the schedule is active;
  • whether another run overlaps; and
  • whether the workflow requirements will be available.

Review upcoming runs after creating or editing a schedule.

This is the clearest way to catch an incorrect day, time, or timezone.

Review recent history

Recent history helps you see what happened during earlier scheduled runs.

Review:

  • whether the run started;
  • whether it completed;
  • how long it took;
  • whether warnings appeared;
  • whether an error occurred;
  • what output was produced; and
  • whether the final destination contains the expected result.

A schedule is not dependable simply because it remains enabled.

Its recent runs should be reviewed.

Understand conflict warnings

A conflict warning can appear when scheduled work may overlap or compete.

Possible conflicts include:

  • two flows starting at the same time;
  • several local models competing for memory;
  • two workflows writing to the same file;
  • repeated updates to the same record;
  • one run lasting into the next planned run; or
  • several workflows depending on the same limited service.

Do not ignore a conflict warning.

Decide whether to change the time, reduce overlap, increase the runtime spacing, or redesign the destination.

Avoid overlapping runs

A repeating workflow may start again before the earlier run finishes.

This can cause:

  • duplicate output;
  • competing model requests;
  • conflicting file changes;
  • repeated messages;
  • overwritten results; or
  • confusing run history.

Set the schedule interval and maximum runtime so normal runs have time to finish.

Test slow and unusual cases before enabling frequent repetition.

Pause a schedule

Pausing keeps the schedule configuration but stops future runs until it is resumed.

Pause a schedule when:

  • the workflow needs editing;
  • a provider is unavailable;
  • a tool or source has changed;
  • the output is no longer needed temporarily;
  • repeated errors appear;
  • the computer will be unavailable; or
  • the result cannot currently be reviewed.

Pausing does not reverse earlier runs or actions.

Resume a schedule

Resume only after confirming that:

  • the workflow still works manually;
  • required providers and models are available;
  • tool settings are current;
  • the source is ready;
  • the next-run time is correct;
  • conflicts have been resolved; and
  • someone will review the output.

Check the next planned run after resuming.

Review scheduled results

A scheduled result needs the same review as a manual result.

Check whether it:

  • used the expected source;
  • followed the correct path;
  • completed every required step;
  • returned the expected format;
  • handled missing information clearly;
  • avoided unsupported claims;
  • completed tool actions; and
  • reached the intended destination.

Results may also be written to the Journal when the workflow is designed to do so.

Open the Journal and confirm the entry rather than relying only on the run status.

Decide who reviews the output

Every schedule should have an owner.

That person should know:

  • what the workflow does;
  • when it runs;
  • where the result appears;
  • what a normal result looks like;
  • which warnings require action;
  • what to do after a failure; and
  • when the schedule should be paused.

An automatic run without a review owner can fail unnoticed.

Keep human review where it matters

Human review is especially important when scheduled output affects:

  • customers;
  • employees;
  • money;
  • contracts;
  • legal rights;
  • health;
  • safety;
  • security; or
  • access to important services.

A schedule can prepare a report, draft, summary, or recommendation.

Important decisions and high-impact actions should remain reviewable.

When a workflow is ready to schedule

A workflow may be ready when:

  • it has been saved;
  • it runs successfully through RunFlows;
  • several realistic examples have been tested;
  • missing information is handled;
  • every branch has been checked;
  • provider and tool failures are visible;
  • write actions have been confirmed;
  • normal runtime is understood;
  • overlapping runs have been considered; and
  • someone is responsible for reviewing the result.

One successful manual run is not enough.

When not to schedule yet

Keep the workflow manual when:

  • the instruction is still changing;
  • the input source is unreliable;
  • the output cannot be checked;
  • the workflow follows the wrong path sometimes;
  • tool destinations are unclear;
  • write actions may create duplicates;
  • the selected model is unstable;
  • errors are hidden; or
  • no one will review the result.

Continue using RunFlows until the process is dependable.

A practical scheduling example

Imagine a workflow that prepares a weekly project review.

The schedule might use:

  • Workflow: Prepare Weekly Project Review
  • Frequency: Weekly
  • Day: Friday
  • Time: 15:00
  • Timezone: Your working timezone
  • Starting input: Prepare the weekly review from the approved project sources
  • Maximum runtime: Long enough for the tested workflow to finish

Before enabling it:

  1. run the workflow manually on several Fridays;
  2. confirm that the source is ready before 15:00;
  3. review the report format;
  4. test missing project data;
  5. confirm where the report is saved; and
  6. assign someone to review the result.

A practical Schedule Manager review

Review Schedule Manager regularly.

Check:

  1. active schedules;
  2. upcoming run times;
  3. timezone settings;
  4. recent completion history;
  5. warnings and errors;
  6. overlapping schedules;
  7. provider and tool dependencies;
  8. write-action destinations; and
  9. schedules that are no longer needed.

Scheduled workflows should remain visible and understandable.

Schedule Manager is for tested automation

Schedule Manager removes the need to start a workflow manually at the same time each day, week, or month.

It does not remove the need to:

  • design the workflow carefully;
  • test it;
  • maintain its providers and tools;
  • review its output;
  • investigate failures; and
  • keep a person responsible for important results.

Use scheduling after the process is reliable, not as a replacement for making it reliable.

Frequently Asked Questions

Which schedule patterns can I use?
Schedule Manager supports one-time, daily, weekday, weekly, and monthly runs.
Does a scheduled workflow still need its provider and tools?
Yes. The selected models, local services, Genes, tools, files, and external connections must be available when the schedule starts.
What should I do when schedules may overlap?
Review the conflict warning, expected runtime, computer resources, and shared destinations. Change the timing or workflow design when overlapping runs could interfere.
Should I schedule a workflow after one successful test?
No. Run it manually with several realistic and unusual examples, test every path, confirm tool actions, and assign someone to review scheduled results.