What the two statuses mean

Queued for Launch means Workday has recorded that the orchestration should run, but the scheduler has not started it. In Progress means it has started, and the orchestration's own steps have not finished. They have different causes, so read which one you have before changing anything.

These statuses appear on the Orchestrations tab of the event details page, which you reach from Find Events. Workday documents them for orchestrations launched by a business process status change: an orchestration launch configuration paired with Cancel, Rescind, Correct or Deny in the Configure Orchestrations task. An orchestration started by a Service step (Orchestration Service) in the business process definition is a different setup with a different symptom, covered further down.

Queued for Launch: the scheduler has not started it yet

Workday doesn't launch these orchestrations from the user's click. The Workday scheduler launches them, typically within 15 minutes, and Workday's documentation warns that Mass Cancel and Mass Rescind can take longer. Mass actions launch the orchestrations through a background job. So a status of Queued for Launch five minutes after a rescind is normal. Wait out the 15 minutes before you debug anything.

If it is still queued well after that, check the setup the launch depends on:

  1. User to Perform Orchestration Launches. In Edit Tenant Setup - Business Processes, this field names the person whose permissions the launch uses. A configuration item without its own user falls back to this tenant-wide user. Workday describes it as a person who can access the fields and perform the actions the orchestration needs, so an empty field, or a user without that access, is the first thing to look at.
  2. The launch configuration exists and is selected. Workday doesn't create orchestration launch configurations automatically. A successful deploy is not enough: you have to create the configuration with Create Orchestration Launch Configuration and then select it in the Configure Orchestrations row for that action.
  3. The condition rule. Workday evaluates the row's condition rule before it initiates the orchestration. If the rule is false for this event, the orchestration does not run.

In Progress: the run started and has not finished

Workday states that the move from In Progress to Completed depends only on the orchestration's processing. The business process has done its part. To find out what is happening, look at the run itself, not the event.

Before you treat it as stuck, click Refresh Status on the Orchestrations tab. It fetches the latest execution state directly from Orchestrate, and the page can show an older state until you do.

Also check who is looking. The event's action page shows Completed for the orchestration only if the initiating user has View permission for the event. If that user lacks View, a finished run can still look unfinished to them. Look at the same event as a business process administrator before you conclude the run never ended.

Find the run in Orchestration Activity

On the Workday Developer Site, open the app's Orchestration Activity and select the orchestration. Each run shows a Current Status, a start time and the tenant it ran in. Expand the run to see its Common Request ID and Process IDs, which you use to find the matching log lines. The statuses that matter here:

Orchestrate status What it tells you
Orchestrate statusQUEUEDWhat it tells youOrchestrate accepted the run and is waiting to execute it.
Orchestrate statusRUNNINGWhat it tells youSteps are still executing.
Orchestrate statusAWAITING_CALLBACKWhat it tells youThe run is paused, waiting for an external callback before it can continue.
Orchestrate statusCOMPLETED_WITH_ERRORWhat it tells youThe run finished, but some processing failed.
Orchestrate statusFAILED or TIMED_OUTWhat it tells youThe run ended without completing.
Orchestrate statusSUCCESSWhat it tells youThe run completed. If the event still shows In Progress, use Refresh Status.

If there is no run at all for the event's time, the orchestration was never launched. Go back to the launch setup above.

AWAITING_CALLBACK means the flow is waiting on something outside itself. In a business process flow, look first for a Trigger Business Process step: the orchestration waits for the business process it started. Orchestrate allows that business process 90 days to complete (the Workday Business Process orchestration runtime callback period in the runtime limits). If the triggered event is sitting in someone's inbox, the orchestration will sit with it. Find that event and move it forward. See why a business process waits on an awaiting action.

RUNNING for a long time is a processing problem. Orchestrate limits any single process to 45 minutes in an app that hasn't been promoted to Production and 60 minutes in Production. An asynchronous Extend orchestration can run for up to 48 hours in total. Look for a loop over far more rows than expected, a polling HTTP request that never meets its exit condition, or a request with a long overall timeout. Click View Logs on the run to open the logs filtered to it, and read the last step that logged.

When a Service step holds the business process

On an Orchestration Service step, the check box Advance business process step when orchestration completes tells the business process not to move to its next step until the triggered orchestration completes. That is useful when the next step needs the orchestration's results, but the event then shows the service step as in progress for as long as the run takes.

Workday's documentation doesn't say what the step does when the run fails, so go to the run rather than the event. Open Orchestration Activity, find the run for that event's time, and read its status and failed steps. A FAILED or COMPLETED_WITH_ERROR run is the cause. Two faults in the step's own setup to rule out are trigger keys that don't match and a run user who can't do the work:

  • Workday requires the Key names in the service step's Configure Orchestration Service data to match the parameters on the orchestration's Business Process Trigger step. Compare them character for character, including case.
  • The Business Process Trigger start needs a credential: either Integration System User authentication or initiating-user authentication. The service step also names the user who runs the orchestration, by default the user who ran the previous step. When the first Workday call in the run fails, check that user's permissions first. See Permission Denied (S22) on a business process orchestration.

If the next step must never open before the orchestration has run, a recommended pattern is to keep the check box selected and also make the orchestration write a visible failure state onto the record it works on, such as a status field on the target business object. That way, a failed run shows on the record the reviewer opens next instead of leaving the record looking untouched.

Clear it and prove it

For an orchestration launched by a status change, wait until the status has moved from Queued for Launch to In Progress. A Relaunch option then appears on the Event Canceled, Event Rescinded, Event Corrected or Event Denied page. It opens the Relaunch Orchestration task, where you can change the launch parameters before it runs. Relaunch skips the condition rules. That lets you force a run the rule blocked, and it also means the rule won't stop a relaunch you didn't intend.

To stop a run that is looping, use Cancel in Orchestration Activity first. Orchestrate stops at the next safe cancellation checkpoint defined in the flow. Kill Orchestration stops it immediately, but it can leave the two systems inconsistent. Use it only when the run never reaches a checkpoint.

The fix is proven when three things agree:

  1. Orchestration Activity shows the new run as SUCCESS, with no failed steps.
  2. Refresh Status on the event's Orchestrations tab shows Completed.
  3. The record the orchestration was supposed to change, in Workday or in the external system, has actually changed. Read it back. A completed run proves the run ended, not that the work was done.

For the general method of reading runs and step failures, see Workday Orchestrate errors.

Sources checked