Review Scheduled Workflow Results

Review Scheduled Workflow Results

A scheduled workflow still needs review.

Schedule Manager can start a tested flow at the selected time, but it cannot decide whether every result is accurate, complete, or ready to use.

Reviewing scheduled runs helps you confirm:

• whether the workflow started;
• whether it completed;
• which warnings or errors appeared;
• whether the expected output was produced;
• whether a tool action reached the correct destination;
• whether a run was missed; and
• whether the schedule should remain active.

Where to review scheduled runs

Open RunFlows, then open Schedule Manager.

Schedule Manager shows information about planned and recent executions.

Depending on the schedule, you may see:

• the workflow name;
• the schedule status;
• the next planned run;
• recent run history;
• completion states;
• warnings;
• errors;
• runtime information; and
• conflict notices.

Begin with the recent-history section.

Review the schedule before the result

Confirm that you are reviewing the correct schedule.

Check:

• the workflow name;
• the recurrence pattern;
• the scheduled time;
• the timezone;
• the active or paused state;
• the expected output destination; and
• the reviewer responsible for the result.

Similar schedule names can cause confusion.

Rename unclear workflows or schedules before they become difficult to track.

Check whether the run started

A scheduled run should appear in recent history after its planned time.

Confirm:

• the expected date;
• the expected start time;
• whether the schedule was active;
• whether Feluda was available;
• whether the computer was on;
• whether required local services were running; and
• whether a run record was created.

If no run appears, treat it as a missed execution and investigate before the next scheduled time.

Read the completion state

A scheduled run may show a state such as:

State	Meaning
Completed	The workflow reached an intended endpoint
Failed	A step could not complete
Stopped	The run ended before normal completion
Running	The workflow is still active
Missed	The planned execution did not start as expected

The exact wording may vary.

A Completed state does not confirm that the content itself is correct.

Review the output and any tool actions.

Review the run time

Compare the actual run time with the workflow's normal performance.

A much longer run may indicate:

• a slow provider;
• a local model under heavy load;
• a large source;
• an unavailable tool;
• an external service delay;
• repeated retries; or
• a workflow step that is no longer behaving normally.

A very short run may also deserve attention when the workflow usually takes longer.

It may have stopped early or skipped an expected path.

Review final output

Open the result associated with the scheduled run.

Check whether it:

• completed the intended task;
• used the expected source;
• followed the required format;
• included the necessary details;
• handled missing information clearly;
• avoided unsupported claims;
• followed the correct branch; and
• is suitable for its audience.

Compare important facts with the original source whenever possible.

Review intermediate output

Some workflows use Emit blocks to show progress or intermediate results.

These can help you understand:

• whether the source was received;
• whether extraction worked;
• which category or branch was chosen;
• what a tool returned;
• where information became incomplete; and
• which step failed first.

When the final output is wrong, review the intermediate results in order.

Review warnings

A warning may mean the workflow completed but found something that needs attention.

Warnings may indicate:

• missing source information;
• unclear input;
• a fallback path;
• incomplete tool output;
• a non-blocking error;
• an unresolved conflict; or
• a result that requires human review.

Read every warning before using the result.

Repeated warnings often mean the workflow or schedule needs to be updated.

Review errors

An error may come from:

• an unavailable AI provider;
• a model that cannot be reached;
• a local model service that was not running;
• an expired or incorrect provider key;
• a missing Gene setting;
• an unavailable tool;
• an inaccessible file;
• an unsupported input;
• a timeout; or
• an incorrect workflow connection.

Read the complete error message.

Then identify the first step that did not produce the expected result.

Review the first failing step

A later error may be caused by an earlier problem.

For example:

Source Retrieval
→ Extract Details
→ Prepare Report
→ Save to Journal

A failed Journal save may be obvious.

But an empty report may have started with a source-retrieval failure.

Review the run from the beginning and find the first incorrect or missing result.

Confirm the expected branch

A scheduled workflow may follow different paths.

For example:

Source Check
→ New Information → Create Report
→ No Change → Return No Update
→ Error → Human Review

Confirm that the result matches the branch the source should have taken.

If similar input follows different paths across runs, review the classification or Expression logic in Studio.

Confirm tool actions

Scheduled workflows may use tools without a person watching the live run.

For every tool action, check:

• which tool was used;
• what input it received;
• what it returned;
• whether it completed;
• whether a warning or error appeared; and
• whether the final result reflects the tool output correctly.

Do not rely only on a success message from the workflow.

Confirm write actions at their destination

When a scheduled workflow creates or changes something, inspect the actual destination.

This may include:

• the Journal;
• a saved file;
• a folder;
• a connected record;
• a message;
• a report;
• an external service; or
• another supported destination.

Confirm that:

• the expected item exists;
• the content is correct;
• the title or filename is clear;
• the correct record was changed;
• no duplicate was created; and
• sensitive information was not sent to the wrong place.

Review Journal results

A scheduled workflow may write results to the Feluda Journal.

Open Journal and find the relevant entry.

Check:

• the entry title;
• the date or reporting period;
• the content;
• the source information;
• missing details;
• unsupported claims; and
• whether another entry was created for the same run.

Repeated reports should use clear titles.

For example:

Weekly Project Review — 2026-06-08

is easier to identify than:

Weekly Project Review

Use the Journal Monitor when relevant

Journal Monitor can help you watch a selected journal for new entries.

This may be useful for:

• recurring reports;
• long-running scheduled flows;
• monitoring workflows;
• daily summaries; or
• research logs.

The monitor helps you see new activity.

It does not replace reviewing the content itself.

Check for duplicate output

Duplicate output may be caused by:

• the same schedule existing twice;
• overlapping runs;
• a retry after a delayed confirmation;
• two workflows writing to the same destination;
• repeated item names; or
• a schedule being resumed after a replacement was created.

Compare:

• run times;
• workflow names;
• schedule names;
• output titles;
• destination identifiers; and
• recent history.

Pause one or more schedules before investigating repeated duplicates.

Review a missed run

A run may be missed when:

• Feluda was closed;
• the computer was off or asleep;
• the schedule was paused;
• the local model service was unavailable;
• the selected provider could not be reached;
• a required source was unavailable; or
• the schedule was changed near its trigger time.

Confirm what was available at the planned moment.

Do not assume the workflow will automatically recreate every missed result.

Decide whether to rerun a missed schedule

Before rerunning manually, ask:

• Is the result still needed?
• Is the source still valid?
• Would a late result cause confusion?
• Could it create a duplicate?
• Has another schedule already produced the same output?
• Does the destination use dates or unique names?
• Is a person available to review the result?

Use RunFlows for the manual replacement run when appropriate.

Review partial results

A scheduled run may complete part of the workflow before failing.

For example:

• a summary may be created but not saved;
• data may be retrieved but not formatted;
• a Journal entry may be created before a later step fails;
• one branch may complete while another tool action does not.

Treat partial results as incomplete.

Confirm which actions already happened before retrying.

Avoid duplicate retries

A timeout or unclear failure does not always mean that a write action failed.

Before rerunning:

1. inspect the destination;
2. review tool output;
3. check recent history;
4. confirm whether the item already exists; and
5. retry only when the earlier action did not complete.

This is especially important for recurring Journal entries, files, and connected updates.

Review local-model scheduled results

For a local-model run, check whether:

• the local model service was running;
• the correct model was loaded;
• the model returned the full result;
• the response was slower than normal;
• available memory was sufficient;
• another local run was active; and
• the output followed the instruction.

Smaller local models may need clearer instructions and shorter source input.

Review cloud-model scheduled results

For a cloud-model run, check whether:

• the internet connection was available;
• the provider remained configured;
• the selected model was accessible;
• the request completed;
• the result followed the instruction;
• the provider returned an error; and
• the output was appropriate for the data sent.

Test the provider in Workbench when repeated failures appear.

Review conflict warnings

A conflict warning may explain an unexpected result.

Conflicts may involve:

• overlapping run times;
• several local models competing for memory;
• repeated access to the same file;
• two workflows updating the same record;
• several schedules using one limited service; or
• one run continuing into the next trigger.

Review the warning together with the run history.

Change the timing or destination when overlap affects reliability.

Check whether the schedule is still useful

A technically successful schedule may no longer provide value.

Ask:

• Is someone reading the result?
• Is the source still current?
• Is the output still needed?
• Does the workflow match the current process?
• Are the provider and model still appropriate?
• Are repeated warnings being ignored?
• Is the result stored in the right place?

Pause or remove schedules that no longer serve a clear purpose.

Decide when to pause the schedule

Pause the schedule when:

• a run was missed without explanation;
• repeated failures appear;
• the output is inaccurate;
• the wrong branch is selected;
• a tool affects the wrong destination;
• duplicate output is created;
• a provider or model is unavailable;
• local services cannot remain active;
• source information has changed; or
• no one is reviewing the result.

Investigate and test manually before resuming.

Decide when to return to Studio

Return to Studio when the process itself needs to change.

Examples include:

• updating an instruction;
• changing the model;
• adjusting labels;
• changing extraction fields;
• repairing a connection;
• improving an error path;
• changing the output format; or
• adding clearer intermediate output.

Save and test the revised workflow in RunFlows before restoring the schedule.

Decide when to update the schedule

Update the schedule when the process remains correct but its timing or execution settings need to change.

Examples include:

• changing the recurrence;
• changing the day or time;
• updating the timezone;
• changing the starting input;
• adjusting the maximum runtime; or
• preventing overlap.

Review the next planned run after every change.

Record review findings

Keep a simple record for important scheduled workflows.

You may note:

• run date;
• completion state;
• output location;
• warnings;
• errors;
• review decision;
• correction made; and
• whether the schedule remained active.

This helps identify repeated problems.

It also makes ownership and oversight clearer.

Review trends across several runs

One unusual result may be caused by one unusual input.

Repeated problems suggest a deeper issue.

Compare several recent runs for:

• growing runtime;
• repeated warnings;
• missed fields;
• changing classifications;
• provider failures;
• duplicate output;
• missing Journal entries; or
• inconsistent formatting.

Use the pattern to decide whether the workflow, schedule, model, or source needs to change.

Keep a review owner

Every active schedule should have someone responsible for its results.

The reviewer should know:

• when the workflow runs;
• where the result appears;
• what a normal result looks like;
• which warnings need action;
• how to investigate a missed run;
• when to pause the schedule; and
• when to involve another person.

Automatic execution without review can allow quiet failures to continue.

Keep human approval where needed

Human review is especially important when scheduled output affects:

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

Scheduled workflows can prepare summaries, reports, drafts, or recommendations.

Important decisions and high-impact actions should remain reviewable.

A practical scheduled-result review

Use this routine:

1. Open Schedule Manager.
2. Select the schedule.
3. Confirm the expected run time.
4. Check whether the run started.
5. Read the completion state.
6. Review warnings and errors.
7. Inspect intermediate output.
8. Review tool input and output.
9. Confirm write actions at their destination.
10. Compare the final result with the source.
11. Check for duplicates or missed output.
12. Decide whether to keep, pause, update, or remove the schedule.

Reviewing scheduled results confirms that automation is still doing the work you intended.