Manage Scheduled Workflows

Manage Scheduled Workflows

A schedule should not be left unchanged forever.

Providers, models, tools, files, source information, and workflow instructions can all change over time.

Schedule Manager helps you keep recurring automation understandable and dependable by letting you review:

• which workflows are scheduled;
• when they will run next;
• whether they are active or paused;
• what happened during recent runs;
• whether two schedules may conflict; and
• whether a schedule should be updated or removed.

Good schedule management combines technical checks with clear human responsibility.

Open Schedule Manager

Open RunFlows from the Feluda sidebar.

Then open Schedule Manager from the RunFlows header.

The workspace shows your scheduled workflows together with their current status and next planned run.

Depending on the schedule, you may also see:

• the recurrence pattern;
• the time and timezone;
• recent run history;
• warnings;
• conflicts;
• pause or resume controls; and
• options for changing or removing the schedule.

Review the schedule list

Begin by reviewing every active and paused schedule.

For each one, confirm:

• the workflow name;
• the schedule pattern;
• the next-run date and time;
• the timezone;
• whether the schedule is active;
• whether recent runs completed;
• whether warnings or errors appeared; and
• whether the schedule is still needed.

A schedule that no one understands should not remain active.

Understand schedule status

A schedule may be active or paused.

Status	Meaning
Active	Future runs can start according to the configured pattern
Paused	The schedule remains saved, but future runs do not start until it is resumed

Pausing a schedule does not remove it.

It also does not reverse earlier workflow runs or tool actions.

Review the next planned run

The next-run time is one of the most important schedule details.

Confirm:

• the correct date;
• the correct time;
• the intended timezone;
• whether the computer will be available;
• whether required local services will be running; and
• whether another schedule overlaps.

Review the next run after every change.

This helps catch incorrect timezones, recurrence settings, or dates before the workflow starts.

Review recent run history

Recent history shows whether the schedule is working in practice.

Check:

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

A schedule can remain active even when recent runs repeatedly fail.

Do not assume that an active status means the automation is healthy.

Pause a schedule

Pause a schedule when future runs should stop temporarily.

Common reasons include:

• the workflow needs editing;
• the selected provider is unavailable;
• a model has changed;
• a Gene or tool is being updated;
• the source is temporarily unavailable;
• repeated errors appear;
• the computer will be offline;
• the result is not currently needed; or
• no one is available to review the output.

Pause first when you are unsure whether the next run is safe.

What happens when a schedule is paused

The schedule remains visible in Schedule Manager.

Its configuration is preserved.

While paused:

• future runs do not start;
• the workflow can still be run manually through RunFlows;
• the schedule can be reviewed or updated; and
• it can be resumed later.

Review any run that was already active when the pause was applied.

Pausing future execution does not necessarily stop an execution that has already begun.

Resume a schedule

Resume a schedule only after confirming that the workflow is ready again.

Before resuming:

• test the workflow manually;
• confirm the provider and model;
• check local services;
• review Gene and tool settings;
• confirm the source is available;
• review the scheduled input;
• check the next-run time;
• resolve conflicts; and
• confirm who will review the result.

After resuming, verify that the schedule shows the expected next run.

Edit a schedule safely

Schedule details may need to change.

You may need to update:

• the selected workflow;
• the recurrence;
• the weekday or date;
• the time;
• the timezone;
• the starting input;
• the maximum runtime; or
• the active or paused state.

Pause the schedule before making an important change when there is a chance it could run during editing.

Change the recurrence

Change the recurrence when the task no longer needs its current frequency.

For example:

• daily to weekdays;
• weekly to monthly;
• recurring to one-time; or
• one weekday to another.

Before saving the change, consider:

• when the source becomes available;
• how often the result is actually used;
• whether review capacity matches the new frequency;
• whether tool actions may create duplicates; and
• whether another schedule already performs similar work.

Review the next planned run after saving.

Change the time

Update the scheduled time when:

• source information becomes available later;
• the result is needed earlier;
• another workflow overlaps;
• local computer resources are too busy;
• a service is more reliable at another time; or
• the reviewer needs more time before using the result.

Leave enough time for the workflow to finish and for someone to review the output.

Change the timezone

Review the timezone after:

• travel;
• moving the computer to another region;
• daylight-saving changes;
• a team-location change; or
• a change in who receives the result.

Do not change only the written time without checking the resulting next-run moment.

The same clock time can represent a different moment in another timezone.

Update the starting input

A scheduled input may become outdated.

Update it when:

• the report format changes;
• a source changes;
• new fields are required;
• the audience changes;
• the workflow should use another tool;
• missing information needs clearer handling; or
• the output needs a different structure.

Use a complete instruction.

For example:

Prepare the weekly project review.

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

Use only approved sources.
If a required detail is missing, write "Not provided."
Do not guess.

Test the exact updated input manually before resuming the schedule.

Update the maximum runtime

Change the maximum runtime when the workflow consistently:

• finishes much faster than the current limit;
• is stopped before normal completion;
• uses a larger or smaller model;
• adds or removes tools;
• processes more information; or
• changes its number of steps.

The runtime limit should be longer than normal execution but short enough to make stalled runs visible.

Avoid increasing the limit only to hide repeated failures.

Investigate why the workflow is slow.

Change the selected workflow carefully

Replacing the workflow inside a schedule can change:

• expected input;
• providers;
• models;
• tool actions;
• destinations;
• output structure;
• privacy requirements; and
• runtime.

Treat this as a major change.

Test the new workflow manually and review every schedule field before activating it.

Monitor active schedules

Review active schedules regularly.

A useful review includes:

• next-run time;
• recent success or failure;
• normal runtime;
• provider availability;
• local-service availability;
• source availability;
• tool destinations;
• output quality; and
• whether the schedule still has an owner.

Regular review helps detect quiet failures before they continue for several runs.

Review conflict warnings

Schedule Manager can show conflict warnings when planned work may overlap or compete.

Common conflicts include:

• two workflows starting at the same time;
• several local models using too much memory;
• one run continuing into the next scheduled start;
• two workflows writing to the same file;
• repeated updates to the same record;
• duplicate Journal entries; or
• several flows depending on the same external service.

Review the warning before the next run.

Resolve schedule conflicts

You can resolve a conflict by:

• changing one start time;
• increasing the spacing between runs;
• shortening the workflow;
• increasing or reducing the runtime limit appropriately;
• using separate output destinations;
• reducing simultaneous local models;
• changing repeated item names; or
• removing a duplicate schedule.

Test the affected schedules manually after making changes.

Prevent overlapping runs

A repeating workflow may start again before the earlier run has finished.

This can create:

• duplicate output;
• competing provider requests;
• conflicting file changes;
• repeated messages;
• overwritten information; or
• unclear history.

Compare the normal and slowest observed runtime with the recurrence interval.

Make sure one run has enough time to finish before the next begins.

Review local-model dependencies

For schedules using Ollama, LM Studio, or another compatible local provider, confirm that:

• the computer will be on;
• Feluda will be available;
• the local model application will be running;
• the required model remains installed;
• the model can load successfully;
• enough memory is available; and
• overlapping local runs will not overload the system.

Pause the schedule when the local environment is unavailable.

Review cloud-provider dependencies

For cloud workflows, confirm that:

• the internet connection is available;
• the provider remains configured;
• the API key is active;
• the selected model remains available;
• the account can complete the request; and
• the provider is appropriate for the information being sent.

Test the provider in Workbench after repeated scheduled failures.

Review Gene and tool dependencies

A scheduled workflow may depend on a Gene, tool, or MCP connection.

Confirm that:

• the Gene remains installed;
• it has been synced;
• required settings are complete;
• the tool is still available;
• external services remain accessible;
• permission limits still allow the action; and
• tool results remain suitable for the next workflow step.

Pause dependent schedules before removing or changing a required Gene.

Review output destinations

Scheduled workflows may save or change information.

Review destinations such as:

• Journal entries;
• files;
• folders;
• connected records;
• messages;
• reports; or
• external services.

Confirm that each schedule writes to the intended place.

Use unique names or dates when repeated runs create separate items.

Prevent duplicate output

Duplicates can appear when:

• the same schedule exists twice;
• two schedules run the same flow;
• a timeout is retried;
• output names never change;
• overlapping runs use the same destination; or
• a paused schedule is replaced with a new one but later resumed.

Review the full schedule list before creating another schedule.

Remove or keep paused any duplicate configuration that is no longer needed.

Review scheduled Journal entries

When a workflow writes to the Journal, check that:

• entries appear after the run;
• titles clearly identify the date or period;
• content matches the expected source;
• missing information is visible;
• duplicate entries are not being created; and
• someone reads the result.

A useful title might be:

Weekly Project Review — 2026-06-08

This is clearer than creating repeated entries named only:

Weekly Project Review

Review schedule ownership

Every schedule should have a responsible person.

That person should know:

• what the workflow does;
• when it runs;
• where the result appears;
• which providers and tools it uses;
• what a normal result looks like;
• how to respond to an error;
• when to pause it; and
• when it should be removed.

Reassign ownership when responsibilities change.

Remove a schedule

Remove a schedule when:

• the workflow is no longer needed;
• another schedule replaces it;
• the source no longer exists;
• the project has ended;
• the workflow has been removed;
• the schedule repeatedly fails and will not be repaired; or
• keeping it would create confusion.

Removing a schedule stops future planned runs.

It does not remove the workflow itself.

It also does not erase earlier results or reverse earlier actions.

Check before removing a schedule

Before removal, confirm:

• the correct schedule is selected;
• no future run is still needed;
• another process does not depend on its output;
• recent results have been reviewed;
• important output has been saved;
• the workflow remains available if manual use is still needed; and
• no replacement schedule is accidentally duplicated.

Pause first when you are uncertain.

Remove outdated schedules

Old schedules create risk when they remain active after the work has ended.

Review schedules connected to:

• completed projects;
• former team responsibilities;
• retired providers;
• removed models;
• unavailable tools;
• outdated source files; or
• old report formats.

Remove or update them before they create misleading output.

Keep the workflow separate from the schedule

Removing or pausing a schedule does not normally change the saved workflow.

The flow can still be:

• opened in Studio;
• edited;
• run manually through RunFlows; or
• placed into another schedule later.

This separation lets you stop automatic execution without losing the process itself.

Review after a workflow change

A schedule may still point to a workflow that has been edited.

After changing a scheduled flow:

1. pause the schedule;
2. test the workflow manually;
3. review its new input and output;
4. confirm providers and tools;
5. check the normal runtime;
6. update the schedule if needed;
7. confirm the next run; and
8. resume it.

Do not assume that the old schedule remains suitable after a major workflow change.

Review after a provider change

When a model or provider changes:

• test the workflow in RunFlows;
• compare output quality;
• review tool support;
• check runtime;
• confirm privacy requirements;
• update the scheduled input when needed; and
• monitor the first scheduled result closely.

Different models can behave differently with the same instruction.

Review after a tool change

When a tool or external service changes:

• pause the schedule;
• confirm the connection;
• review required settings;
• test a safe read action;
• test write actions with care;
• verify the destination;
• inspect returned data; and
• resume only after successful manual runs.

A tool that appears available may still return a different format than the workflow expects.

Create a regular review routine

Review schedules at a consistent interval.

For each schedule, check:

1. whether it is still needed;
2. whether the next-run time is correct;
3. whether recent runs completed;
4. whether warnings or errors repeated;
5. whether providers and tools remain available;
6. whether output is still useful;
7. whether destinations are correct;
8. whether conflicts exist; and
9. whether the schedule still has an owner.

Frequent schedules should be reviewed more often than occasional ones.

Keep human review where needed

Scheduled execution does not remove human responsibility.

Human review is especially important when output affects:

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

A schedule can prepare information or drafts.

Important decisions and high-impact actions should remain reviewable.

A practical management routine

Use this process:

1. Open Schedule Manager.
2. Review active and paused schedules.
3. Check each next-run time.
4. Review recent history.
5. investigate repeated warnings or failures.
6. Pause schedules that need attention.
7. Test changed workflows manually.
8. Update recurrence, input, timezone, or runtime when needed.
9. Resolve overlaps and shared-destination conflicts.
10. Resume only after confirming readiness.
11. Remove outdated or duplicate schedules.
12. Confirm that every active schedule has a reviewer.

Schedule management keeps recurring workflows visible, controlled, and useful.