Read the run, the failed steps and the result separately
Start with the exact run, its trigger and supplied inputs. Then read its failed-step count, the messages for those steps and the application logs for the same time. A run marked Success means the run finished; it does not prove that every step produced the intended work.
Finish with the system the orchestration was meant to change: read the target record, file, event or downstream response back. Logs can explain a failure, but neither a quiet log nor a completed run is the business result.
"Failed to parse Credstore response … CredStore did not return any refresh tokens"
The app validates and builds, but every run fails while fetching the credential's token, before any request reaches Workday. The message points at tenant setup — the integration system user, its API client, the consent — and you can check all three and find nothing wrong.
Each time we hit it, the cause was the credential's type. Orchestration Builder shows the older type as "ISU (Deprecated)"; in the app's source it reads:
"_type": "IntegrationSystemUser"Validation accepts it and the app builds, but runs cannot use it. Replace it with the current type under the same credential name, both in Orchestration Builder and in the app's source, then validate and build again:
"_type": "ApplicationSystemUser"Go by the type, not the name: old and new credentials are both commonly called "ISU" or "Default_ISU", and several of Workday's sample flows still carry the old type. Look at the integration system user and API client only once the type is current.
"Function convertToJson cannot be applied to an instance of JsonType(None)"
convertToJson turns XML into JSON, and the value it was given is already JSON — typically
the output of a text template set to application/json. Pass that template's
message on as it is, or read single fields with JSON-path accessors. Changing
convertToJson's true or false arguments does not help, because the input is the
problem.
"ExtraProperties" or "MissingRequiredProperty"
A step has a setting in the wrong place, or is missing one Workday requires. Compare the step, and the object around it, with the same kind of step in a flow that already validates. A frequent cause is a resource, such as a credential or retry setting, placed outside the flow's resources.
The run says Success, but the work did not happen
A run's status and its steps are separate. Workday can report a run as successful while one or more of its steps failed: the run finished, not every step in it. Read the run's failed-step count and its step messages in the app's logs on the Workday Developer Site before concluding anything from the status.
When you build the flow, make a failed step visible where people look: write a clear failed status onto the record the run was filling in, rather than leaving it looking untouched.
The step debugger cannot run every component
Orchestration Builder can run a flow one step at a time and show each step's inputs and outputs. Workday currently excludes Trigger Business Process, Trigger Integration, Trigger PDF Generation and Send HTTP Request steps that use polling. Some flows also need one tenant run before the debugger can import launch parameters, credentials or documents.
When the debugger cannot reproduce the failing component, use the deployed run, step messages, application logs and observable output instead. Do not replace the unsupported component only to make the debugger available.
A page launches the orchestration, and its parameters arrive empty
The parameter names must match exactly between the page's launch action and the orchestration's read of them:
data.start.queryParams.getParam("requestId")A scheduled orchestration receives no page parameters at all, so read its settings from somewhere a schedule can supply them.
The request body is empty at run time
Build a JSON body with a Create Text Template step set to application/json,
placed before the request that sends it, and point the request's body at that template's
message. Inside a For Each loop, reach the template through the loop's own name, the way a
working sample does. The json:object(…) shorthand is rejected.
Retry only work that is safe to repeat
Put retry and polling configuration in the flow's resources and use the current Workday component shape. A timed-out read is usually safe to repeat; a timed-out create or update can be ambiguous because the receiving system may have accepted it before the response was lost. Read the destination before sending the mutation again.
Workday publishes separate runtime, process, memory, message-size and structure limits for orchestrations. Check the current limit named by the failure and the flow's synchronous or asynchronous context rather than applying one timeout or row count to every orchestration.
Prove the repair at the same boundary
Read a changed Builder graph back, rerun Workday validation, then execute the affected path when the failure was runtime-only. If the orchestration belongs to a larger app journey, use the Workday Extend testing method to check the browser behavior and saved result. For component validation outside the flow, use the validation-error guide.