How to Schedule AI Workflows
Scheduling an AI workflow means configuring a tested process to run at a selected time or recurring interval without a person starting it manually.
A scheduled workflow may prepare:
- a daily briefing;
- a weekly report;
- a monthly document review;
- a weekday inbox digest;
- a recurring research update;
- a client-preparation brief;
- a content-analysis summary; or
- another repeated output.
A simple pattern looks like:
Schedule
→ Collect Input
→ Validate
→ Run AI Steps
→ Save Reviewable Output
Scheduling should be one of the final stages of automation.
It does not make an unclear or unreliable workflow dependable. It only causes the same process to run without a person initiating it each time.
Before scheduling, confirm that the workflow handles normal input, missing information, provider failures, tool errors, duplicate actions, and human review requirements.
Choose between a schedule and an event trigger
A schedule starts a workflow according to time.
Examples include:
- every weekday morning;
- every Friday afternoon;
- on the first day of each month;
- once at a selected date and time; or
- every month before a reporting deadline.
An event trigger starts a workflow when something happens.
Examples include:
- a new message arrives;
- a file is added;
- a form is submitted;
- a record changes;
- a customer creates a request; or
- a connected service sends an event.
Use a schedule when the task should happen at a predictable interval.
Use an event trigger when the task should respond to new information as soon as it appears.
Some processes combine both. A scheduled workflow may check a data source for new records and stop when none are found.
Choose a useful cadence
Run the workflow only as often as the process requires.
Common cadences include:
| Cadence | Suitable examples |
|---|---|
| Once | A planned one-off analysis or future reminder |
| Daily | Morning briefs, daily summaries, recurring checks |
| Weekdays | Business-day reports and work-queue preparation |
| Weekly | Project updates, research digests, review reports |
| Monthly | Performance summaries, audits, content reviews |
More frequent execution increases:
- model calls;
- tool usage;
- data processing;
- review volume;
- operational cost; and
- the chance of duplicate or overlapping actions.
Do not schedule an hourly run when the source changes only once a day.
Match the cadence to the source update frequency and the reader's need.
Define the time zone
A schedule needs one clear time zone.
This matters for:
- teams in different countries;
- daylight-saving changes;
- monthly reporting boundaries;
- business-day schedules;
- customer-facing deadlines; and
- workflows that combine local and remote services.
Record:
- the selected time zone;
- the intended local time;
- whether daylight-saving changes are expected;
- the reporting period used by the source; and
- which date should appear in the output.
Test the schedule around a time-zone or daylight-saving change when timing is important.
Avoid describing a schedule only as 9:00 without identifying the relevant
time zone.
Define the input for an unattended run
A manual workflow can ask a person for missing information.
A scheduled workflow may run when no one is present.
Define where its input comes from.
The source may be:
- a local file;
- a folder;
- a Journal entry;
- an approved database;
- a connected service;
- a set of documents;
- a saved configuration; or
- information returned by a tool.
Confirm that the source will be available at the scheduled time.
Avoid depending on temporary clipboard content, an open browser page, or a file path that changes regularly.
Validate that the input belongs to the intended reporting period or run.
Check dependencies before the AI step
A scheduled workflow may depend on:
- the desktop application running;
- a local model service;
- internet access;
- a cloud provider;
- valid credentials;
- a mounted drive;
- a file or folder;
- an external API;
- a database; or
- another tool.
Add checks before expensive or consequential steps.
For example:
If source file is missing → Stop with Source Missing
If local model is unavailable → Stop or use approved fallback
If credentials are invalid → Stop with Connection Error
If no new records are found → Complete with No New Data
Do not allow unavailable dependencies to produce an empty report that looks successful.
Test the workflow manually first
Run the workflow manually with representative input before adding a schedule.
Test:
- normal input;
- empty input;
- incomplete input;
- unusually large input;
- an unavailable provider;
- a stopped local model;
- an invalid credential;
- a failed tool;
- every decision route;
- a write-action failure; and
- a case requiring human review.
Confirm that the final output clearly indicates:
- success;
- partial success;
- no new data;
- review required; or
- failure.
A scheduled run should not require someone to interpret an ambiguous blank result.
Make scheduled runs idempotent
An idempotent workflow can be repeated without creating unintended duplicate effects.
This is important because a run may be retried after:
- a timeout;
- a lost connection;
- an unclear tool response;
- an application restart;
- a partial failure; or
- a manual attempt to recover the process.
Use a run identifier, source identifier, reporting period, or destination check before creating a new record.
For example:
If a report for this period already exists → Stop or create a new version
If this source message was already processed → Skip it
If the task already exists → Update or review instead of duplicating
Be especially careful with message sending, payments, record creation, file creation, and external write actions.
Prevent overlapping runs
A new scheduled run may begin before the earlier run finishes.
This can happen when:
- the schedule is too frequent;
- the source is unusually large;
- a provider is slow;
- a tool retries;
- human review blocks completion; or
- the computer has limited resources.
Overlap can create:
- duplicate output;
- conflicting writes;
- excessive model usage;
- file locks;
- inconsistent reports; and
- repeated messages.
Choose a cadence longer than the expected maximum runtime.
Add a run-status or lock check where the process supports it.
Route conflicts to a visible warning rather than allowing both runs to continue silently.
Separate preparation from consequential actions
A scheduled AI workflow is safest when it prepares a reviewable result.
For example:
Schedule
→ Gather Updates
→ Create Draft Report
→ Save for Review
A higher-risk pattern is:
Schedule
→ Generate Message
→ Send Automatically
Separate generation from distribution when the output:
- goes to an external recipient;
- changes a customer or financial record;
- creates a public statement;
- affects access;
- makes a commitment;
- contains sensitive information; or
- is difficult to reverse.
Scheduling should not remove a required approval.
Design clear success and failure outputs
Every scheduled run should end in a visible state.
Useful outcomes include:
- Completed;
- Completed with no new data;
- Partial result;
- Human review required;
- Source missing;
- Provider unavailable;
- Tool failed;
- Duplicate prevented; and
- Run conflict detected.
Include enough context to investigate the problem.
A failure output may contain:
- schedule name;
- workflow name;
- planned run time;
- actual start time;
- failed step;
- error message;
- source identifier; and
- recommended next action.
Avoid placing unnecessary sensitive source content inside an error log.
Add safe retry behaviour
Temporary failures may justify a retry.
Examples include:
- provider rate limits;
- short network interruptions;
- temporary tool unavailability; and
- a local service still starting.
Define:
- which errors may be retried;
- maximum number of attempts;
- delay between attempts;
- total allowed runtime; and
- what happens after the final failure.
Do not retry every error.
Invalid input, missing permissions, unsupported files, and rejected actions normally need correction rather than repetition.
Confirm whether a write action completed before retrying it.
Keep the model output constrained
Scheduled workflows run without immediate supervision.
Use focused AI tasks and structured outputs.
Define:
- required fields;
- allowed labels;
- length limits;
- missing-value behaviour;
- source boundaries;
- review status; and
- prohibited assumptions.
Use fixed workflow logic to validate:
- required fields;
- dates;
- numbers;
- categories;
- thresholds;
- destinations; and
- duplicate identifiers.
An unattended model result should not be treated as verified data simply because it arrived on time.
Protect secrets and sensitive information
Scheduled workflows may run when no one is monitoring them directly.
Review:
- which model receives the input;
- which tools receive data;
- where outputs are stored;
- what appears in logs;
- who can access run history;
- which credentials are used; and
- how long records are retained.
Store API keys and tokens in protected provider, connection, or Secrets fields.
Do not place credentials in prompts, source files, schedule names, or error messages.
Give each tool the least access required.
A scheduled summarisation workflow does not need permission to delete files or send messages unless the process explicitly requires it.
Use local models on a schedule
A compatible local model can support scheduled AI processing on the desktop.
Confirm that:
- the model is downloaded;
- the local model application is running;
- the selected model is available;
- enough memory and storage remain;
- the computer will be awake;
- the workflow does not require an unavailable online tool; and
- failure is visible when the local service stops.
A local model keeps that model step on the computer.
The complete workflow is only local when all tools, sources, outputs, and destinations also remain local.
Test the scheduled process while disconnected when offline operation is a requirement.
Monitor scheduled runs
Scheduling creates an ongoing operational responsibility.
Review:
- upcoming runs;
- completed runs;
- failed runs;
- partial results;
- duplicate prevention;
- unusual runtime;
- provider errors;
- tool failures;
- review backlog;
- model cost; and
- output quality.
Assign an owner.
Define how often the owner reviews run history and what conditions require the schedule to be paused.
A workflow that fails every Monday should not remain active merely because the error is logged.
Monitoring should lead to correction.
Pause schedules during changes
Pause a schedule before changing:
- the workflow structure;
- the provider;
- the model;
- a tool;
- credentials;
- the source format;
- the destination;
- the reporting period; or
- validation rules.
Test the revised workflow manually.
Rerun the representative test set.
Resume the schedule only after the new version behaves dependably.
Preserve enough version information to understand which workflow produced an earlier result.
Build a schedulable workflow in Feluda
Feluda is a desktop application for building and running visual AI workflows.
Begin in Workbench to test the instruction and selected model.
Build the repeatable process in Studio.
Use focused blocks:
- LLM for summaries, comparisons, analysis, and drafting;
- LLM Label for classification;
- LLM Extract for structured fields;
- Expression for deterministic checks, dates, thresholds, and routing;
- Emit for intermediate status and debugging; and
- Output for success, review, no-data, partial, and error results.
Save the workflow and test it through RunFlows before scheduling it.
Review every branch and tool action.
Use Feluda Schedule Manager
Feluda's Schedule Manager is available in paid plans.
It lets you choose a saved flow and configure it to run:
- once;
- daily;
- on weekdays;
- weekly; or
- monthly.
You can open Schedule Manager from the Dashboard or RunFlows area.
Feluda shows upcoming runs, recent history, and conflict warnings. Schedules can be paused or resumed.
The scheduled process runs on the desktop. Feluda must be running for the workflow to execute at the planned time.
If the app is closed, that run cannot execute normally at its scheduled moment, so critical workflows should use an appropriate always-available setup and active monitoring.
Create a schedule in Feluda
A practical sequence is:
- finish and save the workflow in Studio;
- run it manually through RunFlows;
- confirm all provider, local-model, tool, and file dependencies;
- open Schedule Manager;
- choose the saved flow;
- select once, daily, weekdays, weekly, or monthly;
- choose the date or time;
- activate the schedule;
- review upcoming runs and conflicts; and
- inspect run history and output after execution.
Begin with a low-risk schedule.
A daily internal briefing or weekly draft report is easier to review than an unattended external write action.
Suitable scheduled Feluda workflows
Useful examples include:
- a weekday morning briefing written to the Journal;
- a weekly project-summary draft;
- a monthly document-review checklist;
- a recurring research digest;
- a scheduled content-analysis report;
- client-preparation notes before a regular meeting;
- a daily classification summary; and
- a periodic local document-processing task.
The Journal can provide a useful local destination for reviewable scheduled output when the enabled tool and workflow are configured appropriately.
Confirm tool permissions and output location before relying on the schedule.
Test the schedule itself
Workflow testing and schedule testing are different.
After manual testing, create a near-term test schedule.
Confirm:
- the workflow starts at the expected local time;
- the correct saved flow runs;
- the input source is available;
- the model and tools are available;
- the output reaches the intended destination;
- run history records the outcome;
- failures are visible;
- conflicts are handled; and
- no duplicate action occurs.
Test pause and resume behaviour.
Test what happens when Feluda or a required local model is unavailable.
Measure scheduled-workflow reliability
Useful measures include:
- planned runs;
- completed runs;
- missed runs;
- failed runs;
- partial runs;
- average runtime;
- conflict rate;
- retry rate;
- duplicate-prevention events;
- output-review time;
- cost per approved result; and
- percentage of outputs delivered on time.
Track output quality separately from schedule reliability.
A workflow may run on time but produce poor content.
Another may produce excellent content but miss runs because the desktop or local model is unavailable.
Both problems matter.
Common scheduling mistakes
Avoid:
- scheduling before manual testing;
- choosing a cadence that is too frequent;
- ignoring time zones;
- depending on unavailable files or services;
- allowing overlapping runs;
- retrying write actions without duplicate checks;
- hiding no-data and failure states;
- sending AI output automatically without necessary review;
- assuming a local model service is always running;
- leaving credentials inside prompts or files;
- failing to monitor run history; and
- changing an active workflow without pausing its schedule.
A schedule is dependable only when the workflow, environment, and ownership are dependable.
Schedule the smallest reliable process
Choose one low-risk recurring workflow.
Define the cadence, time zone, input source, dependencies, output, owner, and failure path.
Test the AI task in Workbench.
Build and validate the flow in Studio.
Run normal and failing cases through RunFlows.
Then create the schedule and verify a real scheduled execution.
AI workflow scheduling is most useful when it removes repeated manual starts without removing visibility, review, or responsibility.