Derived table, multiple conditions?

Hi there

I have a flow where I lookup order references via API with our transporters, to pull delivery information for performance and tracking purposes.

In this flow I have a number of conditional flows; check if order reference is valid and API returns response or error, check if a shipment has multiple shipment details etc.

Working with the conditional flows makes me go most of the way, but now I’m stuck in a condition where I need to have a calculated condition as well as a condition to check if source table is NOT empty - a combination of 2 of the 3 built in options. Is this even possible?

In flow below I tried to group the different parts of the flow;
A and B - First validation
If import is a success, A takes the flow to the C part, where multiple transformations are made, all derived tables are made if source table is NOT empty.
If import is a failure, B takes the flow to Z where data is prepared for output.

My issue is in the D and E tables, where I can either only derive tables made on a calculation or if source table is either empty or not - What I need, it seems, is a combination of a calculation and a source table that is NOT empty - Is this possible?? Or is there a workaround I haven’t found yet?

1 Like

There is a technique to use a condition of any complexity for table derivation, but I don’t think it’s required here.

As I see it, you need to move blocks C, D, E and table “input2Merge” into a separate module which would be called from a conditionally derived table in the main module (e.g. in table “importSuccess”). Because of that, you won’t need to have conditional derivations in block C at all (they will be all unconditional), and will be able to use a simple condition a-la contains([Field],"addon") for derivation in blocks D and E.

PS. Thank you for a very clear illustration in the question :+1:

1 Like

Thank you!

This did the trick - I have a much cleaner flow now. At least on the input/output page… :smiley:
I have kept the original module almost as-is from webrequest until ‘Table 1’ which is the basis before consolidating with potential import errors.

Illustrations often help to simplify written words … :laughing:

Looks great :slight_smile:

A tip: you don’t have to do another iteration in “importSuccess”, at least you didn’t do it in the original screenshot. You can replace “Iterate” with “Call” and use the “Input” in the “Process import success” module to bring in the dataset from “importSuccess”. That would save you unnecessary web requests and make workflow faster. See this topic on using the “Input” action: Input transform