Interpreting Workflows
Understanding the Workflow Response
After executing a workflow, the API returns a comprehensive workflowResult object. This object is the key to understanding the outcome of every step performed. This guide provides a structured, top-down walkthrough of how to parse this response, explaining each key object from the final verdict down to the granular evidence.
View Full API Response Example
The examples in this guide refer to the following API response for workflow execution 01K4XQGV10NY0Q3SE0F73H9TJX. Click to expand and see the full structure.
Part 1: The Overall Outcome (The Final Verdict)
Start by examining the top-level fields of the workflowResult object. These provide the final, authoritative outcome of the entire workflow execution.
Workflow Execution States (workflowExecutionState)
This field tells you if the workflow ran to completion.
Workflow Statuses (status and result)
This is the final recommendation of the workflow.
Detecting Manual Overrides
It’s crucial to know if a workflow’s result was changed by a person. When an operator manually changes the status (e.g., from FAIL to PASS), the following fields are populated:
statusOverrideRequestId: The unique ID of the override request.statusOverrideBy: The user who performed the override.statusOverrideAt: The timestamp of the override.
To detect an override, check if statusOverrideRequestId exists and is not empty.
Part 2: The Step-by-Step Breakdown (workflowStepResults)
The workflowStepResults array is a log of each step in the workflow, explaining how the overall status was reached. Each object in this array corresponds to a step configured in your workflow (e.g., KYC, AML, IDV).
Workflow Step Results (result)
Part 3: The Granular Evidence (processResults)
For the deepest level of detail, look inside a workflowStepResult at its processResults array. A Process Result Object (PRO) is the raw evidence from a single check against a single data source.
Process Result Classes (class)
Best Practices for Integration
- Check
workflowExecutionStatefirst: Always confirm the workflow isCOMPLETEDbefore trusting thestatusand the returnedorganizationobject. - Debug with
workflowStepResults: When you get an unexpectedFAILorREVIEW, loop through theworkflowStepResultsto find whichstepNamehas a non-passingresult. ThesummaryandprocessResultswithin that step will tell you why. - Log the
workflowExecutionId: This ID is your key for auditing, support queries, and correlating results.
References
For more details on specific workflowResult objects, please refer to our Features section.
