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.
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.
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.
- 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.
Dormant steps can move to the skipped state
Some designers have built extremely complex step dependencies, and it becomes tough to track your workflow. In such cases, it possible to get into a situation where a step’s run condition is met before its skip condition. If this does occur, the step will be completed and then skipped. This situation will mean you will see the actions performed in the audit trail. However, in the user interface, you will see that the step is skipped.
Note: It is advised that you should always treat the audit trail as the source of truth in such cases.
Suppose you configured a step B as shown below and its sit between Step 1.2 and 2.2.
Step B - Dependency configuration
The timeline of events is as shown.