We generally suggest drawing a line between system inputs & and expected outcomes , and then handling the latter ones in the scripts or even after export.

That approach would be preferable in the majority of most situations, and you are likely well aware of how the data-driven Expected Results in Manual scripts facilitate it.

...

The left part of the equation is dynamic, and it changes based on the scenario. The right part is fixed, and it determines the step verbiage. If the equation is evaluated as TRUE, the step is performed, ; otherwise skipped. Multiple conditions could be stringed together with AND, OR, etc. This approach is preferable when the number of unique steps is low compared to the overall length of the script.

...

Within each block, you have the flexibility to write a completely different script if necessary. Depending on the overall length, you may consider putting each block on a separate tab in Automate and placing the subsetting {} value in the Background section.

Forced Interactions

Another feature is the internal variable (at the bottom of the dropdown list) which comes from the Forced Interactions tab. First, you can specify the conditions (even one).

...

• No need to repeat the scenario blocks, which saves the time on the creation & maintenance of hardcoded text.
• Simple dependencies are easy to implement and review with the stakeholders.
• If you switch the overall execution approach to just the data table, you will already have the expected result populated there as well.

Downsides:

• For complex dependencies, extra intervention in the algorithm could reduce the efficiency and unnecessarily increase the number of scenarios.
• If the whole column is not populated, the script will get the value “No expected outcome” for blanks, which a) could cause confusion; b) would need to be treated as “skip the step” by the automation framework.
  • You could side-step this challenge with the freeze/reimport combination.
• This does not support differences in multiple steps, only in 1 line.

...

Why: multiple simple dependencies throughout the flow (i.e., you can have multiple action-result parameter pairs to use in multiple steps)

This approach can also be used for a single dependency as well, in which case the only difference from Expected Outcome is that the parameter requires constraints instead of forced interactions.

The downsides are the potential complexity of constraints and the “cluttered” artifacts like Mind Map and Parameter/Scenarios tables. As you probably guessed, this approach would struggle with dependencies across 3 or more “actual” parameters.

Some of the challenge challenges can again be mitigated using the freeze/reimport combination.

...

...