Limitations and workarounds for Step dependencies – Solvexia

As with all sound systems, there are limitations to the dependency system. These limitations are a trade-off from the freedom and flexibility that is offered by the step dependency system.

Contravention of formal logic

One of the most critical limitations of SolveXia’s step dependency is the contravention of formal logic when your run conditions involve skipped steps. This limitation means that your run conditions will not work as you would expect intuitively.

If you see that steps are not behaving as expected, don’t worry, this is most likely not because you configured your step dependency wrong. We’ve provided a typical case where this limitation occurs and a global workaround.

Example Scenario

A typical scenario where enabling skip conditions will interfere with your run conditions is shown below.

Step A - Initial dependency configuration

In this specific case, if either step 1.2 or 2.2 is skipped, then Step A would be skipped as well. This will also be true, if say, Step 1.2 skipped, but Step 2.2 completes.

Global workaround

We have a mathematical workaround so that steps can behave as you expect. In simple terms, the workaround is like adding 0 or multiplying by 1 in your equation.

One method is to add a condition that will always be false to the step dependency. Continuing from our above example, you would configure Step A as shown below.

Step A - Updated dependency

You’ll see here that it is always impossible to have Step 1.3 to be completed and skipped at the same time. But this impossible condition is all you need. If, say, Step 1.2 is skipped, and Step 2.2 completes, you will now find Step A will run.

Notes:

The correction step can be any action/data step. It is generally recommended to use a step that will not impact your process.
Other methods will also serve the same purpose, and the discovery of these methods are left as an exercise for curious readers

Skipping takes priority

While it is rare in practice, we have found a common configuration error where designers have provided the same logical equivalent statements in the skip and run conditions.

Here is a self-evident case of the situation.

In this case, the system will be confused as what the designer expects it to do. For simplicity, our developers have designed the system to always skip steps as a priority if any conflicts occur.

Note: In the App, a warning about this limitation will always be shown when skipping conditions are enabled.