This would be the branch that runs if the length call does not fail. You would basically start with wherever you put your Configure Run After to failed to make the first method to work, and add a parallel branch to add one that runs on success. Here is how you might do it in case you wanted only one Parse JSON action instead of two:Īssuming you have this hard coded input block to test with: I would recommend you test it though to be sure it works correctly for you. In order to avoid this, you could place the logic for processing each specific individual item, into a child flow, for example, which will then avoid this to give you some more detail about the 'smarter method' as it is actually bit more involved to set up - but it could be worth it in case you prefer it, as you would then have only one Parse JSON instead of two. When doing this, you might find that it may seem to be necessary to have the apply to each logic duplicated again. In order to avoid this, you could place the logic for processing each specific individual item, into a child flow, for example, which will then avoid this duplication. The overall result of the flow is successful despite the error - this is because the error is handled using the 'configure run after' Then when testing with the single object input, it is successful - failing over from the block expecting an Array, to the other one expecting a single object as you can tell from the green checkmark on the second block below: I noticed it was not in your original post, so in case, this is the schema to use for the single object off-case. Note - the schema to use for single object (for the second Parse JSON block) is:

There should be a red arrow with dashed line, like this: Then in the 'Parse JSON 2 should run after' screen, you should uncheck 'is successful', then check 'has failed' and then, click 'Done'. (by the way to access the above options you must click the Ellipses on the upper right of 'Parse JSON 2' and click 'Configure Run After')

Here I am using a Compose block, to simulate the input of a single object returned by Azure, at the top of the Flow:

If you know that those are the only two possible schemas, you can have two Parse JSON blocks, one for each schema, hook them to same content for 'Content' field, then use 'Configure Run After' and change it so it is set to when the previous block 'has failed' to try the schema version for a single object 'Parse JSON 2' in case the first one fails for multiple objects schema encountering a single object, and then it will use that fallback block for the single object instead and work correctly. Is there any good way to dynamically switch the schema between object and array ?Įxample of SINGLE OBJECT result from Azure AutomationĮxample of multiple object result (array) from Azure Automation Likewise, if I switch the schema to a single object same it fails whenever I get results in form of array. The issue I'm having is if I use the multiple objects result to build my json schema, it only works for multiple objects and fails when the result is a single object. The result can either be a single object or multiple objects which is represented as array. I have a flow which is getting data from Azure Automation.

Mtasa dymatic object