Conditional Visibility & Calculate on Hidden
ROI Studio lets you control whether supported elements are visible based on values elsewhere in your Calculator.
For calculated Outputs, Calculate on Hidden also lets you control whether a hidden Output continues to participate in calculations.
Together, these features let you create models that adapt to the user's choices without unnecessarily displaying every component.
What is conditional visibility?
A Visibility Condition determines whether an element should be displayed.
For example, you might have a Toggle asking:
Include Implementation Costs?
When the user selects Yes, additional cost Inputs could appear.
When the user selects No, those Inputs could remain hidden.
This can make larger Calculators easier to use by showing information only when it is relevant.
Where visibility conditions can be used
Visibility conditions are available on supported ROI Studio elements.
They can also be used with structural components and multi-page Calculators.
Examples include:
Inputs
Outputs
Dynamic Value Text
Columns
Accordions
Micro Tabs
Pages
The available controls depend on the component you're configuring.
Add a Visibility Condition
To configure conditional visibility:
Edit the element you want to control.
Find Visibility Condition.
Choose the value or element that should control visibility.
Configure the required comparison.
Enter or select the comparison value.
Save the element.
Preview the Calculator and test the condition.
The element will then be displayed according to the configured condition.
Use another value as the condition
Visibility conditions can reference values elsewhere in the Calculator.
For example:
Show Implementation Costs when Include Implementation = Yes
or:
Show Additional Savings when Adoption Rate > 50
This allows the Calculator experience to respond dynamically to user assumptions.
Comparison operators
Visibility logic uses comparison operators to evaluate the condition.
Supported comparisons include:
Greater than
>Less than
<Equal to
=
Choose the comparison that reflects the behaviour you want.
Example: optional implementation costs
Imagine your Calculator contains:
Toggle — Include Implementation Costs?
with:
No = 0
Yes = 1
You could configure an Implementation Cost Input with a Visibility Condition based on that Toggle.
When the Toggle value meets the condition, the Implementation Cost Input appears.
Otherwise, it remains hidden.
This keeps the Calculator focused on assumptions that are relevant to the current scenario.
Example: conditional narrative
Visibility conditions can also be useful with Dynamic Value Text.
For example, one statement could appear when ROI is above a particular level, while another statement is shown under a different condition.
When doing this, make sure the narrative remains accurate and appropriate for the underlying calculation.
Conditional pages
Multi-page Calculators can also apply a Visibility Condition to individual pages.
This lets an entire stage of the Calculator appear only when it is relevant.
For example:
Core Inputs → Optional Costs → Results
The Optional Costs page could be conditional rather than always displayed.
For more information, see Multi-page Calculators.
Visibility creates dependencies
When one element controls the visibility of another, ROI Studio creates a dependency between them.
This matters when editing or deleting components.
If you attempt to delete an element that is still being used for visibility, ROI Studio can block the deletion.
You may see:
Cannot delete! This component is used in other components for the visibility.
Before deleting the element:
Find the components that use it for visibility.
Change or remove those Visibility Conditions.
Save the affected components.
Retry the deletion.
Page visibility dependencies
The same principle applies when an element controls the visibility of a page.
ROI Studio can display:
Cannot delete! This component is used for the visibility of pagination.
To resolve this:
Open Multi-Page Options.
Open Setting Pages.
Find the page using the element.
Change or clear its Visibility Condition.
Save the page configuration.
Retry the deletion.
This prevents you from accidentally breaking the Calculator's page logic.
Calculate on Hidden
Visibility and calculation are related, but they are not the same thing.
A calculated Output may be hidden from the user while still being required by another calculation.
Calculate on Hidden controls whether that hidden Output should continue calculating.
Why Calculate on Hidden matters
Consider this calculation chain:
Calls Contained
↓
Agent Hours Saved
↓
Labour Cost Saving
↓
Net Annual Benefit
You may decide that Agent Hours Saved is an intermediate calculation that doesn't always need to be displayed.
However, Labour Cost Saving may still depend on it.
If the hidden Output stops calculating, downstream results can be affected.
Calculate on Hidden lets you determine whether the calculation should continue even while the Output itself isn't visible.
Hidden doesn't necessarily mean unused
This distinction is important:
Visibility determines whether the user sees the component.
Calculate on Hidden determines whether a supported hidden Output continues calculating.
A value can therefore be visually hidden while still playing an important role in the calculation model.
When to enable Calculate on Hidden
Consider enabling Calculate on Hidden when:
The Output is used by another formula.
The Output is an intermediate calculation.
The value should continue contributing to final KPIs even when it isn't displayed.
Visibility is being used to simplify presentation rather than change the underlying business logic.
For example:
Internal calculation hidden
Agent Hours Saved
↓
Visible result
Annual Labour Saving
The hidden calculation may still need to operate for the visible result to remain correct.
When a hidden value should not calculate
There are also situations where hiding an Output should represent removing that calculation from the active scenario.
For example, a conditional benefit might only apply when a particular option has been enabled.
In that situation, continuing to calculate the hidden value could produce results that don't match the scenario the user has selected.
The correct behaviour depends on the business logic of the model.
Visibility is not business logic by itself
Avoid assuming:
Hidden = zero
or:
Hidden = excluded
unless you've deliberately configured the model to behave that way.
Conditional visibility primarily controls presentation.
Review the calculation behaviour separately and decide whether Calculate on Hidden should be enabled.
Test downstream calculations
Whenever you combine Visibility Conditions with Calculate on Hidden, test the complete calculation chain.
For example:
Set the condition so the Output is visible.
Record the downstream results.
Change the condition so the Output becomes hidden.
Check whether the hidden Output should continue calculating.
Review every downstream result that depends on it.
This is particularly important for headline KPIs such as:
Annual Benefit
Net Benefit
ROI
Payback
Use conditions to simplify the experience
Conditional visibility is most useful when it reduces unnecessary complexity.
For example, instead of showing every possible Input simultaneously:
Does your organisation currently perform this activity manually?
If Yes:
Manual Hours Employees Involved Hourly Cost
If No:
Those Inputs remain hidden.
This creates a more relevant experience without requiring separate Calculators for every scenario.
Don't overuse conditional behaviour
Too many conditions can make a Calculator difficult to understand and maintain.
If many components depend on several layers of conditional logic, consider whether the Calculator would be clearer using:
Separate pages
Accordions
Micro Tabs
Simpler calculation paths
Conditional visibility should make the experience simpler for the user, not make the underlying model unnecessarily difficult to maintain.
Preview every conditional path
Before publishing, test the different paths users can take.
Check:
Whether the correct components appear
Whether hidden components disappear as expected
Whether page visibility works
Whether hidden calculations continue when they should
Whether excluded calculations stop contributing when appropriate
Whether downstream Outputs remain correct
Whether Dynamic Value Text still describes the scenario accurately
Don't test only the default state.
Best practices
When using conditional behaviour:
Use conditions when they genuinely simplify the experience.
Keep the controlling value easy to understand.
Use supported comparison operators consistently.
Remember that visibility creates dependencies.
Check dependencies before deleting controlling elements.
Treat visibility and calculation behaviour as separate decisions.
Enable Calculate on Hidden when hidden intermediate Outputs must continue calculating.
Don't assume a hidden value automatically becomes zero.
Test every important conditional path.
Review downstream financial KPIs after changing conditions.
Related articles
Adding & Configuring Inputs
Adding & Configuring Outputs
Dynamic Value Text
Creating & Editing Formulas
Multi-page Calculators
Editing, Copying & Deleting Elements
Last updated