Autonomous Work

​

Open Autonomous Work

​

Check prerequisites

• Executor: The Waker is enabled and responds normally. For a WakerFlow, complete at least one successful manual run and verify its human-confirmation nodes and output.
• Model: The Waker's model is available. Select a specific model when repeatability matters, or use Auto to follow the system recommendation.
• Workspace: The Waker can access the required directory or project. A local directory requires the device, QoderWake, and directory to remain available when the trigger fires.
• Capabilities and access: Validate required Skills, connectors, network access, and external accounts in a normal chat first. Do not use a production automation as the first authorization test.
• Task boundary: Keep work that still needs repeated goal clarification in a chat. Prefer WakerFlow for multiple stages, fixed approvals, or human-confirmation steps.

​

Choose a trigger

​

Create an autonomous task

1. Select New Automation.
2. Enter a name in the form “object + action + frequency or source.”
3. Add one or more trigger conditions. A task can contain up to five triggers.
4. Choose an execution method:
   • Waker for stable work owned by one role.
   • WakerFlow for multiple stages, parallel work, fixed handoffs, or structured input.
5. Select the execution object and verify that it is enabled.
6. When the response method is Waker, select Auto or a specific model. If that model becomes unavailable or is removed, edit and retest the task.
7. Write the task description: recurring objective, input scope, output, and prohibited actions.
8. Choose the default workspace, a local directory, or a project.
9. Open advanced settings and configure maximum runs and an end date.
10. Save, run manually, then test the real trigger before enabling production use.

Objective: what every invocation must accomplish.
Input: allowed data, time range, and business objects.
Processing rules: required steps, decisions, and error handling.
Output: response format, file name, destination, or external action.
Acceptance criteria: how to verify the business result, not only a Completed status.
Prohibited actions: content that must not be changed, deleted, published, or sent.

​

Configure a schedule trigger

1. Select Schedule.
2. Choose recurring or one-time execution and set the date, time, and repeat rule.
3. Verify the next-run time and business timezone.
4. For the first test, schedule a run a few minutes ahead; switch to the final cadence only after success.

​

Configure an event trigger

1. Select Event and authorize the event source.
2. Select the repository or object.
3. Choose the event type and source-specific filters, such as create, edit, repository, branch, label, or object scope. Available fields vary by source.
4. Save and create a safe test event in the source system.
5. In task details, check Event Activity or run history. First confirm that the event arrived, then confirm that it started exactly one expected task.

​

Configure scheduled polling, when available

1. Select and authorize the source.
2. Choose the object scope, filters, and polling interval.
3. Define the initial time or cursor so the first run does not process all history accidentally.
4. Use a stable object ID or update time for deduplication.
5. Validate the full path: discover change → create task → advance cursor.

​

Configure an API trigger

​

Create a personal access token

1. Sign in to the Qoder Console and open the avatar or user menu.
2. Go to Personal Settings → Service Integration.
3. Create a personal access token. Use a name that identifies the caller and environment, such as ticketing-production.
4. Copy the token immediately. It is normally shown in full only once; store it in the caller's credential manager or CI secret store.
5. Validate the integration in a test environment, then create a separate production token. During rotation, verify the new token before revoking the old one.

​

Create the task and obtain its endpoint

1. Create an autonomous task and add an API trigger.
2. Select a Waker or WakerFlow, then configure the task description, workspace, and run limits.
3. Save the task. From task details, copy the generated POST endpoint, authentication method, and request example.
4. Protect the full endpoint like a credential. Do not construct it manually or include it in public logs or screenshots.

​

Design the task description and payload

Process ticket {{ticket.id}}.
Severity: {{ticket.severity}}
Issue: {{ticket.summary}}
Output: provide the cause, recommended action, and risks that need human approval.

curl -X POST 'https://api.qoder.cn/v1/qoderwake/automation/invoke/<GENERATED_INVOKE_KEY>' \
  --header 'Authorization: Bearer <YOUR_PAT>' \
  --header 'Content-Type: application/json' \
  --data '{
    "wakeSessionUniqueId": "ticket-1001",
    "ticket": {
      "id": "1001",
      "severity": "high",
      "summary": "Payment callbacks keep timing out"
    }
  }'

• Use {{field}} for a top-level field, {{ticket.id}} for a nested field, and {{items[0].name}} for an array element.
• Field names are case-sensitive. If a path cannot be resolved, the placeholder remains in the task description so the mismatch is visible.
• Strings are inserted directly. Objects, arrays, numbers, booleans, and null are converted to JSON text.
• If the task description has no placeholders, the fixed description remains and the complete request body is appended as input for that run.

​

One-off requests and continued sessions

• Requests from the same user, autonomous task, and wakeSessionUniqueId reuse one session and run in order.
• Omitting the field or changing its value starts a new session.
• This field preserves context; it is not an idempotency key. The caller must still implement retry and deduplication behavior.
• Use distinct values across customers, projects, data permissions, and security scopes to prevent context from crossing boundaries.

​

Verify the result

1. Make the first request with a small, non-sensitive payload.
2. Check the HTTP response. An accepted request only means execution has been dispatched; it does not mean the business task has completed.
3. In Autonomous Work run history, verify that the trigger source is API and inspect the input, executor, workspace, and current status.
4. Wait for completion, then inspect the final response, generated files, and actual result in the external system.
5. After validation, configure the protected endpoint and PAT in the production caller.

​

Troubleshoot API triggers

​

Run a WakerFlow

1. Select a WakerFlow that has already passed a manual run.
2. Review phases and human confirmation nodes.
3. Configure an override method and value for every runtime parameter.
4. Verify required fields and output compatibility.

​

Configure the workspace

​

Advanced settings

• Maximum runs: unlimited or a custom number. The task pauses when the limit is reached.
• End date: never or a specified date. No new trigger starts after that date.

​

Test before rollout

1. Use Run now to validate the executor, task description, workspace, and capabilities.
2. Test the actual trigger with a near-term schedule, safe event, or API request.
3. Inspect trigger source, input, current step, final result, and artifact.
4. Confirm that high-risk actions still pause for approval.
5. Remove test data, then enable the production trigger.

​

Inspect run records

​

Edit, pause, copy, and delete

• The response method and selected Waker or WakerFlow are locked when editing an existing task. To change the executor, use Copy, validate the new task, then pause or delete the old task.
• Retest after changing triggers, model, workspace, permissions, or connectors.
• Copying does not copy the accumulated run count or run history. After copying, verify the name, trigger scope, project, model, and token so two tasks do not process the same event.
• Pausing prevents new automatic triggers but does not stop a run already in progress.
• Not every event-triggered task supports Run now; use a safe event from its external source for validation.
• Before deletion, preserve required run records and stop external systems from calling the endpoint.

​

Common issues