Flow chart cropped after three x yes

[Erik_Ferm]

I have a process with 3 yes/no forks. The problem with that is that the graphic displaying the flow is cropped so I can’t get to the bit that would be executed in case all three forks were yes. (I am assuming 3 x no would be the same.)

Is there a way to see the cropped part?

I think the flow charts are great as they make it very easy to see what is going on which reduces the risk of making mistakes and it would be great to have more than 2 yes/no junctions.

I realise that I could break the process up in smaller parts but that creates a number of small processes which is harder to follow.

[pravse]

I think the chart is meant to be scrollable. @Gustavo @jared FYI

@Erik_Ferm in general, we want to encourage you to modularize your logic into sub-processes for sure. That said, it is not always sensible as you point out.

[Erik_Ferm]

@praveen Thanks for your reply.

It is still early days for me but I love automation so far. I think it has massive potential as it allows us to:

• see the logic in flow charts which are much easier to understand (and remember) than formulas in a workflow
• split the logic into smaller bits and re-use them. This could greatly reduce the number of instances of the same formula. For example, you could have one process to perform calculations that are used both for emails and for a report etc.
• replace lengthy formulas in virtual columns
• put data into any row and column of any table (by calling a dummy process if we don’t need to return any data)

To achieve this, I think it would help to make the values returned from a sub-process a bit more variable like. I know we are no-code but it would help enormously if:

• the returned values would survive outside the calling process
• the returned values could be used in emails and reports
• one value could be used to calculate another, like a=10, b=a+5. This would allow us to split up long formulas in smaller bits

[Former Community Member]

Thanks for your valuable inputs @Erik_Ferm. Modularity is a key design principle for automation and provides extreme re-use at the cost of slight complexity.

The product will continue to evolve and we will definitely explore options for return values persistence.

[pravse]

Hi @Erik_Ferm , yes it is really important for returned values from one task or sub-process to be usable subsequently in other later steps of the process.

This has been a long-standing ask in workflow rule tasks (actually for years!). In fact, we had embarked on that work but put it on hold because it made more sense to target the new automation model. Now that we have this new and richer model, we will be adding these richer capabilities.

In general, we have to fit such concepts into the functional expression language we have adopted (with its Excel/spreadsheet roots). I suspect we will never support a=10, b = a+5 — which is very much like procedural programming. However, there are other approaches to split formula logic into smaller bits by naming and reusing sub-formulas. Today, many of our advanced users utilize virtual columns for this purpose, but that’s sometimes an inefficient thing to do as it leads to a lot of pre-computation which goes beyond just modular logic definition.