Flow+ course 04 — Recovering safely and maintaining an accountable workflow

Recovery starts by identifying what is uncertain: input validation, saved definition, execution or destination effect. Repeating a button is not a general recovery method. This chapter uses a separate local-recovery example and a controlled-change plan without modifying or executing a workflow.

In this chapter

• Classify the problem before choosing a control
• Compare local recovery with the saved revision
• Reconcile an uncertain effect before retrying
• Read error policy without inventing retries
• Give changes and stopping a responsible owner
• Complete the independent design check

Classify the problem before choosing a control

Malformed input is a configuration problem. An authorization denial is an access boundary. A save response failure leaves persistence uncertain. A provider timeout can leave an external effect uncertain. An expected false condition is not an error at all.

For example, {"ready":false} is complete JSON; {"ready": is incomplete. Changing the node label or running repeatedly cannot supply the missing syntax. Correct the intended value in a separately authorized draft and validate through the supported controls before considering execution.

Do not infer every JSON comparison rule from one example. The historical recovery case compared two empty objects after correcting syntax; it does not establish universal object equality, coercion or array semantics.

Compare local recovery with the saved revision

The separate historical workflow Training - local condition recovery had an unfinished JSON literal corrected to {}. A Save draft attempt returned a network error, but a later inspection showed the corrected graph at saved revision 1. An offered local copy was based on revision 0.

Recover unsaved changes explains that restoring replaces the canvas, not the saved draft or publication. The dialog can offer Keep current canvas, Discard selected copy and Restore onto canvas. These choices have different consequences and should not be treated as routine inspection.

A newer saved revision can already contain the intended correction. Blindly restoring an older copy can bring back stale values. Compare both revision and actual node content; a revision number alone does not prove which configuration it contains.

Keep this recovery example separate from Riverside revision 3. Similar node types do not make them the same workflow or history.

Reconcile an uncertain effect before retrying

Pause new saves or runs while the preceding outcome is unknown. Record workflow, revision, mode, source/input identity, attempted operation, visible response and any operation reference. Exclude credentials and unnecessary personal data from the report.

For a save, reopen the exact saved definition and compare intended fields. For an action, inspect the exact authorized destination or provider result. If the intended effect is already present, do not repeat it just to obtain a cleaner run log.

If the destination is unavailable after a provider timeout, keep the effect unknown and stop retries. The provider may have accepted the request before the response was lost. A manual replacement can duplicate the uncertain automatic operation just as easily as a rerun.

If evidence establishes no effect and the cause is understood, obtain the required authority for a controlled correction or retry. An access denial is not something to bypass with another account, guessed route or broader permission.

Read error policy without inventing retries

The inspected trigger and condition show Stop the run (default) and a helper indicating automatic retries are unavailable for the action. Do not report retries as enabled, configured or tested from an unimplemented control or a generic expectation about automation tools.

False branching and error handling are different. For a valid 4 equals 5 comparison, the false branch is the ordinary result. For malformed JSON, the definition needs correction. For an external timeout, destination reconciliation is needed. These cases should not share one indiscriminate retry rule.

Give changes and stopping a responsible owner

The business owner defines the rule and approves consequences. The operator manages authorized execution. The reviewer checks outcomes. One person may perform several roles, but naming them in a document does not prove agreement or grant communication authority.

A change to trigger, source binding, target, recipient, caller permission, schedule, action or error handling reopens the effect review. Approval for an inert literal comparison does not cover a later message action. Preserve the old and proposed definitions and test expectations before saving a revision.

A controlled stop plan distinguishes preventing future starts from handling work already in flight. Use supported authorized controls and inspect outstanding effects. Do not assume switching activation off cancels a running job, reverses prior actions or recalls a message; those behaviors were not established by the retained evidence.

Complete the independent design check

A candidate says “live checklist readiness,” but uses literal Number 4 equals Number 5, enables calling by other workflows and adds a reminder action. Correct the description to literal practice, remove the unapproved caller/action expansion from the proposed design, and retain the inert two-node graph with no downstream effects.

Prepare true, false, missing-input and invalid-input expectations, a saved-definition readback and a mode-specific result check. The corrected design is ready for owner review, not automatically authorized for save, Test Run, release or deployment.

You have completed the course when you can explain the graph, distinguish literal values from bindings, separate Preview from effect-capable tests, reconcile history with destinations and choose a safe recovery/stop decision. Before using live data or deployment, confirm the supported procedure, authorized effects and independently verified result.