How to keep large Workday Orchestrate loads inside the runtime limits: templates, checkpoints, batches and child runs

Find which limit stopped the run

A large load in Orchestrate usually fails on one of four limits, and each has a different fix. Look up the run in Orchestration Activity on the Developer Site: a status of TIMED_OUT plus the run's elapsed time and its process IDs tell you which one it was.

From Workday's Orchestration Runtime Limits page:

The 45-minute figure matters during testing: a single process that needs 50 minutes would finish in an app promoted to production but times out before promotion, which is where you test.

For the full table, including message sizes, and for paging through Workday and external APIs, see Orchestrate looping, pagination and limits.

Move the work off the synchronous template

If a page or a Home Card launches the work, the orchestration is synchronous and gets 25 seconds or 5 minutes, whatever its timeouts say. Workday's own recommendation on the limits page is to use an asynchronous orchestration when you expect more than 25 seconds of processing. For a scheduled or bulk load, build it on the Integration System template, which runs up to 48 hours and is the only template with Trigger Integration and Trigger PDF Generation.

The user-facing consequence is that the page no longer gets the result back in the same request. Have the orchestration write its outcome to a record the page can read later (a status field on the request, an integration event message), rather than trying to keep a synchronous call alive.

A synchronous orchestration that calls itself to process the next chunk is capped at 31 recursive self-calls, so recursion is not a way around the 5-minute limit.

Add checkpoints so no single process runs 60 minutes

An orchestration runs as a chain of processes. Each process may run for 60 minutes (45 before promotion to production); the whole run is limited separately. Orchestrate starts a new process, with a fresh 60-minute window and its state saved and reloaded, at every checkpointing step:

• Send Workday RaaS Request
• Trigger PDF Generation
• Trigger Business Process
• Trigger Integration
• Send HTTP Request when it uses polling

A flow that reads a large report and then spends 70 minutes writing records back in one uninterrupted loop fails at 60 minutes, because nothing in the loop starts a new process. Moving the writes into child integrations (below) puts a checkpoint around each batch.

Order matters. Put the expensive read (a RaaS call) at the start of a phase, not at the end, so the time-consuming processing that follows starts with the window reset.

Batch the writes with Batch Loop

One API call per record is the most common reason a load runs long. When the target accepts several records per request, group them with a Batch Loop. Workday's Import web services go further: one call takes a large data set and returns the WID of a background process that imports it, which you then monitor with Get Import Processes. The Batch Loop strategies are:

• Size strategy: set the Data Breakpoint Number to the number of items per batch.
• Group strategy: batch by an expression such as the company or pay group, so each request covers one organization.
• Custom strategy: start a new batch at or after a marker item.

Inside the loop, the current batch is available as data.<loop name>.batch; Workday's BatchLoop_SizeStrategy sample aggregates it straight into the output. Build each batch's request body from the batch with a text template, send it once, and record the response per batch.

Choose the batch size from the receiving API, not from the orchestration: large enough to cut round trips, small enough that one rejected record does not cost you a long resend. The Batch Loop guide covers the strategies in detail.

Let loops run in parallel unless order matters

Loop iterations are processed in parallel unless something forces them to run in order. Two settings do:

• Force Sequential Processing on a loop's Early Stop Condition. Workday warns that it can significantly increase processing time and cause a timeout that would not otherwise happen.
• Enable Wait for Long Running Response on Send Workday API Request (Advanced Mode). It lets one call wait up to 1 hour for REST or 6 hours for SOAP, and inside a loop it makes iterations run sequentially.

Use either only when the business logic needs it, for example when each record depends on the previous one. An early stop condition without forced ordering is still useful: it ends a paging loop as soon as the last relevant page arrives.

Split very large work into child integrations

When one run is simply too much work, make the parent orchestration a coordinator. In an Integration System orchestration, a Trigger Integration step launches another integration as a child, passes it launch parameters and at most one document, then pauses until the child calls back with its status, messages and output documents (in the sample, data.TriggerDemo.childDocuments).

The usual shape: the parent reads the full population once, cuts it into batches with a Batch Loop, stores each batch as a document and triggers a child per batch. Points from Workday's Triggering Integrations page that shape this design:

• The child can be a Studio, packaged or Orchestrate integration system. EIBs are not supported.
• Trigger Integration cannot be used in Join Loops.
• Each child sees only the single document the parent passes it, plus what it creates itself.
• Retry settings on the step retry a failure to launch the child, not a failure of the child. Handle a failed child with an error handler, after checking what the child already wrote.
• Document storage for the passed document defaults to 7 days, with a maximum of 1 year.

Because Trigger Integration is a checkpoint, the parent's current process saves its state while the child runs and a new process resumes when the child calls back. A child that is itself an Orchestrate integration runs as its own orchestration, with its own processes and limits.

Wait for an external system between phases with a launch delay

Orchestrate has no general delay or wait step. When a phase needs another system to catch up before the next one starts, for example an external database that has to index the records you just loaded before you read them back, put the next phase in a suborchestration and give its Call Suborchestration step a Suborchestration Launch Delay. Select Advanced Mode on the step and set Delay Duration (Minutes) to a number or a number expression from 1 to 60; a value outside that range is moved to the nearest end. The wait always happens before the suborchestration starts. It is not available in synchronous orchestrations or from Join Loops.

The delay adds to the run's elapsed time, so it counts against the 48-hour run limit. Call Suborchestration is not on Workday's list of checkpointing steps, so do not count on a delay to reset the 60-minute process window. Inside an ordinary Loop the iterations run in parallel, which means every delayed call starts its wait at the same moment; select Force Sequential Processing on the loop's Early Stop Condition if each delay has to follow the previous call.

Keep memory flat inside long loops

The 200 MB limit counts every in-scope value plus temporary values created while evaluating expressions. Values over 20 MB are kept on disk in file-backed structures (up to 2 GB on disk), and data is released when it goes out of scope. So:

1. Iterate a large document with an iterator instead of building a list of it first.
2. Fetch and transform each item inside the loop, so the per-item data goes out of scope when the iteration ends.
3. Aggregate only what you need downstream (a count, a list of failed IDs) rather than every response.

For heavy mapping steps, Workday's Optimizing Create Values Performance page notes that independent key/value pairs in one Create Values step can be created in parallel, with up to 4x improvement at 100 or more independent pairs. Put derived values that depend on others in a separate Create Values step.

Prove the redesign fixed it

Run the load at full production volume before the app is promoted to production, while the process limit is still the stricter 45 minutes. Then, in Orchestration Activity, check the run:

• Process IDs: there should be one per checkpointed phase, and none should approach 45 minutes.
• Elapsed Time against Compute Time: a large gap means the run is waiting (on callbacks, delays or long-running responses), which is fine; compute time close to the elapsed time in one process means that process is the next one to time out as volumes grow.
• Status: SUCCESS, not COMPLETED_WITH_ERROR. A completed-with-error run finished but hit processing errors, and in a batch design that is where records go missing.

Finally, count the records in the target against the source population. A load that finishes inside the limits but writes 9,800 of 10,000 workers has not been fixed.