The Verify Data Type operator is not evaluating the correct output. Upon reviewing the execution logs, it appears that this step is not retaining the previous step’s data in thestepInputsection , which results in incorrect evaluation and routing.
Observed Behavior
The Verify Data Type step does not contain the expected data from the prior HTTP step in stepInput.
As a result, the JSONPath condition evaluates against an empty or incomplete payload.
This causes the operator to return FALSE even when a valid match exists.
The above step is not carrying hTTpRequest2.body in step input which in result impact the evaluation .
Expected Behavior
The Verify Data Type step should retain and evaluate the full output of the previous step within stepInput.
The JSONPath expression should correctly evaluate the presence of matching data and return TRUE when applicable.
Impact
This issue affects conditional routing in the workflow, leading to incorrect execution paths (e.g., default steps being triggered instead of approval or validation steps).
Not sure about your use-case here but can you not use simple comparision string operation where you can compare the id stored in the variable and json output you receive. OR is that also giving the error.
Generally i would just verify data types to see if the value exists in response for example if the element 1 in exists in List and then would use compare strings operator and did not encounter such issues.
But may be you can help more with the use-case, I can try to reproduce it in my tenant.
Thank you for your response. I was able to find a workaround.
I’m unable to use “Compare Strings” because it strictly compares string-type values, whereas my use case is to check whether a JSON object (HTTP response) contains a specific value.
The same workflow (using the Verify Data Type method) works in the demo tenant but not in the CU tenant.
Glad to hear that you have managed to find the workaround. Yes, i agree with you i have seen similar occurrances where some code worked in my own tenant but does not work. For most of the cases, i have found the input type values to be the issue but your case could be different :).
Yeah, i’m having this same issue!
Started suddenly, all my workflows was executing perfectly and 4 days ago it just stopped!
I had to change my logic, the odd part is just happening in one tenant in (us-west-2) and for older workflows, new workflow doesn’t seem to be affected!
For example:
If i want to check if the user has manager i usually use $.getIdentity.managerRef.id Exists but this just stopped working!
This logic was executing a few months in and i had to change it!
For this bug, please open a support case so the right team can take a closer look. Creating a formal case helps make sure the appropriate resources are involved and that the root cause is carefully investigated and fully resolved.