Programmatic Detour

[MarqueeCrew]

I've seen this question before and have run into it myself.  I'd like to see a new tool that would allow a developer (of a workflow) to choose a path of logic based upon criteria known only during the execution of a module.

If LEFT INPUT Count of records < 10,000 THEN Path1 (e.g. use a calgary join)

ELSE Path 2 (e.g. use a standard join)

endif

Thanks,

Mark

[MichelSza]

Yes, good one.

Would also like to see this one implemented.

I too would like to avoid running a branc conditioned to the input.

ie: fill a cache from batch macro if the input has changed and read the cache if not changed.

[simon]

agree - right now detour is limited to user interaction and sometimes we don't want that.

If rec count=0 then by pass and don't create output else do. should be possible esp when using chained apps.

[DanH]

I also agree that this functionality would be useful. There is currently a way to do it using batch macros and tool containers, though the setup is more involved than the proposed feature.

Here are explanations of two similar approaches, one based on Tool Container, and one that's based on Detours. Personally, I think tool containers are a more flexible solution as they can accomodate N conditions and don't require designs with single data streams.

http://community.alteryx.com/t5/Alteryx-Knowledge-Base/Dynamically-enabling-disabling-workflow-secti...

http://community.alteryx.com/t5/Alteryx-Knowledge-Base/CS-Macro-Dev-Conditional-Processing-with-Deto...

[SergioD]

This will be awesome!! 

it's kind frustating have to configure a simple module as an app only because you need an "Smart Detour".

[mcarrico]

Could not agree with this request more.  As someone who is leveraging the software for automation purposes, I am often hamstrung by the fact that I can't make my workflows more dynamic to handle a variety of input conditions.  As a result, I'm often left with multiple workflows (not ideal for end user) or some clunky logic (not ideal for the designer).  The new block until done was a big step for controlling serial processes, but introducing some sort of branching capability would be an enormous help.

[PaulRB]

In my use case, I would use the proposed tool to bypass a Dynamic Input tool (containing an SQL query) when there are zero input rows to that tool. At the moment, even when there are zero input rows, the Dynamic Input tool runs the SQL once. Fortunately, the SQL produces zero output rows, so my workflow results are not affected, but the remote database is so busy and slow that the execution of my flow can be 5 mins plus when it could be 5 seconds.

[GavinAttard]

 Yes, fully support this request. 

I have found ways round it by using macro's in macro's or filter's based on record counts, but it is tedious... 

kr

[Coxta45]

Call me crazy, but I'm pretty this can be done quite easily with a formula and filter tool...

[PaulRB]

@Coxta45 I don't think it can be done that way. Problem is, the filter tool will always send output to the next tool, even if that output consists of zero rows of data. That output activates the next tool, which may not be desirable, even though it has received zero rows input. For example in my use case, the tool I want to avoid activating is a dynamic input tool which queries a remote oracle database. When there are zero input rows, the dynamic input tool still queries the remote database once. This can take a long time, even though no results are returned. So what I need is either a tool that enables me to avoid activating the dynamic input tool when there are zero input rows, or a change to the dynamic input tool so that it does not query the remote database when it has zero input rows.

[Coxta45]

@PaulRB,

Very good point, I clearly hadn't thought about that.  My apologies!

Kind regards,

Taylor