How workflows work

Behavior-level overview of the workflow model.

A workflow in OpCon Continuum is a scheduled, dependency-ordered set of jobs. It defines what runs (the jobs), when it's eligible to run (frequencies, calendars, build settings), in what order (dependencies), and what should happen in response to outcomes (events). Each job runs a job type — the connectors documented separately — on an agent.

Terminology note: in the configuration and runtime model a workflow is represented as a schedule. Treat "workflow" (the UI term) and "schedule" (the underlying term) as the same thing.

What a workflow contains

Part	What it is
Jobs	The units of work. Each runs a job type on an agent and has its own timing, dependencies, and events.
Frequencies	Rules for which days/times a job (and the workflow) is eligible to run.
Dependencies	Conditions that must be met before a job runs.
Events	Actions (commands) fired in response to job outcomes.
Build settings	How and when the workflow is built into a day's run.
Calendars / working days	Holiday calendars and working days that shape eligibility.

Jobs

A job is configured with:

• A job definition — the job type to run (e.g. Run Command, SQL Script) plus its parameters.
• An agent assignment (how the job is placed on an agent — see below).
• One or more frequencies with runtime settings (timing, retries, reruns).
• Dependencies (what must be true before it runs).
• Events (what to do on certain outcomes).
• Properties, tags, custom fields, and flags like disabled and multi-instance.

A workflow itself can also carry named schedule instances — see Schedule instances — so one definition builds once per branch, region, or entity for the same date rather than once per date.

How jobs are ordered: dependencies

A job runs only when all its dependencies are satisfied. There are four types:

Dependency	Satisfied when
Job	A predecessor job reaches the required result — success, failure, or any — optionally on a day offset and a specific frequency.
Threshold	A named threshold reaches a value.
Resource	Enough of a named resource is available (the job reserves it).
Expression	A custom expression renders True. It is re-asked while the job waits; one that can't be evaluated puts the job on hold rather than leaving it waiting silently. See Expression dependencies.

Job dependencies are how the run is sequenced; threshold and resource dependencies coordinate shared state and capacity across jobs.

When jobs run: frequencies and build

Frequencies define eligibility. Each job's frequency carries runtime settings, including:

• Build status — released, onHold, doNotSchedule, toBeSkipped, or disabled.
• Start-time offsets and late-to-start / latest-start / late-to-finish offsets.
• Max run time and estimated run time.
• Failure retries (whether to retry, how many times, minutes between attempts).
• Success reruns (none, recurring instances, or a restart offset).

Build turns the definition into a day's run. Build settings include how many days in advance to build, how many days to build, whether to build on hold, and whether to overwrite on build. Holiday calendars and working days remove non-eligible days.

Where jobs run: agent assignment

Mode	Behavior
Specific agent	Runs on the chosen agent. Secondary, tertiary and quaternary agents can be set, but they are not used: there is no failover. A Universal Agent job goes on its pool's queue, so any agent in that pool can run it.
Pool — least-tasked	Runs once, on whichever agent in the pool asks for work first.
Pool — run-all	The same as least-tasked for a Universal Agent pool: the job runs once.

Responding to outcomes: events

Events fire a command in response to a job outcome. Triggers:

• Job status — a status such as FinishedOk, Failed, LateToStart, LateToFinish or Skipped. See Job and workflow statuses for the authoritative set. The same list offers exceededMaxRuntime, which is a derived condition rather than a status: it fires while the job is still running, and the job's status does not change.
• Job exit description — a comparison against the job's termination description, using EqualTo, NotEqualTo, GreaterThan, GreaterThanOrEqualTo, LessThan, LessThanOrEqualTo, Contains or Range. The comparison is numeric only when every value involved is a whole number; otherwise it compares as text. See Workflow events.
• Job completion expression — a custom expression. Selectable and saved, but it does not run its command in the current build; see Workflow events.

Workflows can also carry schedule-level events.

The run lifecycle (link to runtime)

A workflow is built into a day's run, then jobs run as their dependencies are satisfied, moving through statuses to completion. Operators monitor and act on that run in the Processes view. See the runtime/Processes docs for status meanings and operator actions.

Versions and deployments

Workflows are versioned — each saved change creates a new version, and history can be reviewed or rolled back. A version is deployed to an environment to run there; deployments are tracked, so the same workflow can move from test to production deliberately.

Good to know

• Build on hold is intentional — a workflow built on hold won't run until released; it's not stuck.
• Disabled jobs and doNotSchedule/toBeSkipped build statuses are by design — check the job's frequency settings before treating a "missing" job as a fault.
• Multiple instances means two different things, and both produce more than one row. A job can fan out into several job instances within one run (named with a dot, EXTRACT.US). A workflow with Allow Multi-Instance on builds as several named schedule instances for the same date (named with an underscore, PAYROLL_BRANCH1), each carrying its own property values.
• A job dependency on failure or any is valid design — a downstream job can be meant to run when its predecessor fails.

Related topics

• How connectors work
• How the daily run works (runtime monitoring)