Work the Processes page

Processes is your daily-run screen: the live view of the workflows and jobs running in the selected environment. This page is where you watch the run and act on it.

What this solves

During the run you need to see what's happening and act fast (push a waiting job through, stop one that's misbehaving, or clear a batch of stuck jobs at once) without hunting through separate screens or selecting one row at a time.

Pick your view

A toggle switches between two views (your choice sticks if you reload):

• Job View (the default): every job in the run, one row each. All columns sort.
• Workflow View: the workflows themselves. Filter it by status group (Building, Waiting, In Process, Held, Completed, Cancelled) rather than individual statuses.

From here you can also Schedule Workflow to add a workflow to the run, and refresh the view. Schedule Workflow takes a date range of up to 31 days, not just one day, and builds each date in turn — so a date the workflow isn't deployed for is reported against that date while the rest of the range still builds. One tick of Overwrite Existing applies to every date you picked; the confirmation states the date count beside the instance count, and carries the progress while the range runs.

An expanded row moves to the top of the list

Opening a row lifts it to just under the column headers and scrolls it into view, and its panel gets the full height of the list — so a workflow diagram has room instead of being squeezed into whatever the other rows left over. The rest of the rows carry on below the panel in their usual order, and collapsing the row puts it back where it was. Your sort and filters don't change.

Following a job between the views

Both views hand you off to the other with the destination already narrowed:

• On the workflow diagram, a job node's menu offers View in Job View. It switches views, fills in the Job Name, Workflow Name and Date filters from that job, and opens that job's own row — so you land on the job you clicked, not on every job that shares its name. Earlier builds seeded only the name, which matches anywhere in a name that repeats across workflows.
• From a job's detail, Workflow → goes the other way: the Workflow View filters to that job's workflow instance and opens its row.

Editing the seeded Job Name — including clearing it to widen the list — hands the view back to you and abandons the rest of the hand-off, so the filter bar always matches what you're looking at.

Find what you're looking for

• Use the search command menu to jump to a job.
• Use the filters (look for the funnel icon on a section header) to narrow the list; the frequency filter uses on/off switches. Hover any control for a tooltip explaining it.
• Filter by status group rather than by raw status. In Job View the primary groups are Held, Waiting, Running, Succeeded and Failed, with Pending Term, Fixed, Skipped, Cancelled and Under Review under More.

Listing a run's skipped or fixed jobs

Fixed and Skipped are now choices of their own. They used to be reachable only inside Succeeded, so there was no way to list just the jobs that were skipped. Succeeded still includes both, so it means what it always did.

Narrowing a name filter

The name filters — Workflow, Job and Agent, each in its own column header — all match anywhere in the name by default, which is usually what you want and occasionally far too much. Add a * to say where the match has to sit:

You type	You get
payroll	Any name containing payroll
payroll*	Names starting with payroll
*payroll	Names ending with payroll
pay*roll	Starts with pay and ends with roll

Case never matters. ?, _ and % are all taken literally, so a name that really contains one is findable — earlier builds let _ and % through as wildcards, which is why a filter of JOB_01 used to bring back JOB-01 as well.

The same applies to the Job History report's workflow, job and agent name filters. See The Processes page.

To see only what needs attention, turn on Show jobs with errors. It covers every failure status — Failed, Marked Failed, Initialization Error, Missed Start Time and Under Review, including the brief "pending" form of each. Earlier builds matched only Failed and Under Review, so a job that failed to initialize or missed its start window stayed hidden while the switch was on; if you had stopped trusting it, it is reliable now.

Changing the page, sort, search, or a filter clears your current selection, so a bulk action never acts on rows you can no longer see.

Telling two runs of the same workflow apart

Some workflows build more than once for the same date — once per named schedule instance, such as one run per branch. Those rows show a composed name, PAYROLL_BRANCH1, so you can tell them apart. A workflow that builds only once shows its plain name.

The Workflow filter in the Workflow View's column header matches the composed name, so typing BRANCH brings back PAYROLL_BRANCH1 and PAYROLL_BRANCH2. There is no longer a separate Instance Name filter — it used to sit beside Workflow Name and hid every workflow that had no instance name at all, which made an empty grid hard to explain. A saved filter or bookmark that carried one still loads; the instance name in it is simply ignored.

One instance can also be built more than once for the same date — when the build carries different instance property values, or on any build of a workflow that allows multiple instances but declares none. Those rows carry a four-digit run suffix — PAYROLL_BRANCH1$0002 is the second run of BRANCH1. The first run has no suffix, and the suffix follows through into the Close and Delete confirmations and the result message after a bulk action, so an action on one run is never reported against another.

Good to know

An underscore means a schedule instance — a whole separate run of the workflow (PAYROLL_BRANCH1). A $nnnn suffix means a repeat run of that same instance for the date. A dot means a job that fanned out into several instances inside one run (EXTRACT.US). You may see all three in the same run.

Act on one job

Open a job's action menu to act on it. You'll only ever see the actions its status allows, so you can't pick one that would fail. For what each action does, including when to use Kill vs Cancel, see Job statuses and actions.

Select a job to open its detail panel (read-only). It has five tabs — Output, Summary, Configuration, Status History and Status Update — and a link to the job's Workflow.

Status History is where the job's status changes live. It used to be a dialog opened from an icon in the panel header; that icon is gone, and the tab shows the same thing — each change with its timestamp, the old and new status, who made it and any detail. It loads only when you open the tab.

Restart is in Status Update, with the other actions, rather than in a footer button.

Act on many jobs at once (bulk actions)

To act on several jobs at once, complete the following steps:

1. Select the rows you want, or select them all.
2. Once two or more are selected, a Bulk actions button appears.
3. Open it. The menu shows only the actions valid for every selected row, plus Delete.
4. Choose an action; it runs across the selection and a message confirms the result.

This works in both Job View and Workflow View.

Spot a container job with nothing to run

A Workflow Container job runs a whole other workflow as one step. If that embedded workflow couldn't be built — usually because it isn't deployed for the date — the container has nothing to run, and it will fail when it starts. Until then it sits in an ordinary waiting status, which is why it's marked for you:

• A warning icon sits beside the job name in Job View, and beside the status badge on the workflow diagram. Hover it for the reason the build recorded.
• Scheduling a workflow that leaves a container empty raises a warning banner above the list naming each one — the schedule instance that owns it, the container job, the workflow it referenced, and the reason. It has no timer, so it waits for you to dismiss it.

What to do about it

Fix what the reason names — most often, have the embedded workflow deployed for that date — then rebuild the parent with overwrite. If you'd rather let the run go on without it, Skip the container job (or Cancel it, or Mark Finished OK if the dependents should proceed as though it succeeded). Any of those three clears the warning as well.

See what a job is waiting on from outside this run

A job can be waiting on a predecessor that isn't part of the workflow instance you are looking at — a job in another workflow, or a job in this workflow on a different date. The workflow diagram used to draw nothing at all for those, so the waiting job appeared to have no reason to be waiting.

That predecessor is now a dimmed stand-in card with an arrow into the job that waits on it. Read it like this:

• the top line is the workflow the predecessor belongs to, and the bold line its job name;
• a trailing * on the name means the dependency matches a name prefix, so more than one job could satisfy it;
• a third line names the schedule instance, when the dependency names one;
• -1d or +2d is the day relative to the waiting job's own date — blank means the same day;
• Any day means the relation isn't tied to a single date.

The card carries no status, because nothing here checks that other run. The arrow is what tells you whether the wait is still on: a satisfied dependency draws solid, an unsatisfied one dashed.

What to do about it

Nothing on this canvas will resolve it. Go and look at the run the card names — switch the Date filter to the day it points at, or search for that workflow — and act there.

Read a job's output

The Output tab on a job's detail panel shows what the job printed, with the job's Date, Exit Code and Workflow Name above it so a log you copy elsewhere still says which run it came from.

For a job that ran on a legacy (LSAM) agent you get a list of output files the agent holds; open any one to read it in place. For a job on a Continuum agent you get the one log it returned. A job that runs no process of its own — a container job, for instance — has no output and says so.

Three things are worth knowing when the log is the thing you actually need:

• Open shows the file you are reading in a new browser tab, at full width. The in-panel view materialises only the first 500 KB of a long file and tells you when it has — Use Open to read all of it. Open and Download always work from the whole file.
• Download never truncates. All takes every output file; the list beside it takes one named file.
• Refresh from agent re-asks the agent for the file list. The list is fetched once and then kept, so a job that was still writing when you first looked needs a refresh to show the rest.

UNIX and IBM i output: check the relay if it looks wrong

Retrieving output from a UNIX or IBM i agent depends on the relay being on a current build. On an older relay, a UNIX job's Output tab came back holding the agent's own global log files instead of the job's output, reporting success the whole way — so it looked right and was wrong. If UNIX or IBM i output is empty or clearly belongs to something else, ask your Administrator to check the relay build before treating it as a job fault. Once the relay is current, use Refresh from agent on any job whose wrong list was already stored.

Reopen a workflow that already finished

A completed workflow instance isn't the end of the road. From Workflow View, Hold, Release and Start are all available on a Completed row, and each one reopens that finished run so you can get more work out of it:

Choose	And the run reopens as
Hold	On Hold
Release	Waiting to Start
Start	Started by User

What this solves

A run finished, and then you find out a job in it has to run again — a step that failed and was marked fixed too early, or output that has to be regenerated. You need that same instance back, not a whole new build for the date.

To reopen a completed run and re-run a job in it, complete the following steps:

1. In Workflow View, open the completed instance's action menu and choose Hold, Release or Start. Release is the usual choice — it puts the run back in the queue.
2. Confirm in the Reopen Completed Workflow dialog. It names the instance and tells you where the action will leave it. Choose Leave Completed if you've changed your mind.
3. Restart the job you reopened the run for. This is the step that matters — see the note below.

Reopening on its own runs nothing

Reopening clears the run's recorded End Time and moves it out of Completed, but it does not restart anything. The instance sits in its new status and stays there — it won't run on, and it won't quietly re-complete itself either — until you restart a job on it. Once you do, it picks up and finishes as a genuine second run, and its completion notifications fire again rather than being treated as a repeat of the first.

If you reopened with Hold, remember it's now a held run: release it as well.

Two things to know:

• You can't reopen a sub-schedule. On a completed nested sub-schedule (a run started by a container job), those three actions aren't available — a sub-schedule follows its parent. Act on the parent workflow instead.
• A run reopened with Start can't be deleted. Started by User isn't a deletable status, so if you reopen with Start and then change your mind, use Close to put the run back to Completed. Reopening with Hold or Release leaves you a run you can still delete.

To reopen several runs at once, select them and use Bulk actions. If any selected row is Completed, the action confirms first and tells you how many completed runs it will reopen — worth reading on a mixed selection.

If the automatic daily build stops replacing that date

Once a run has started — including a run you reopened — the automatic daily build leaves it alone instead of rebuilding over it. That's deliberate: it won't overwrite work that has already happened. Rebuild the date yourself if that's what you want.

Add a job to a running workflow

Sometimes a workflow is already running (or has finished for the day) and you need one more of its jobs to run: a step that was skipped, or one you want to run again. From Workflow View, open a workflow instance's action menu and choose Add Job.

What this solves

A job that belongs to the workflow didn't run this time (maybe its frequency didn't qualify for the date, or it was left out), and you need it to run now, in the same instance, without rebuilding or rescheduling the whole workflow.

To add a job to a running workflow, complete the following steps in the Add Job to Workflow Instance dialog:

1. Pick the job. You'll see every job defined on the workflow. Each is tagged so you know what will happen:
   • (no tag): the job isn't in this run yet and will be added.
   • Will Replace: the job already ran and finished; adding it again replaces that finished copy (you'll be asked to confirm first).
   • Job is Active (greyed out): the job is already running or waiting, so you can't add another.
   • No Frequency (greyed out): the job has no frequency defined, so it can't be added.
   • Disabled: the job's Disabled switch is on, so no build ever includes it. You can still add it — that is the way to run a parked job once — but the badge is there so it is a choice.
2. Choose a frequency if the job has more than one (if it has just one, it's picked for you).
3. Choose which instances — only for a job that runs as multiple instances. Tick All Instances to add every one of them at once, or leave it clear and pick a single Instance.
4. Adjust properties if you need to. The grid is pre-filled with the job's defaults; leave it alone to use them as-is.
5. Add on Hold if you want the job held instead of released to run right away.
6. Add a reason (optional). It's saved to the job's history for the audit trail.

Choose Add Job. A released job starts as soon as it's eligible; a held job waits until you release it. If you add a job to a workflow that already completed, the workflow reopens so the new job can run. The added job shows up in the run and on the workflow's timeline, marked as added.

Adding every instance of a multi-instance job

Each instance is handled separately, which is usually what you want: one of them already running doesn't stop you adding the others, and if one can't be added the rest still are. The result tells you what happened to each.

Its tag is read per instance, too — from each instance's own row, not from the plain job name, which is never in the run. An instance still running reads Job is Active; one that has finished makes it a Will Replace. Earlier builds looked under the plain name, found nothing, and showed every multi-instance job as freely addable — so Will Replace never appeared and a finished instance could be replaced without a confirmation.

The same add raised as an event

A $JOB:ADD or $JOB:ADDHLD event names a job but has no field for an instance, so a multi-instance job used to be refused outright. It now behaves the way Classic's did: with no properties on the event it adds every instance, and with properties it adds one, named from the first property's value — so Property=1 is its own instance beside Property=0, which is the point of a multi-instance job. If that value happens to name one of the job's own instances, that instance is added instead, with the event's properties merged over its own.

Either way the event log records what happened to each instance, and a partly failed add is worth reading before you raise it again — see Use the event log.

Adding a job that runs on every agent in a group

A job assigned to a legacy agent group in run-on-all mode used to be refused. You can add one now, and it behaves as the build does: you get one job per member of the group, each named <job>__<agent> and pinned to that agent, each reporting its own result.

The group is read as it stands now, not as it was when the workflow was built, so an agent added to the group since then is included. Two things to expect:

• The dialog reads the job's tag from its per-agent jobs, because there is no single job under the plain name. Every agent still running it reads Job is Active; any agent that has finished makes it a Will Replace.
• The add is refused, naming the group, if the group has no members, if two members share a name, or if the group can't be read.

A Universal Agent pool set to run on all its agents is added as a single job instead — again, the same as the build.

What you still can't add

You can't add a job to a cancelled workflow instance.

Workflow-container (sub-schedule) jobs can be added now, with one restriction: if you're replacing a container job that already ran, its child workflow has to be finished first. Replacing one while the child is still going would leave that child with nothing owning it, so it's refused rather than allowed.

Delete a job or workflow instance

Delete removes a job or a whole workflow instance from the run (a soft delete). Deleting a job also frees anything waiting on it, so downstream jobs stop hanging on a step that's no longer there.

You can't delete a workflow instance while it's actively running. Hold or let it finish first. Deletion is allowed when it's waiting, held, completed, or cancelled.

Related topics

• The Processes page (runtime) — full configuration reference and troubleshooting
• Monitor the daily run (Operator)
• Job statuses and actions (Operator)
• Respond to a failed job (Operator)