Skip to main content

Feature Overview

Workflow Orchestration is organized as Home, Workflows, and Executions. Editing happens on the workflow canvas.

1. Home​

Home summarizes runs and keeps approvals that are waiting for you nearby.

  • See counts, success and failure, and a recent trend.
  • Open a recent run, or filter executions by workflow name.
  • Waiting approvals show the workflow name, title, starter, and time remaining. If no deadline is set, the item says so. Open the waiting-for-me tab from here.

2. Workflows​

A workflow is a canvas that starts with a trigger. Save it before a form, schedule, webhook, or NATS message can start it.

  • Maintain workflows by name and open the canvas.
  • Agents, memory spaces, and notification channels referenced by the workflow must be available to the current organization.
  • Later nodes reference trigger input, runtime fields, and earlier node output by picking a field, not by inventing a name.

2.1 Triggers​

The first node is the only start.

  • Form: Design fields. Submitting the form page starts a run. Use it for change requests and other manual starts.
  • Schedule: Start on a frequency. Use it for inspection, reconciliation, and regular reports.
  • Webhook: Give an external caller an entry. Optionally wait for the workflow result before responding.
  • NATS: Subscribe to a platform channel. Use it when Alert Center or another module already publishes the event.

2.2 Condition​

Structured rules choose matched or not matched. Each rule has a left value, a comparator, and a right value from a field or a literal. There is no free expression. Multiple rules combine as match all or match any, up to 10 rules. The canvas does not split into one branch per rule.

2.3 Human approval​

The run waits for a named person. Set a title and description. Only candidates can act. Anyone else can view when they have read access. Approve continues the pass path. Reject requires a reason and takes the rejection path. The approver sees the public context for this run, not the entire internal payload.

2.4 Actions​

  • Job execution: Run a user-written Linux or Windows script on authorized targets and return a JSON envelope. This changes the host. Confirm the target and script first.
  • HTTP request: Call a method and full URL. Address checks and response-size limits apply.
  • Agent: Call an OpsPilot agent available to the current organization. You can add a prompt and knowledge files.
  • Intent classification: Classify input into predefined intents with a model available to the current organization.
  • Memory read: Search a memory space and optionally limit the number of hits.
  • Memory write: Store text produced by this run for a later workflow or agent.
  • Document rendering: Fill a Word or Excel template and produce a controlled download.
  • Notification: Send through email, WeCom, Feishu, DingTalk, or Webhook already configured in System Management. A rendered document can be attached.

3. Executions​

Each trigger creates one execution.

  • States are Queued, Running, Waiting for Approval, Terminating, Outcome unknown, Succeeded, Failed, Timed Out, and Terminated.
  • All lists executions you can see. Waiting for my approval lists approvals you can act on.
  • Detail shows the trigger, starter, node input and output, and the approval decision. A terminated approval remains readable.
  • Stop a test run that is stuck in the middle.
  • A workflow name opened from Home is applied as the execution filter.

Note: Job execution and notification affect hosts or external channels. Prove the condition and approval with a form and test data before enabling a schedule, webhook, or NATS trigger.