Skip to main content

Workflows and tasks

GeniSpace turns repeatable business processes into visual workflows. A workflow defines nodes, mappings, branches, and execution behavior. A task is the managed, triggerable resource that runs a workflow or another supported execution mode in a Space.

How the pieces fit together​

ComponentResponsibility
TriggerDecides when and with what input a task starts
Operator nodeRuns a typed, reusable action
Agent nodeUses a task agent for language or structured AI work
Dataset / Datasource nodeReads or writes governed business data
Control nodeBranches, loops, combines, or gates execution
MappingPasses an upstream result into downstream input
ExecutionOne run with a unique execution ID, status, logs, and result

Trigger types​

Manual​

A user starts the task and supplies any required input. Use manual tasks for review-driven or on-demand operations.

Scheduled​

The scheduler starts the task from a Cron schedule and optional date window. Check timezone and next-run time before activation.

Event-triggered​

An event or webhook starts the task. Configure the event source, verification secret, input mapping, and idempotency assumptions.

Manual and event-triggered tasks installed by an industry solution are enabled by default so the solution can be used immediately. Review their connections and permissions before using production data.

Build a workflow​

  1. Create a task in Console and choose its trigger and execution mode.
  2. Open WorkflowStudio and add agent, tool, Dataset, Datasource, or control nodes.
  3. Configure each node's typed inputs and outputs.
  4. Connect nodes and map data paths explicitly.
  5. Define timeout, retries, failure behavior, and environment values.
  6. Save, run with representative input, and inspect every node result.
  7. Activate the task only after success, empty-result, and failure paths behave correctly.

You can also start from AI-generated workflow suggestions, but the resulting nodes, credentials, mappings, and error handling still require review.

Execution and recovery​

Each run has its own execution ID. Use that ID when reading logs or reporting a problem.

  • A redelivery of the same execution is deduplicated instead of creating duplicate work.
  • A different execution of the same task can wait when concurrency is full.
  • Concurrency-limited work uses delayed retry instead of immediate requeue loops.
  • Failed nodes follow the task's retry and failure policy.
  • Cancellation and timeout stop the active execution according to runtime state.

Multi-replica schedulers coordinate through shared execution state and messaging. Users should rely on execution records rather than a particular scheduler or worker instance.

Data and secrets​

Workflow nodes exchange structured values through mappings. Validate required fields and types at each boundary. Use environment variables, ConfigMaps, and managed connections for deployment-specific or sensitive values; do not embed secrets in node descriptions or sample input.

Dataset fields are schema-bound. Datasource behavior depends on its connection and remote system. Test write operations with non-production records first.

Agents inside workflows​

Use a task agent when a step needs language understanding, classification, extraction, or structured generation. Use an operator for deterministic transformations or system actions. The workflow remains responsible for input/output mapping, retries, and downstream decisions.

Interactive-chat features such as free-form follow-up questions are not automatically available to a background task. Design task inputs and error outputs so the execution can complete without an active user unless the workflow explicitly implements a human step.

Monitor and improve​

The task list and execution history show status, start/end time, retries, node results, and errors. During acceptance testing, verify:

  • the intended trigger starts exactly one execution;
  • empty data and partial data take the expected path;
  • repeated events do not duplicate consequential writes;
  • retries are safe;
  • concurrency delay is observable;
  • logs do not expose secrets;
  • the final output has the expected schema.