Short Summary
This article explains how to use conditional connections and Show/Hide rules to control workflow flow based on operator input, and how that affects what gets captured in the Session Report.
Context
Not every workflow follows the same path every time. Some steps are only relevant depending on the product being built, the result of a previous step, or a decision made by the operator. Next Plus handles this through two mechanisms: conditional connections between steps and Show/Hide rules on steps. Understanding both — and how they interact with the Session Report — is key to building clean, flexible workflows.
How It Works
In the Next Plus workflow designer, you connect steps using arrows. Each connection can carry a condition configured via the Conditions Wizard. When an operator signs a step, Next Plus evaluates the condition on the outgoing connection and routes the operator to the correct next step automatically.
Alternatively, you can use Show/Hide rules to control whether a step is visible at all during a session, based on field values or variables set earlier in the workflow.
The Session Report is the output record of the session. It is generated automatically and captures every step that was signed during execution. Steps that were skipped or hidden depending on the path taken may appear differently in the report depending on how they were configured — so it's important to test both paths before going live.
Step-by-Step: Setting Up Conditional Flow
Build the workflow steps first. Create all the steps your workflow needs — including the optional ones — before adding conditions. It's easier to wire conditions once the full structure is in place.
Draw connections between steps. In the workflow designer, connect the step that contains the decision point to each possible next step.
Add a condition to a connection. Click a connection arrow and open the Conditions Wizard. Select the input field or variable that drives the decision, choose the logical operator (equals, greater than, is null, etc.), and set the value.
Configure the alternative path. Add a second outgoing connection from the same step pointing to the alternative next step, and configure its condition to cover the other outcome. If one path is your default/fallback, you can leave its connection without a condition — it will be taken when no other conditions are met.
Or use Show/Hide instead. For cases where you want a step to simply not appear rather than route around it, configure a Show/Hide rule on the step. The step will only appear if the condition is satisfied.
Use triggers for additional automation. If a condition should trigger an action beyond routing — such as displaying a warning, setting a variable, or opening a form — add a Trigger to the relevant step and use the Conditions Wizard to define when it fires.
Test both paths. Before publishing, simulate the workflow through both the true and false paths. Check the resulting Session Report in both cases to confirm the output looks correct.
Example
A workflow for component assembly includes an optional inspection step that only applies to high-tolerance parts.
The operator selects a part category in Step 1. Step 2 is the standard assembly step. After signing Step 2, two outgoing connections are evaluated:
If the field "Part Category" equals "High Tolerance" → the workflow routes to the Inspection step.
If the condition is not met → the workflow skips directly to the Final Sign-Off step.
The Conditions Wizard is used on both connections to define this logic. The Session Report captures whichever steps were actually completed, giving a full and accurate execution record.
Best Practices
Design the full step structure before adding conditions. Trying to wire conditions while building steps leads to messy connections.
Name your steps and connections clearly so it's obvious at a glance which path is which.
Use Show/Hide for steps that are contextually irrelevant. Use conditional connections when the routing itself carries meaning (e.g., pass vs. fail paths that lead to different follow-up actions).
Always test both the positive and negative path through a condition. The Session Report output can differ between paths and needs to be validated for both.
Keep condition logic simple. One clear field per connection is easier to maintain than compound AND/OR logic unless it's truly necessary.
Common Mistakes
Setting conditions on only one connection and leaving the other open. If you configure a condition on one outgoing connection but forget to configure the fallback, both connections may trigger simultaneously or the fallback may fire unexpectedly. Always define the logic on all outgoing connections from a branching step.
Using Show/Hide when a conditional connection is more appropriate. Show/Hide is good for toggling visibility, but it doesn't route the operator. If the workflow should actively guide the operator to a specific next step, use conditional connections instead.
Not testing the skipped path's impact on the Session Report. Assuming the report will look clean on both paths without testing often leads to surprises. Always review the report output for every path before go-live.
Nesting conditional logic too deeply. Multiple layers of conditions in a single workflow become difficult to troubleshoot. If the logic is getting complex, consider splitting into separate workflows and using the Go to Workflow trigger action to chain them.