Skip to main content
Employee Resources

WakerFlow

Orchestrate multi-stage work and manage inputs, Wakers, confirmations, run records, and automated triggers.

WakerFlow turns a validated working method into a repeatable executable workflow. Each run collects structured inputs, invokes assigned Wakers by stage, controls sequential work, parallel work, branches, and human confirmation, and returns one defined result. Use it when execution order and delivery format must remain stable across runs—not to make an untested or ambiguous task reliable. Before creating a flow, validate each participating Waker with a small task. Confirm its responsibility, workspace, Skills, connectors, and permissions. A workflow can reliably reuse only a working method that is already clear.

When to use WakerFlow

Working modeBest forMain characteristic
One Waker chatExploratory work with frequent questions and adjustmentsMost flexible; validates whether the task is feasible
GroupSeveral Wakers collaborate toward one goal while a Leader assigns work dynamicallyOpen-ended collaboration and ongoing discussion
WakerFlowStages, dependencies, inputs, and outputs must stay consistent across runsExplicit execution path with parallelism, branches, and human gates
Autonomous WorkA stable task starts on a schedule, event, or API callControls when work starts; the target can be a Waker or WakerFlow
A practical progression is: validate one Waker in a chat, validate multi-role work in a Group, then formalize the stable steps as a WakerFlow. A single-step task with one Waker and no structured input usually does not need a workflow.

Open WakerFlow

Path: left navigation → Capabilities & Resources → WakerFlow. Use the management page to create a flow, review participating Wakers, open an existing flow, and maintain automated triggers.
Open WakerFlow from Capabilities & Resources, then create or select a flow
 Before editing an existing flow, review its description, inputs, assigned Wakers, and recent runs. The name alone does not define the behavior; input fields, execution nodes, and the final return value do.

Create a flow

  1. Select New WakerFlow to open an empty canvas.
  2. In the chat panel, describe the goal, changing inputs, stages, Waker assignments, error handling, human confirmation, and final output.
  3. Wait while QoderWake generates the script, stages, and Waker nodes. Do not submit the same request repeatedly.
  4. Give the flow a clear name and a description that explains both its scope and exclusions.
  5. On the canvas, verify stage order, parallel relationships, and the Waker assigned to every node. Then check the script and run configuration.
  6. Save and run a manual test before adding an automated trigger.
A useful creation request can follow this structure: 
Create a meeting-minutes workflow.
Inputs: transcript, meeting topic, and date.
Stage 1: extract conclusions and action items, owners, and due dates in parallel.
Stage 2: consolidate the results into Markdown minutes.
Constraint: use only information present in the inputs; do not invent decisions.
Outputs: complete minutes, a structured conclusion list, and an action-item list.
When the generated result needs correction, change one type of issue at a time—for example, make two extraction nodes parallel, assign the review node to a QA Waker, or add a confirmation before publishing. Changing nodes, inputs, and outputs together makes validation harder.

Understand the editor

AreaPurpose
CanvasReview stages, Waker nodes, parallel branches, and dependencies
ScriptInspect and edit the executable definition, inputs, outputs, and logic
Chat panelCreate or revise the flow with natural language and review generation progress
Run configurationReview the fields required for a manual run
Version historyCompare and restore saved workflow versions
Run historyInspect inputs, node states, and results for each run
The canvas explains the structure, but the script is the executable definition. After changing the script, confirm that the canvas and run form still match it.
Review stage order, parallel Waker nodes, and dependencies on the canvas

Revise a generated flow

  • Select a stage or Waker node, then describe the exact change in the chat panel, such as “change only stage 02 and pass its review result to stage 03.”
  • For a structural change, state which stages must remain, which nodes are added or removed, and whether inputs and outputs must remain compatible.
  • After editing the script directly, resolve parser errors first, then recheck the canvas, run configuration, and final return.
  • Save a version after each testable group of changes instead of stacking many unverified revisions.

Configure run inputs

Define only values that change between runs as input fields. Give every field a stable name, type, description, required status, and a safe default where appropriate.
SettingGuidance
Field nameUse a stable identifier so automated mappings do not break later
DescriptionExplain what to enter and the expected format
RequiredEnable when the flow cannot complete without the value
DefaultUse only for safe values that remain valid over time
Sensitive dataNever store passwords, tokens, or customer data as ordinary defaults
Changing an input field can affect the manual run form and every Autonomous Work item that invokes the flow. Review all callers after an input change.

Configure stages and Wakers

  • Stage: a business step such as collect information, analyze, or generate report.
  • Waker node: a node that performs a specific task. Assign one available Waker with a clear responsibility, and define the node's input, work, and deliverable.
  • Parallel: use when work items are independent.
  • Sequential: use when a later step depends on an earlier result.
  • Branch: select a path from structured conditions and include default and error handling.
  • Human confirmation: pause before code merges, releases, deletion, external publishing, or other critical actions.
Check each Waker node before saving:
ItemWhat to verify
Node nameThe expected deliverable is immediately understandable
Task instructionRequired workflow inputs and upstream results are referenced
Assigned WakerResponsibility, runtime, and availability match the task
WorkspaceThe correct project is available and parallel nodes will not write the same file
Downstream resultThe output is structured enough for the next stage to consume
When several Wakers share a directory, define one primary editor and keep the others read-only or review-focused. Parallel writers can overwrite the same file. A stage can contain several parallel Waker nodes; use a later stage for consolidation instead of allowing multiple nodes to edit the final artifact.

Define the output

The final return should deliver what the business user needs, rather than internal execution logs. Include:
  • business conclusions or structured fields;
  • accessible links or locations for generated artifacts;
  • validation results, unresolved issues, and required human actions.
If an API or downstream automation consumes the output, do not rename fields casually. Update every caller and document compatibility when the structure must change. Return the final result explicitly from the workflow script. A run can still report success without an explicit return, but its final result can be null; content intended for delivery must not exist only in business logs.

Run manually

  1. Select Run and complete all required fields.
  2. Check whether defaults are appropriate for this run.
  3. Confirm that the assigned Wakers, project, model, and connectors are available.
  4. Start the run and open Run history to track the active stage and node.
  5. When confirmation is requested, read the context, impact, and choices before deciding.
  6. After completion, inspect the final result and open the actual artifact.
Complete the structured parameters required for this manual run
 Object and array inputs must contain valid JSON. Missing fields, malformed JSON, or a type mismatch prevents submission or produces a validation error. Use the run state to decide the next action:
StateMeaningNext action
Queued / RunningThe run exists and is progressingIf it stops changing, inspect the active node and service state
Waiting for inputA human answer or confirmation is requiredOpen the run and respond; do not treat it as a failure
CompletedThe workflow script finishedValidate the final result, required fields, and actual artifact
Completed · N failuresThe workflow ended, but one or more nodes failed or returned a failure resultOpen failed nodes; do not approve the run from “Completed” alone
Failed / TerminatedA node failed or the run was canceledStart with the first abnormal node, fix the cause, and run again
The first validation should cover a normal input, a missing field, an invalid input, a human-confirmation path, and one Waker-node failure.

Understand configuration, logs, and results

InformationSourceCompletenessUse
Run configurationSubmitted fields and defaultsCompleteReproduce the run input
Configuration summarySystem-generated overviewMay be summarized or truncatedQuickly verify key settings
Node stateWorkflow engineExecution statusLocate running, waiting, successful, or failed nodes
Business logExplicit workflow or Waker outputOnly what the flow chose to logFollow business progress and key decisions
Waker chatActual Waker sessionNode-level contextInspect inputs, tool activity, and responses
Final resultWorkflow return valueOfficial returnDeliver the run outcome
A configuration summary is not the complete input, and a business log is not the complete output. Use the run configuration for inputs, the final result and artifact for delivery, and the Waker chat for node-level troubleshooting.

Handle waiting and failures

Waiting for input is not a failure. A flow can be waiting for a required value or human decision. Investigate only when a node reports failure or the flow terminates unexpectedly. Terminate stops later execution but does not undo files already written, messages already sent, or completed external actions. Decide whether manual cleanup or rollback is required before terminating. Retry can reuse nodes already completed in the same run. Retry after a transient failure only when inputs and the script are unchanged. If you changed an input, workflow script, or node configuration, start a new run so it does not inherit stale results. Start with the first abnormal node:
  1. Check the input received by the node.
  2. Confirm that the Waker assigned to the node is enabled and its device is online.
  3. Check the workspace, Skill, connector, and permission.
  4. Confirm that script branches cover the current input.
  5. Fix the issue and rerun the same test input.
Do not rely only on the last summary message; later errors often originate from an earlier input or node failure.

Recognize “Completed with failures”

A workflow script can catch a node error and continue. The overall state may therefore be Completed while the run also shows an N-failure badge. This means the engine finished, not that every business step succeeded. Validate the overall state, failure count, final return value, and actual artifacts together. Open a failed Action node and inspect its name, error summary, error details, input parameters, and available output. Failures in Waker nodes or subflows can also contribute to the count. If the page does not expose full details, open the corresponding Waker chat or subflow run.

Improve from a failed node

When a failed Action node offers Improve workflow from this failure, it carries the node error and run context into an editable draft. It does not send the draft or change the workflow automatically:
  1. Review the referenced node, error, and run; remove sensitive input that should not be included.
  2. Add the expected behavior, allowed stages, and acceptance criteria.
  3. Send the request, review the proposed change, and save a new version.
  4. Rerun the same input and compare the failed node and final artifact.

Use version history

Save a recognizable version after every meaningful change and record the reason in its description.
  • Run a fixed regression sample after small changes.
  • Review all Autonomous Work items and API callers after input or output changes.
  • After a restore, reconnect Wakers, projects, or connectors that were removed or replaced.
  • Version history records configuration; run history records execution.

Improve the flow from a run record

Switch to Run history to see the selected run's stage and Waker-node states on the left and the chronological run list on the right.
Compare stage and node status with the chronological run history
  1. Select the run you intend to investigate instead of assuming the newest run is relevant.
  2. Start with the first failed or unexpectedly waiting Waker node and open its result and chat.
  3. Compare run configuration, configuration summary, business log, and final result to identify an input, task instruction, resource, or workflow-structure problem.
  4. Use Improve workflow from this run for structural issues. For one failed Action node, prefer the node-level improvement entry. Both create an editable draft before anything is submitted.
  5. Save a new version and rerun the same input to compare node states and final artifacts.
Do not rewrite the entire flow merely because one result uses weak wording. Fix the earliest input mapping or Waker node that diverged, then keep the stable downstream structure.

Configure automated triggers

WakerFlow can be the execution target of Autonomous Work. For a schedule, event, or API trigger, select Run WakerFlow and map every required workflow input to a fixed value or trigger field. This page owns workflow structure, input/output design, and failure diagnosis. Configure trigger timing, run limits, and API access in Autonomous Work. Complete a manual run first, then validate the real trigger with a limited test. If the flow contains a human-confirmation node, an automated run pauses at that node; it does not bypass the decision.

Rollout and maintenance checklist

  • The name, description, inputs, and outputs are understandable to a new user.
  • Every Waker node has one clear responsibility and an available assigned Waker.
  • Parallel nodes cannot overwrite the same file or external object.
  • High-risk actions have human confirmation and a workable rollback plan.
  • Normal, invalid, and empty inputs have been tested.
  • Retest after changing inputs, scripts, Wakers, connectors, or permissions.
Get Started
Work Management
Employee Resources
Best Practices
Configuration
Support