I have a basic process as follows:

Run Task A to get result
If A.result = X, then do Task B else do Task C
Do Task D (always)

If I understand flows correctly, I would first create these Tasks:
Task A - query
Task B - conditional action
Task C - conditional action
Task D - unconditional action

In Task A, I'd have Task Conditions that force control to Task B or Task C. The question is what happens after B/C end and what additional flow configuration is necessary to get to Task D (and avoid things like flowing from B into C).

If I understand flows correctly, we need:

Task A - OnSuccess - If X, go to Task B
Task A - OnSuccess - If not X, go to Task C
Task B - OnSuccess - go to Task D

There would be no need for an OnComplete within Task A since control won't come back to it once forced to Task B/C. Similarly, nothing is needed on Task C since flow will naturally head to Task D with the default OnSuccess - go to next Task.

Is this accurate or does control return to A after B/C end? Note: if this works as I believe, then I don't actually need "if X, go to Task B" since that's the next natural step for anything being directed to Task C via the Not X Condition.


And for the extra credit, how does this work within a loop?

Task A - get List of keys
Loop - for each key

Task B - perform query using key
Task C - action to be performed only if key satisfies some condition in B (eg., there are records for the key)

end Loop
Task D

How do I initiate the next iteration of the loop, avoiding Task C, when the condition is not satisfied within B?

The initial flow control in Task B seems simple (OnSuccess - rowcount > 0, go to Task C). And I don't think anything special is needed within Task C. But how do I skip Task C and initiate the next iteration when rowcount is 0 in Task B? I don't want to pass control directly to Task D since that exits the loop. And I'm afraid to explicitly pass control back to Task B since I'm guessing that won't be treated as a new loop iteration and I'll be caught in an infinite loop.

Even though standard is that it moves from Task A to B right now I think it is good that it is explicitly used now (Continue to Next Task) as we may remove the "auto correct" later.

As for your other question, how to skip C I think there are a lot of things that can be improved here but I would not use Flow but normal Condition for this, the Variable Condition. That should work.

Please make any suggestions how you would like it to work.

---

Hi Henrik/grendel70

I know we have briefly discussed this kind of thing on another thread but I still can't help thinking that a simple 'IF' task might resolve this challenge (unless I am thinking at cross purposes here?).

For example if User Variable X contains a particular int value:

IF X equals 1 then run TASK A (perhaps an option to say ....OnSuccess continue to TASK E otherwise continue)
IF X equals 2 then run TASK B (perhaps an option to say ....OnSuccess continue to TASK E otherwise continue)
IF X >= 3 then run TASK C (perhaps an option to say ....OnSuccess continue to TASK E otherwise continue)
TASK D runs Default catch-all action (Error, or set variable or whatever) OnSuccess continue to TASK E.

I know this is mostly covered functionaly with Conditions and/or FLOW, but where I am coming from is also from a self-documenting perspective, where we can look at a VC Job and see at a glance what it is doing. Also, logically speaking this would also stand up within a LOOP whether the value 'X' is incremented or not.

Just a thought

Cheers

Andy

As for your other question, how to skip C I think there are a lot of things that can be improved here but I would not use Flow but normal Condition for this, the Variable Condition. That should work.

Please make any suggestions how you would like it to work.

The Loop control item is only an issue when Task C is the final step of the Loop. In any other place, flow can be forced around Task C. As such (and maybe for other reasons too), perhaps there should be a Flow option of "Continue to Next Loop Iteration". "Exit Loop" might also be useful although than can be handled by forcing flow to the first step outside the loop. Exit Loop is just a little more obvious and avoids the need to explicitly declare/be linked to whatever the first non-loop Task is (kind of like "Continue to Next Task").

For now, my solution is to throw in a dummy Task at the end of the loop to provide a place to branch around Task C and allow for easy continuation to the next iteration.