Synchronous Orchestration Returns a 500 Error When Making Many Sequential PUT Calls
What it means
A PMD page calls a Synchronous Orchestration in a loop to make many sequential PUT calls against a custom object, for example approving 1,000+ pending records at once. Once the total call count gets high enough, the page gets back a 500 error. The real cause isn't the call volume itself, it's the orchestration exceeding Workday's documented synchronous runtime limit, which is much shorter than the asynchronous limit.
Troubleshooting
- Check whether the orchestration is invoked as Synchronous or Asynchronous from the PMD page; sync orchestrations invoked from a PMD have a hard runtime limit (documented around 25 seconds), far shorter than the limit for async orchestrations.
- Time how long the loop of PUT calls actually takes outside the PMD (for example via Postman) to see whether it exceeds that sync limit even though each individual call is fast.
- Check whether partial completion occurred: if some but not all records were updated when the 500 fired, that confirms the orchestration was cut off mid-run rather than failing outright.
- Review Workday's current published runtime-limit documentation for sync vs. async orchestrations, since these limits have changed across releases and are easy to misremember.
Reduce the batch size per invocation so the loop of PUT calls comfortably finishes inside the synchronous runtime limit, and let the user trigger multiple smaller batches instead of one large "Approve All".
Convert the orchestration to an Asynchronous template so it isn't bound by the short synchronous runtime limit, and have the PMD page poll for completion (or notify the user when the batch finishes) instead of blocking on a synchronous response.