The Processes page (runtime)

For what each status/action means, see Job and workflow statuses and Operator response guide.

Task walkthrough: Work the Processes page. This page is the full configuration and troubleshooting reference.

Processes is the operator's daily-run screen: the live view of workflow instances and their jobs for the selected environment. It is environment-scoped (the environment picker sits above it) and breadcrumbs to a single Processes crumb.

Two views

A view toggle switches the body between two views; the choice is URL-synced, so a reload returns to the same view. Job View is the default.

View	Shows	Notes
Job View	Every job instance in the run	Default. All column headers sort.
Workflow View	Workflow instances (the containers)	No "Built" column. Filters by coarse status groups, not raw statuses (see below). "View in Workflow view" links from a job.

The page also hosts the Schedule Workflow action (schedule a workflow into the run) and a manual refresh. The dialog's Workflow list is sorted alphabetically by name, so you can scan it for the one you want.

An expanded row moves to the top while it is open. Opening a row lifts it directly under the column headers, scrolls the list up so it is in view, and gives its panel the full height of the visible table — the rest of the rows continue below the panel in their usual order, and collapsing the row returns it to its place. Earlier builds sized the panel to whatever space the other rows left over, so on a full page a workflow diagram was squeezed to its minimum and changed height as the row count changed.

Only the display order moves. Your sort and your filters are untouched, so the row order you see below the panel is the order you chose.

Getting around the diagram

Both views render the same run diagram, and its controls are grouped in one panel at the bottom-right — the minimap, with the view controls in a row directly beneath it. Earlier builds scattered them: the zoom controls bottom-left, the minimap bottom-right, and the orientation toggle as a third overlay of its own.

Control	What it does
Minimap	The whole run in miniature, with your current viewport marked. Drag it to pan and scroll it to zoom, so you can cross a large run without touching the canvas.
Zoom in / Zoom out	Step the zoom level.
Fit view	Zoom and pan so the whole diagram is on screen.
Orientation	Switches the layout between top-to-bottom and left-to-right.

Every control carries a tooltip and is reachable by assistive technology.

Good to know

The Job view diagram dims every card except the one you are focused on. Those inactive cards are now solid rather than see-through: they were drawn at 40% opacity, which let the dependency lines behind them show through the card and made both hard to read. A failed card keeps its error ring while inactive, greyed with the rest of the card rather than staying full-strength red.

Scheduling a workflow across a date range

Schedule Date takes a range, not just one day, and opens on today. Building a workflow for a week is one pass through the dialog instead of seven, each of which used to mean re-picking the workflow, the schedule instance, the property overrides and both check boxes.

How much you can ask for	Up to 31 days in one submission. A longer range is refused in the form — "Select at most 31 days — this range covers 45." — and Schedule stays disabled until it fits. Building further ahead than that is what the automatic daily build is for.
How it runs	One build per date, in sequence. Each build expands its own container hierarchy and reads the deployment list for its own date, so a month of them at once would be a self-inflicted rate limit. The date count and the range appear under the field — "5 dates, 2026-10-01 through 2026-10-05 — one build per date."
What the Workflow list offers	The workflows deployable on the range's first date. Deployment windows are per-date, so intersecting across the range would hide workflows you can legitimately build on most of the days you picked. A workflow that only becomes deployable later in the range is not listed — move the start date to reach it.
Property overrides and both check boxes	Apply to the whole range. Every date resolves the same deployment, so the instance names, the declared override fields and the instance list in the confirmation hold for all of them.

One refused date no longer abandons the rest. A range typically fails on exactly the dates a deployment does not cover, so each date is reported with its own reason rather than the whole submission reading as nothing was built. The dialog closes only when something was built and every date answered; anything else keeps it open with the per-date report in it, so you can tick Overwrite Existing and retry without re-entering the form. A range that landed reports as "Scheduled 3 of 5 dates", naming the dates that got nothing and, where instances failed, which instance failed on which date.

One tick of Overwrite Existing applies to every date in the range

The check box's hint and every variant of its confirmation state the date count beside the instance count, because the two multiply: a fan-out of five instances across 31 days is 155 runs deleted by one tick. Read the count in the confirmation before you accept it. While the range is building, the confirm button carries the progress — Overwriting… (4 of 31) — since the confirmation, not the form behind it, is the only surface you can see for the whole loop.

Whatever the range, the warnings that belong to the dates that did build are still raised: container jobs the build left with nothing to run, and instances an overwrite irreversibly deleted. Both appear on no count and in no instance list, so a range refused on its last date no longer discards them.

Reading a named schedule instance

When a workflow builds as several named schedule instances, both views show the composed name Workflow_Instance — PAYROLL_BRANCH1 — in the workflow column, so two branches of one workflow on one date are distinguishable at a glance. A workflow that builds no named instance shows the bare workflow name.

• The Workflow View adds an Instance Name filter beside Workflow Name. It is a partial, case-insensitive match and it excludes runs with no instance name, so leaving a value in it hides every single-instance workflow. Both the filter and the composed name are saved with a filter preset.
• Sorting by Workflow Name orders by the bare name, so an instance's siblings sort as peers.
• Following a job back to its workflow narrows the workflow list to the instance you came from.
• The workflow details panel shows an Instance Name row only for a named instance.
• An instance built more than once for the date carries a four-digit run suffix — PAYROLL_BRANCH1$0002 for its second run. The first run has no suffix. The suffix appears everywhere the composed name does, including the Close and Delete confirmations and the result message after a bulk action, so an action on one run is never reported as an action on another.

note

A schedule instance is named with an underscore (PAYROLL_BRANCH1). A job that fans out into several instances within a run is named with a dot (EXTRACT.US). Both can appear in the same run.

Status-group filters

Both views filter by status groups rather than raw statuses, each group expanding to its constituent statuses for the query.

• Workflow View offers Building, Waiting, In Process, Held, Completed, Cancelled. UNKNOWN is intentionally ungrouped. See Job and workflow statuses.
• Job View offers Held, Waiting, Running, Succeeded, Failed as its primary groups, with Pending Term, Fixed, Skipped, Cancelled and Under Review under More. Fixed and Skipped are new as standalone choices — both were previously reachable only folded into Succeeded, which left no way to list a run's skipped jobs. See Job status-group filter.

Showing only jobs with errors

The Job View's Only show tasks with errors switch now covers every failure status: Failed, Marked failed, Initialization error, Missed start time and Under review, plus the pending-term form of each. It previously matched only Failed and Under review, so a job that failed to initialize, one an operator had marked failed, and one that missed its start window were all invisible while the switch was on — and any failed job was invisible for the second or so it spent in pending-term.

Container jobs with no sub-schedule to run

A Workflow Container job whose sub-workflow couldn't be built during the build is marked with a warning icon — beside the job name in the Job View list, and beside the status badge on the workflow diagram in either view. Hovering it gives the reason the build recorded. The job's status is an ordinary waiting one, so without the marker a container that will run nothing looks exactly like one that will.

Scheduling a workflow that leaves any container empty also raises a warning banner above the list, listing each one with its owning schedule instance and the reason. It has no timer and closes only when you dismiss it.

The marker is not shown while the diagram's timeline is replaying an earlier point in the run: the statuses shown there are reconstructed as of that point, while the reason behind the marker is read live, and the two must not be judged against each other.

See Workflow Container job for what the banner says, which statuses carry the marker, and which actions clear it.

Predecessors outside this run

The workflow diagram is drawn from one workflow instance's own jobs, so a predecessor that is not one of them used to have nowhere to appear — the dependency was real, the job was waiting on it, and the canvas showed a job with no incoming arrow at all.

Such a predecessor is now drawn as a dimmed stand-in card with an arrow into the job that waits on it. Two kinds qualify: a job in another workflow, and a job in this workflow on a different schedule date.

The card carries what the dependency stored, which is all a label needs:

On the card	Meaning
Top line	The workflow the predecessor belongs to.
Name	The predecessor's job name. A trailing * means the dependency matches on a name prefix, so more than one job could satisfy it.
Third line	The schedule instance the dependency names, when it names one.
-1d, +2d	The Days Offset — which day's run, relative to the waiting job's own schedule date. Blank means the same day.
Any day	An any-day conflict — the relation is not confined to one date, which is why no offset is shown.

A stand-in carries no status badge, deliberately: nothing on this canvas resolves it against the instance it names, so there is no state to show. Whether the waiting job is still blocked is carried by the arrow, not by the card.

Several jobs naming the same predecessor share one stand-in, with an arrow each.

Thresholds, resources and expressions on the diagram

The run diagram draws more than job boxes. A job's threshold, resource and expression dependencies each appear as their own card, with an arrow into every job that depends on them — the same cards the Workflows canvas uses, so the two views agree.

Card	What it stands for	What the arrow is labelled
Threshold	One named threshold	The comparison that job requires — ≥ 5
Resource	One named resource	The units that job needs — 2 units
Expression	One expression	Nothing — an expression is satisfied or not

One card per threshold name, resource name or expression, shared by every job that depends on it, so a resource ten jobs contend for is one card with ten arrows rather than ten copies.

An arrow is solid green when that job's requirement is satisfied and dashed grey when it is not — the same treatment job-to-job arrows already use.

While a job waits on a requirement, every arrow of that kind reads unsatisfied

A job sitting in a threshold, resource or expression wait has all its arrows of that kind drawn unsatisfied, even one whose condition is actually met. A job needing two resources shows both as unsatisfied while it waits, because what the diagram knows is that the job is still held by that kind of requirement, not which one of them is holding it. Over-reporting a block is the safer direction: you are told the job is waiting, and reading both resources is the next step.

Current values are not drawn. The card names the threshold or resource; what it stands at right now is on the Toolkit page, not here.

A job blocked on a dependency that cannot resolve

A job waiting on a predecessor that will never arrive used to look exactly like a healthy waiting job. It now carries an orange warning icon in the bottom-left of its card, and the tooltip names each predecessor and why it cannot resolve.

Two cases raise it:

• The predecessor is absent from the run, and the dependency is a Requires — which waits indefinitely. An After dependency on an absent predecessor proceeds, so it is not marked.
• The predecessor resolved to the wrong instance of a multi-instance job, which waits indefinitely whatever the dependency type.

The marker follows the job's status, not just the stored reason, so it clears once the job is past its dependency waits — running, finished, waiting on a machine, or waiting to start. Force starting, cancelling or marking the job does not leave a stale warning behind.

Filters and search

Each view has a filter bar across the top and a filter box in some column headers. Which filter lives where follows what it narrows: the bar holds filters over the whole run, and a filter that narrows one column sits in that column's header.

View	Filter bar	Column header filters
Job View	Choose Hours, Date(s), Tag, Status(s), Saved Filters, and a Show jobs with errors switch	Workflow, Job, Agent
Workflow View	Choose Hours, Date(s), Status(s), Saved Filters	Workflow

The Job View's columns are Date, Workflow, Job, Status, Return Code, Job Type, Start, End, Duration, Agent and Priority. The Workflow View's are Date, Workflow, Status, Start and End. Columns truncate with a tooltip carrying the full value, and the filter bar stays on one line, its controls shrinking as the window narrows rather than wrapping.

Status(s) and Tag report their selection as a one-line summary rather than listing every choice. Saved Filters carries a funnel icon, and the badge showing how many filters are applied sits under the button so selecting it never moves.

Two filters were retired, and old links still work

Job Type no longer has a header filter on the Job View, and Instance Name no longer filters the Workflow View. A saved filter or bookmarked URL that carried either one still loads — the retired value is ignored and cleared from the address rather than narrowing the list invisibly.

Changing page, sort, search, or a filter clears the current row selection (so a bulk action never acts on rows scrolled out of view).

Filtering by date and time

Date(s) takes more than one day. It opens on today, and its menu offers three ways to choose, plus a time window:

Mode	What you get
A single day	That schedule date
Date Range	Every date from one day to another
Select individual Days	Specific, non-contiguous days — select a day, and add or remove more with Ctrl/Cmd and select
Time Range	A start and end time applied to each selected day

You can type into the field instead of using the calendar — 05/29/2026, May 29, 2026, a range with - or to, or a list of days. Text that is not a valid date stays in the field with an error rather than being committed.

A Time Range narrows to jobs and workflows that started inside that window on each selected day, in your own local time. An end earlier than the start runs past midnight into the next day. A missing start means 00:00:00; a missing end means 23:59:59. Rows that have not started yet never match a time range.

Two limits worth knowing:

• A time range covers at most 31 days. Beyond that the field shows an error and the time range is not applied — the dates still are.
• Time Range and the Choose Hours preset exclude each other. Choosing a preset clears the days and the time range; changing the date field clears the preset.

Reordering the columns

Drag a column's label to move it, or reach it with the keyboard: tab to the label, pick it up with Space or Enter, move it with the Left and Right arrows, drop it with Space or Enter, or abandon the move with Escape. The sort control and the header's own filter box never start a drag, so selecting either still does what it did.

The order is remembered in this browser between sessions, per view — it is a personal preference, not part of the URL, so sharing a link does not carry it. Reset Column Order, under Schedule Workflow, puts the visible view back to its default and is unavailable while that view is already in default order. Resetting also opts the view back into any future change to the defaults.

The expand, selection and row-action columns are not reorderable: they stay first and last.

Name filters take a * wildcard

The name filters in the column headers — Workflow, Job and Agent — accept * as a wildcard, as Classic's do, and each carries a hover hint saying so. Where you put it decides what the filter means:

What you type	What it matches
payroll	Any name containing payroll — the behaviour with no *, unchanged
payroll*	Names starting with payroll
*payroll	Names ending with payroll
pay*roll	Names starting with pay and ending with roll
*pay*roll*	pay somewhere, then roll somewhere after it

Matching ignores case throughout. A value with no * in it still matches anywhere in the name, so nothing you have saved changes meaning.

? is literal — it matches a question mark, not a single character.

Good to know

_ and % are now literal too. They used to leak through as wildcards of the underlying query: a filter of JOB_01 quietly matched JOB-01 and JOBX01 as well, and a single % matched everything. Both are taken as the characters you typed, so a name that really contains one is now findable.

A name filter is capped at 1024 characters — well above the longest name any object can have, so an over-long value from a saved report filter just matches nothing rather than failing. Beyond that, or a value that isn't a single piece of text, is refused.

Filtering by tag

The Job View's Tag filter takes several tags at once, and a job matches if it carries any of them. The list offers the tags actually present on jobs in the dates you have selected, with a search box, so you pick from what is there rather than typing from memory.

You can also filter on a pattern: type one using * or ? and press Enter to add it as an entry alongside the exact tags. A saved filter or URL carrying a single tag pattern from an earlier build loads as one such entry.

The exact-name parameters a deep link can carry are unaffected. The Job History report's Workflow, Job and Agent name filters reach the same matching, so * works there too — see Reports.

Clearing filters

Two actions reset the view's filters back to their defaults rather than leaving stale criteria applied:

• Clearing or deselecting a saved filter. Selecting a saved filter applies its criteria; clearing it puts the filters back to default instead of leaving the saved filter's criteria behind with nothing indicating they're still in force.
• View in Job View. Following a workflow into the Job View clears whatever filters were active, so you see that workflow's jobs rather than an intersection with a filter set for something else.

Moving between the two views

Both directions are a push: the view you land on is filtered down to what you came from, and the one row you asked about is opened.

From	Action	What the view you land on does
A job's detail	Workflow →	Switches to the Workflow View, filters to that workflow instance, and opens its row.
A job node on the workflow diagram	Node menu → View in Job View	Switches to the Job View, seeds the Job Name search and the Workflow Name and Date filters from that job, resets to page 1, and opens that job's own row.

The job node push identifies the job, not just its name. A job name is unique only within a workflow instance, and the Job Name box matches anywhere in a name unless you anchor it with a * — so the same name can belong to jobs in other workflows, to a multi-instance job's fan-out, or to a longer name the search also matches. Earlier builds seeded the job-name search and nothing else, which landed you on a list of rows with nothing saying which one you had clicked. The workflow and date filters narrow it, and the row being open is what identifies the job when they can't — two runs of one workflow on one date have no filter that separates them.

The seeded date now lands on the Date control's own range, so you can see it and change it. Earlier builds set a date axis the control doesn't render, which filtered the list invisibly.

Editing the seeded filters hands the view back to you

The seeded Job Name is typed into the box rather than forced, so changing it — or clearing it to widen the list — abandons the rest of the push, including the row that was about to open. That is deliberate: the filter bar keeps telling the truth about what is applied.

A deep link into the Job View — the dashboard's failed-jobs widget, or a URL you saved — carries only what its own address says, so it seeds no workflow and opens no row.

Row actions (single job)

Each row has an action menu offering only the actions the job's status accepts — the status-gated set (see Job statuses and actions): Hold, Release, Cancel, Kill, Restart, Force Start, Skip, Mark Fixed, Under Review, Mark Finished OK, Mark Failed. Cancel applies to a job that hasn't started running; Kill is its running-job counterpart. A running container job offers Kill only.

Kill stops the process only on a legacy (LSAM) agent, through its relay. On a job running on a Universal Agent, Kill is accepted and the job's status records it, but nothing reaches the agent: the process keeps running until it ends on its own or reaches the agent's fixed one-hour limit. See How a Universal Agent takes and runs work.

Row actions (single workflow instance)

A Workflow View row offers the actions its own status accepts — Hold, Release, Start, Close — plus the ad hoc Add Job and Delete items below. The per-status set is in Job and workflow statuses.

On a COMPLETED row, Hold, Release and Start reopen the finished run, so the row menu treats them differently from an action on a live instance:

• They confirm first, in a Reopen Completed Workflow dialog that names the instance (including its $nnnn run suffix) and says where the action will leave it. The alternative is labelled Leave Completed.
• They are unavailable on a completed nested sub-schedule, which can't be reopened. On any other status a nested sub-schedule's ordinary lifecycle actions are offered as normal.
• Any other status is unaffected: those actions fire directly, with no confirmation, exactly as before.

A failed Hold, Release or Start reports on a page-level alert; Close reports inside its own dialog.

Bulk actions

Both views support multi-row selection, per row or all at once. A Bulk actions button appears once 2+ rows are selected. Its menu is the intersection of the valid actions across the selection (an action shows only if every selected row accepts it) plus Delete; actions run as a batch and a confirmation message reports the result in both Job View and Workflow View.

Two carve-outs on a Workflow View selection, both because status alone doesn't decide whether Hold, Release and Start are legal on a COMPLETED row — those three reopen a finished run:

• If any selected row is a COMPLETED nested sub-schedule, Hold, Release and Start are dropped from the menu. A sub-schedule can't be reopened, so offering them would fail part of the batch.
• If the selection contains any COMPLETED row at all, those three actions confirm first, naming how many completed instances will be reopened — the same treatment Delete already gets. A mixed selection is the easy way to reopen a run without meaning to.

Delete (jobs and workflow instances)

Delete is a manual intervention (soft-delete), not a lifecycle action, surfaced ad hoc rather than in the action set:

• Delete a job instance drops the dependency edge from every dependent (same- and cross-workflow) so downstream jobs re-qualify against their remaining conditions instead of hanging on a predecessor that no longer exists; dropped edges are persisted so a restart doesn't re-block them. Rejected while the job is in a pending-termination status.
• Deleting a container job takes its nested sub-workflows with it. A container job is deleted together with the sub-workflow it holds and every level below that, so no nested run is left behind pointing at a job that no longer exists. Each nested instance has to pass the same checks a workflow-instance delete applies — a deletable status, and no running or pending-termination job inside it. If any level fails, the whole delete is refused and nothing is removed, so a container is never half-deleted. Dependents of the nested sub-workflows re-qualify as they would for an ordinary delete, including those that named a nested job by name rather than resolving it.
• Delete a workflow instance soft-deletes the instance and cascades to its child jobs (parity with job delete), tearing them out of the runtime dependency graph and re-qualifying surviving cross-workflow dependents. Allowed only from a deletable status — WAIT_TO_START, WAIT_CONTAINER_JOB, ON_HOLD, PARENT_HOLD, COMPLETED, CANCELLED — and blocked while actively running (BUILDING, IN_PROCESS, STARTED_BY_USER, UNKNOWN), or when a child is running/pending-term.

Add a job to a workflow instance

An operator can add a job that is defined on the workflow to a running (or resident) instance of that workflow — the equivalent of the legacy Add Jobs wizard ($JOB:ADD / $JOB:ADDHLD), re-shaped to OpCon Continuum's synchronous in-process model. The trigger is an Add Job item in the Workflow View row action menu; it opens the Add Job to Workflow Instance dialog and posts to POST /workflow-instances/:workflowInstanceId/jobs.

Candidate list. Candidates come from the live workflow definition, not the instance's frozen config snapshot — so a job added to the definition after the instance was built still appears. The dialog shows a sorted radio list of every defined job, each badged with its disposition:

Disposition	Badge	Selectable?
addable	(none)	Yes — not currently in the instance
replace	Will Replace	Yes — already ran and is in a terminal status; adding replaces it
active	Job is Active	No — already present in a non-terminal status
no-frequency	No Frequency	No — the job defines no frequency, so it can't be instantiated

A job whose Disabled switch is on also carries a Disabled badge, in addition to whichever disposition badge applies. It is still selectable, deliberately: adding it by hand is the way to run a parked job once, and the build never would have.

Multi-instance, workflow-container and run-on-all jobs are all supported — see below. The backend re-fetches the deployment and stays authoritative on whether a job is actually addable.

Dialog inputs.

• Frequency — a choice is required when the job defines more than one; auto-selected when it defines exactly one.
• All Instances / Instance — shown only for a multi-instance job, and one of the two is required. See Adding a multi-instance job.
• Instance Properties — a property grid pre-filled with the job's default property set. Sent to the backend only if edited; an untouched add keeps the deployment's (environment-transformed) property values. A property marked encrypted but carrying a plaintext value is rejected.
• Add on Hold — a toggle. Released → the job lands at WAIT_START_TIME (so it runs regardless of whether its frequency qualified for the date); on hold → ON_HOLD.
• Reason — optional free text recorded on the audit history entry.

Duplicate gating. A job already active in the instance rejects; a job present only in a terminal status is replaced (the dialog warns first, then soft-deletes the prior instance and re-points its dependents onto the new job).

A replacement is one transaction: the previous run is not deleted unless the new job is written in its place. And the previous run is re-checked as still terminal inside that transaction, so if somebody restarted it between the dialog reading it and your Add, nothing is written and the add reports that the row changed — restarted, or replaced by another add — rather than overwriting a run that is live again.

A dependent the replacement could not be wired to keeps waiting. Re-pointing dependents onto the new job covers the ones in the same workflow. A dependent in another workflow, or one whose re-point did not take, is left waiting rather than released:

• A cross-workflow dependent re-resolves onto the replacement by name, so it picks the new job up on its own.
• A same-workflow dependent that could not be re-pointed stays unsatisfied, and keeps waiting until you act on it.

Either way the dependent holds rather than running early. Earlier builds dropped these dependencies instead, so a dependent that should have waited for the replacement ran straight away — and because the stripped dependency was saved, a restart did not put it back.

Adding a multi-instance job

A multi-instance job runs once per property group, under the projected name <job>.<instance>. Adding one offers a choice:

Control	Adds
All Instances	One row per instance the job defines — the same fan-out, under the same projected names, that a build would have produced
Instance	Just the one you name from the list of the job's instances

Each instance is judged and reported on its own. That is the point of the fan-out, and it has three consequences worth knowing:

• Duplicate gating is per instance. EXTRACT.US being active does not refuse EXTRACT.EAST — they are independent runs.
• One instance failing does not block the rest. An All Instances add reports an outcome per instance, so a conflict or a failure on one still adds the others.
• A job that defines no instances is refused rather than added under its bare name, and an instance with no name, or a duplicate name, is refused for the same reason: the projected name is what the rest of the run identifies it by.

A projected <job>.<instance> name longer than 255 characters is refused up front rather than failing on the write.

Its disposition badge is read per instance, too. A multi-instance job is never in the instance under its bare name, so the dialog reads each instance's own <job>.<instance> row — the exact name the add will materialize. A job with one instance still running shows Job is Active, one whose instances have all finished shows Will Replace, and the replacement confirmation names the instances it covers. Earlier builds looked for a row under the bare name, which never exists, so a multi-instance job was always badged as freely addable and the Will Replace warning never appeared. If the job also runs on each agent of a legacy agent group, the per-agent <job>.<instance>__<agent> rows are read the same way.

Adding a multi-instance job from a $JOB:ADD event

A $JOB:ADD / $JOB:ADDHLD event names a job but has no way to name an instance, so it cannot make the choice the dialog asks for. Earlier builds simply refused such an event. It now follows Classic's default, and what it adds depends on whether the event carries a properties value:

The event carries	What is added
No properties	Every instance the job defines — the same fan-out, under the same projected names, as All Instances
Properties, and the first value names one of the job's instances	That instance, with the event's properties merged over its own
Properties, any other first value	One ad-hoc instance, named from the first property's value, with the event's properties merged over the job's Default instance where it has one

A job that is not multi-instance is an ordinary add either way — the event asks for the fan-out only if the job turns out to have one.

note

An add with properties no longer lands on Default

Earlier builds put a property-carrying add on the job's Default instance whenever the job had one, and the designer gives every job a Default — so a second add with a different value collided with the live Job.Default and failed with a conflict, which is exactly the case a multi-instance job exists for. Classic names every multi-instance run from its property values, and so does this now: Property=1 is its own instance beside Property=0.

To write onto Default deliberately, send Default as the first property's value, or name it in instanceTarget where the caller has that field (an event does not).

Matching the first value against the job's instances. The value is matched ignoring case, against the value as sent and then against the name it cleans down to — so Env=default adds the job's Default instance rather than building Job.default beside it, and an instance named R&D is still reachable even though & is not a character an instance name can hold. A value that matches two instances on case alone is refused rather than taking whichever the job lists first.

Merging the properties. A property the event names replaces the instance's own, one it does not name is kept as it stands, and a name the instance does not define is added. Names are matched case-insensitively, the way a [[JI.…]] token reads them — so REGION in the event overrides the instance's Region instead of landing beside it and losing to it. A property the instance declares encrypted cannot be set this way, and the event fails naming it. An ad-hoc instance merges over the job's Default instance when it has one, so a property the event leaves out keeps that instance's default rather than being absent.

Ad-hoc instances. The name is taken from the first property's value — up to any further =, with line breaks and tabs turned into spaces and the characters a job name cannot hold removed, including the . that separates a job from its instance — then trimmed. A value that leaves nothing usable no longer fails the add: the instance is named AdHoc instead. An ad-hoc instance is refused when:

• the job's own name leaves no room to append one;
• the name spells one of the job's defined instances although it came from no value — an add from a legacy agent, which is always named AdHoc, onto a job that has an instance named AdHoc. Rename that instance;
• a same-workflow predecessor or dependent of the job is multi-instance. Those are matched up instance by instance (B.EAST waits on A.EAST), and neither has an instance of an ad-hoc name, so the job — or the job waiting on it — would wait indefinitely. The message says which relation blocked it, and suggests naming one of the job's instances or sending no properties to add them all.

A repeat ad-hoc add is numbered rather than refused. When the name is still held by a run that hasn't finished, the instance takes a $NNNN suffix the way Classic numbers a multi-instance duplicate: the lowest-numbered $NNNN copy that has finished is reused — replaced, as any finished duplicate is — otherwise it is the next number after the highest copy, starting at $0001. A finished un-numbered instance is replaced as usual, and instances of the job's defined groups are never numbered, because their group name is what dependencies match on: a live Default is a conflict, not something to number around. Past 9999 copies in one workflow instance the add is refused.

An event raised by a legacy agent names its ad-hoc instance AdHoc instead of using a property value, because an agent's properties are redacted and a job's name is not — see Secrets in an agent-raised event.

Each instance the event targeted is reported on its own in the event log.

Adding a workflow-container job

Adding a workflow-container job expands its sub-schedule immediately, the same way a build does — the child workflow's jobs are materialized with it rather than waiting for dispatch. Two limits:

• Top-level instances only. Adding a container job to a nested instance is left to dispatch rather than expanded here.
• Replacing a container job is refused while its sub-schedule is still live. Replacing it would orphan the child run — jobs still going with nothing left that owns them — so the add is refused and tells you so. Wait for the sub-schedule to finish, or close it, then add again.

Replacing a container job that has finished discards its old sub-schedule properly: the child is soft-deleted and evicted from the running schedule, so it does not linger.

Dependency wiring. A dependent that cannot be rewired — most often one deleted between the dialog reading the definition and the add — is retried once on its own and then skipped, so it no longer costs every dependent after it its edge.

Same-workflow dependencies are resolved by GUID and pruned against the jobs actually materialized in the instance — except an authored Requires or After, which survives and is marked absent instead of being dropped. That is what a normal build does, so an added job now waits on a Requires predecessor that didn't qualify for the date, rather than dispatching immediately as though the dependency had never been authored. Reverse-dependents (jobs waiting on the added job) are rewired from the live definition; an add that would create a dependency cycle is rejected (400).

Reopen. Adding a job to a COMPLETED resident instance reopens it (COMPLETED → IN_PROCESS) via a job recount so the new job can dispatch; if the best-effort graph sync fails, the instance is left COMPLETED rather than churning. The add records an ADDED job-history entry at the landing status (the job appears on the workflow timeline; audit parity with Classic's "Job Added").

You are recorded as the job's last modifier, not the platform. Adding a job resolves its dependencies immediately afterwards, and that resolution used to stamp the build service as the job's last-modified-by — so a job you added by hand was attributed to the platform the moment it landed. The job now carries you. A job the nightly build adds is still attributed to the build, which is correct for it.

Adding a run-on-all job

A job assigned to a legacy agent group in run-on-all mode runs once on every member of the group, and a build fans it out into one job per member. Adding one to a running instance does the same thing: the group's membership is resolved when you add, and you get one job per member, each named and assigned exactly as the build would have named it.

The job	Each added job is named
An ordinary run-on-all job	<job>__<member>
A multi-instance run-on-all job	<job>.<instance>__<member>, for every instance × member pair

Each one is pinned to its own agent, goes through its own duplicate gate, and reports its own outcome — so a group where one member is already running the job tells you that about that member, not about the add as a whole.

The group is read when you add, not when the workflow was built. An agent added to the group since the build is therefore included.

Only a legacy group fans out. A Universal Agent pool set to run-all is added as a single job, which is also how the build treats it.

The add is refused, naming the group, when:

• the group has no members — there is nothing to fan out to;
• two members share a name, which would collide on the projected job name;
• the group cannot be read — it no longer exists, or the request for it was rejected.

Two further limits are worth knowing:

• Instances × members is capped by the same fan-out limit a build uses. Over it, the add is refused and asks you to add instances one at a time.
• An ad-hoc instance of a run-on-all job is refused. Adding a multi-instance job from a $JOB:ADD event can name an instance that the job does not define; a run-on-all job cannot, because its added jobs are numbered against its per-member rows. Name one of its defined instances, or add it without properties to get them all.

In the dialog, a plain run-on-all job's disposition is read from its per-member jobs rather than a single job under the bare name, because the bare name is never in the instance: every member still running reads as Job is Active, and any member that has finished makes it a Will Replace whose confirmation covers those jobs. A job whose group has not been picked yet is treated as an ordinary job, which is how the run time treats it too.

Preconditions & scope. The add is rejected (409) when the workflow instance is CANCELLED or COMPLETED-and-not-resident (evicted); the UI disables Add Job for CANCELLED. A target instance in another environment is masked as not-found.

Editing a job on a running instance

The job editor opens from Edit Job on a job's node in the workflow diagram, and once it's open a job switcher moves it between the jobs of that workflow instance. It edits that instance, not the workflow definition — see Push Changes to Workflow to promote an edit.

The editor shows the job's custom fields. A Custom Fields section lists your tenant's definitions with this instance's values, and you can correct one on a run that is already under way. Earlier builds showed the section in the workflow editor only, so a built job's custom fields were invisible here.

A field marked required is not enforced on an instance save. The instance's values are fixed when the workflow is built, so a definition made required after that build has no value here to check — and refusing the save would block an unrelated edit the platform is willing to accept. The requirement is enforced where it belongs, on the workflow definition.

A job whose load fails can be opened again. If the job's data can't be fetched, the editor closes and reports "Failed to load job: …". Picking the same job again retries it; earlier builds left the editor pointing at that job, so re-selecting it did nothing at all and the job looked permanently unopenable — the only way through was to open a different job first, or to dismiss the message. Dismissing the message now only dismisses it.

Renaming a job no longer breaks the switcher. The switcher tracks which job is open rather than matching on the name you are editing, so the tick stays on the job you opened while you retype its Job Name. Earlier builds moved the tick to whichever saved job the typed name matched, and then refused to switch to it — no move, no unsaved-changes prompt, nothing — because the switcher read the target as already open. The only ways out were to type the old name back or abandon the edit.

The Events tab is editable here. You can add, change and remove a job's events on a run already under way — to add a notification to tonight's run of a job without touching the definition, for instance. The tab was previously read-only in this editor.

Three things about it are particular to an instance:

• It shows this instance's own events, already narrowed to the frequency the instance was built for. The workflow editor's Events tab lists every frequency's events; this one lists the ones that can actually fire on this run.
• Events are not carried by Push. Because the list is narrowed to one frequency, writing it over the definition would delete every other frequency's events — so the definition is left alone, and an edit to events alone does not offer Push.
• Save names an incomplete event rather than rejecting the form. An event card with nothing chosen reports "Event 2: choose the event to fire", and a Range comparison with no End Range reports "Event 2: enter an End Range for the Range comparison". The number is the card's position on the tab, so you know which one to open.

Events are sent only when the tab actually differs from what it loaded, so an unrelated save does not disturb them.

A refresh that fails after the editor is open keeps your edits. The editor re-reads the job immediately before saving. If that read fails, the dialog stays open with your edits intact and reports "Could not refresh job data before saving — please try again", so you can retry Save. Earlier builds closed the dialog as the save attempt unwound and discarded the edits. A background refresh that fails while nothing is in flight is silent, because the copy you're editing is intact and nothing is being asked of you.

Push Changes to Workflow

Editing a job on a running instance normally changes that instance only — the workflow definition every future build comes from is untouched. Push Changes to Workflow is how you promote such an edit: it writes your change into the master workflow definition, so every future build uses it.

It sits in the job editor's footer, beside Cancel and Save. The two are independent and can be done in either order or on their own: Save writes the instance, Push writes the definition, and pushing neither saves the instance nor closes the editor.

It confirms first, in a Push Changes to Workflow dialog, because the definition is shared: "This updates the master workflow definition. All future builds of this workflow will use these values." Confirming mints a new workflow version, with the change description Pushed edits from job "<job name>" — so the promotion is visible in the workflow's version history like any other edit. See Versions and deployments.

What a push carries

Not everything you can edit on an instance can be pushed. A push overlays:

Carried	Left alone
Documentation, tags, custom fields, the task definition, agent assignment, properties, dependencies	The job's timing — start and late offsets, max and estimated run time, the frequency itself
Within a frequency: priority, failure retries (attempts and the interval between them), success reruns	Everything else on a frequency, including its build status
	The job's events

The timing settings are definition-owned, and the instance's copy of them is a snapshot frozen when the instance was built. Pushing that snapshot back would write a possibly stale value over a newer definition, so those edits stay on the instance where you made them.

Events are left alone for a different reason. The instance holds only the events of the frequency it was built for, so pushing that list would replace the definition's whole set and delete every other frequency's events. Edit a job's events on the workflow when the change should outlast tonight's run.

A same-workflow dependency is translated on the way up. A predecessor the instance holds by its runtime instance name is rewritten to the plain job name the definition uses, so the pushed dependency means the same thing in the definition as it did in the run.

Custom fields are the one structured field pushed field by field, rather than as a set. The instance's values are fixed when the workflow is built, so a definition an administrator added since has a value on the workflow and no value here — replacing the whole set would delete it without saying so. Each field you actually touched is written, and clearing one on the instance does clear it on the definition. A required custom field is not enforced on the push for the same reason; if a value is missing from the instance and the definition, the workflow rejects the write and the push reports it.

When the action is available

Push is offered when the job actually differs from its definition in a field a push can carry — and that is deliberately narrower than "something was edited":

Situation	Push
You edited a pushable field in this window	Available
You edited it in an earlier session and saved to the instance	Available
You just pushed successfully	Not available
You edited a field and then edited it back	Not available
You edited only a field a push cannot carry	Not available
The definition was edited after this instance was built, and you changed nothing	Not available

That last row is the one worth understanding. A definition that has simply moved on since the build is not operator divergence, and offering to push it would write the instance's build-time values over the newer definition. So Push follows what you changed on this instance, narrowed to what the definition still disagrees with.

A pushed field is pushed whole

Push works per field, not per value. If you edited a field on the instance and someone else edited a different part of the same field on the definition in the meantime, your push replaces the whole field — and their change goes with it. This applies to the structured fields: the task definition, properties, dependencies and agent assignment. Custom fields are the exception — they are carried one field at a time, as described above.

Earlier builds gated Push on the current editor window alone. Reopening a job you had already edited and saved showed the action unavailable even though the instance still genuinely differed; and forcing it on by touching an unrelated field pushed only the field touched in that window, not the earlier divergence.

What you may see

Message	Means
Changes pushed to workflow	A new workflow version was written, carrying every field you edited.
Some changes pushed to workflow. Not pushed: …	Some fields were written and at least one could not be, with the reason for each. See When a field cannot be pushed.
This job already matches the workflow definition — nothing to push	Nothing needed writing. No version is minted for an identical configuration.
The workflow definition changed since it was loaded. Reopen the job and try again.	Someone else saved the definition while your editor was open. Reopen the job so you are working from the current definition, then push again.
Could not refresh job data before pushing — please try again	The instance could not be re-read immediately before the push. Nothing was written.

The push always re-reads the instance first, so it writes the instance's current values rather than whatever the editor was opened with — which matters because a push can fire with no local edit at all.

When a field cannot be pushed

A push can carry most of what you edited and still be unable to carry one field. When that happens the rest is written and the result says so — Some changes pushed to workflow. Not pushed: … — with the reason for each field that was left out. Earlier builds dropped the unwritable field silently and reported a plain Changes pushed to workflow, so a property edit could vanish with no message.

Two cases produce it:

• An ad-hoc instance's properties. A job added to a run by a $JOB:ADD event with properties is named from the first property value, so there is no property group in the definition matching that name — there is nothing for the properties to be pushed into. The push reports that the job was added ad hoc and has no property group in the workflow definition to update, so its properties cannot be pushed, and pushes the job's other fields normally. Earlier builds reported the misleading renamed or removed since the build error instead and pushed nothing.
• A property group renamed since the build. The instance's group no longer matches any group on the definition, so the push has no target. The same reporting applies.

Job detail

Selecting a job opens the job detail panel — a read-only view (the inline edit affordance has been removed). The hover overlay on a diagram node is a separate, lighter tooltip.

In the Job view the panel is a card beside the diagram, taking half the expanded row's width and its full height. The header and the tab strip stay put while each tab scrolls on its own, and a long job name wraps instead of being cut off. The Workflow view's own info panel is unchanged.

The panel's tabs

Tab	What it holds
Output	What the job printed — see Output tab.
Summary	What happened on this run — Execution, Submission, Time Constraints, Completion, Kill Request, Recurring and Retry — with Identity and Audit alongside.
Configuration	What the job will actually run with — see Configuration tab.
Status History	Every status change this job has been through.
Status Update	The actions you can take on the job, Restart among them.

Status History is a tab, not a dialog. It used to open from an icon in the panel header; that icon and the dialog are gone. Paging, refresh and the empty and error states are the same as the dialog's, and each entry is a stack of labelled rows — timestamp, event, the old and new status, who or what made the change, and any detail. History is fetched only while the tab is open, so opening a job no longer loads it unasked.

There is no Restart button in the panel footer. The footer is gone; restart is in the Status Update tab with the other actions.

Summary and Configuration lay out in two columns, and both drop to one when the card itself is narrow — which depends on the card, not on your window, so a wide screen with a narrow card still gets the single-column layout.

Summary → Completion carries an Arrived File row for a File Arrival job, giving the path the run actually matched rather than the pattern that found it. It appears only when the run reported a file, and it describes this run — a restart clears it.

Summary → Completion carries an Agent Message row

A legacy LSAM job that fails can send back a reason of its own — why the agent refused or could not run the job. For a Windows, UNIX or SQL LSAM job that also returned an exit code, the Termination row holds that exit code, so the agent's own words had nowhere to go and were invisible. They now appear in an Agent Message row, directly after Termination.

• It appears only when there is something to show. The row is absent unless the agent sent a message and the exit code displaced it from Termination. So the reason is visible exactly once, never in two places.
• It is per-run evidence. Like Arrived File, it is cleared when the job is re-armed, restarted, or dispatched again — it describes this run.
• A failure the relay itself reported is not an agent message, and is never put here. The generic Job failed and the relay's own reasons — a job lost after a reconnect, a runtime ceiling exceeded, a kill that timed out — carry no agent detail.

An agent message is withheld when the run's command line carried a secret

A UNIX LSAM echoes the command line and its arguments back in its failure reason when it cannot start the job. If that command line was built from an encrypted property — or from a credential the job type supplies — printing the agent's text would make a secret readable again, which is exactly what encrypting it promised to prevent.

So when the run's command line carried a secret, the row reads Agent message withheld — this run's command line carried a secret instead of the agent's text. The same substitution is applied to the termination fallback and the exit-criteria trace.

It fails closed: if it cannot be established that the run carried no secret, the message is withheld. A job whose command line holds no encrypted value is unaffected.

The Output tab now shows the server's reason too. When output cannot be fetched, the tab reports the error the server actually sent rather than a bare status code — so, for instance, the gateway failure that explains why an IBM i job has no output is readable. A job with no LSAM job number is also described correctly now: the message no longer claims output is not available for this job type, which was wrong in its commonest case — an undispatched or restarted legacy run.

The panel keeps its Date and Workflow after an action. Editing a job, or restarting it, used to blank those two fields until you hard-refreshed or navigated away and back. Every job action — edit, restart, hold, release, start, kill, cancel and the rest — now returns the job with its date and workflow intact, so the panel stays populated. (Restart still clears the exit code and agent fields; that is the reset it is meant to perform.)

A job that overran its Max Run Time

A job that has run past its Max Run Time carries an Exceeded Max Run Time badge, in two places and in a warning tone rather than an error one — the job has not failed:

• Beside the job's status — in the Job Status column of the jobs list, and beside the Status value at the top of the detail panel's Summary tab. It is a separate badge from the status badge, and the status is unaffected: the job reads Job Running while it runs and then whatever it earns when it finishes.
• On the Summary tab, in the Time Constraints section, as a Max Run Time Exceeded row giving the time the overrun was detected. The limit itself stays on the Configuration tab and is not repeated here.

Time Constraints appears for a job whose only timing value is the overrun, which is the common case — Max Run Time is configured independently of every other timing field.

The badge stays after the job completes. A job that overran and then finished OK is exactly the case the status alone cannot show, which is why the marker outlives the run rather than being a live-only indicator.

There is no filter for it — the jobs list filters on status, and this is not a status. See Exceeding Max Run Time for what the platform does about the overrun, and what it deliberately does not do.

Configuration tab

The Configuration tab describes what this job instance will actually run with, not what the workflow's design says:

Section	Read from
Task Definition	The job instance.
Agent Assignment	The job instance.
Frequency Runtime Info	The parent workflow's build snapshot.

Task Definition and Agent Assignment read from the instance, so they reflect anything that changed between the design and this run — a deploy-time transform rule that retargeted the agent, or an edit made to the instance itself. Earlier builds read both from the workflow's frozen design snapshot, so a job that had been retargeted on deploy showed the agent it would have used rather than the one it did.

Both sections render even when the job isn't present in the build snapshot at all. Frequency Runtime Info still comes from the snapshot, so it's the one section that can be unavailable for an instance the snapshot doesn't cover.

Output tab

The Output tab shows what the job printed. Its header always carries the job's Date, Exit Code and Workflow as a row of labelled values, so a log read out of context still identifies its run, and the tab's actions are grouped together on the right of that header. The log or the file list fills the rest of the card and scrolls inside it, so the header and the actions stay put however long the output is.

The tab has two shapes, chosen by the kind of agent that ran the job:

Job ran on	What the tab shows
A Continuum agent	The output returned with the job, as one log.
A legacy (LSAM) agent	A list of output files the agent holds, any one of which opens in place.
Neither (a container job, or any job type that runs no process)	Nothing — the tab reports No output and offers no download control.

Open shows the file you are looking at in a new browser tab, at that tab's full width. It is the way to read a long log: the in-panel view materialises only the first 500 KB of a file and says so — Showing the first 500 KB of a 2,400 KB file. Use Open to read all of it. Open and Download always work from the whole file, not the truncated view. If the browser blocks the tab, the panel says so rather than doing nothing.

Download never truncates either. All downloads everything, and the caret beside it offers the parts by name — every output file on a legacy job, and the single log on a Continuum-agent job.

Both shapes also carry a refresh: Refresh from agent on a legacy job, which is described below, and Refresh output on a Continuum-agent job, which re-reads the job.

Output files from a legacy agent

A legacy agent keeps its output on the machine, so OpCon Continuum has to ask for it. The first time you open the tab for a job, it fetches the file list from the agent through the relay and stores it; after that the stored copy is served, which is why the tab opens instantly on a second visit. The Output Files heading carries the file count and which of the two you are looking at. The same applies to each file's contents, fetched and stored the first time you open it.

Refresh from agent discards the stored copy and asks again — the action to take for a job that was still writing output when you first looked.

Two limits are worth knowing:

• Only files the agent listed can be read. Reading a file the list does not hold is refused, so the tab cannot be used to reach arbitrary paths on the machine.
• Output is per environment. A job that belongs to another environment reports not-found for its output files, the same as for every other read — see Environments.

Re-running a job discards its stored output listing. The listing and the file contents belong to a run, while the stored copy hangs off the job instance — and a restart, a failure retry, a recurring restart and a force start all re-use that same instance. Each of them now clears the stored copy as the job is dispatched, so the Output tab reads the new run's own output instead of serving the previous run's files as though they were the current ones. You do not have to remember to Refresh from agent after a restart.

Three things are dropped together, because each of them was independently capable of serving the previous run's output as the current one:

• the stored file listing and file contents;
• the identifier the previous run was known by on the legacy agent. A UNIX agent names an output file after that identifier, so a request still carrying the previous run's one matched the previous run's file exactly. A listing that comes back late — the request went out before the job was re-dispatched — is now checked against the identifier it was sent with, and discarded rather than cached, so a slow answer from the old run cannot become the new run's output;
• the inline output a non-legacy job returns with its completion, which is likewise written only when a run finishes.

A restart that is never dispatched is cleared too. Restarting a job on hold, or a restart whose dispatch fails immediately with an initialization error, used to leave all of the above in place — indefinitely, in the second case — so the Output tab showed the previous run's output under a job that had not run. The clear now happens on the restart itself as well as at dispatch.

UNIX and IBM i output needs a current relay

Retrieving output from a UNIX or IBM i agent depends on how the request names the job, and that naming is built by the relay's connector. Two things went wrong on older relays:

• A UNIX request matched nothing — and because the UNIX agent falls back to its own global log, the tab came back populated with the agent's logfile and errfile instead of the job's own output, reporting success the whole way. It looked right and was wrong.
• An IBM i request returned nothing at all. IBM i does not name a job the way the other platforms do: the request has to carry the OS/400 qualified job name — job name, job user and the job number assigned when the job was submitted — and that number exists nowhere in OpCon Continuum. It is reported by the agent itself, and the connector was not reading the part of the agent's status message that carries it.

Current builds send the naming each platform expects, and refuse a request that cannot match rather than sending it — so a failure is visible and retryable. IBM i output is now retrievable rather than refused. If UNIX or IBM i output still comes back wrong or empty, check the relay build first: the relay has to carry these changes for them to take effect, and nothing in the cloud can yet tell an out-of-date relay from a job that genuinely produced no output. Windows and SQL agents are unaffected and were always correct.

If a job's output already looks like the agent's global log rather than its own, use Refresh from agent after the relay is upgraded — the wrong list was stored, and only a refresh replaces it.