Resolving Input Variable Editing Issues in ControlUp Workflows After Recent Update

ControlUp recently updated its workflow functionality with a notice that input variables are now restricted to API-triggered flows and can be marked as “Required.” Additionally, workflows will warn when a flow with input variables is changed to a different trigger type. This update unintentionally disrupted a key capability: running subflows with input variables passed from a main flow. Previously, input variables in subflows functioned similarly to parameters in PowerShell functions, enabling seamless parameter passing and modification within nested workflows.

Users reported that while subflows still received parameters correctly during execution, the workflow editor UI no longer allowed modification or addition of input variables for flows that were not API-triggered. This caused confusion and limited flexibility in workflow design, as input variables appeared hidden or locked outside of API-triggered contexts. There was also concern that input variables should remain editable and available for manual triggers and subflow usage, rather than being limited solely to API workflows.

ControlUp’s development team investigated and identified that the core runtime functionality for passing parameters to subflows had not changed; the problem lay in the editor interface. The editor was erroneously hiding and disabling input variable editing for non-API triggered flows. A fix was prioritized and promptly released. The update restored the visibility and editability of input variables for all trigger types in the workflow editor, allowing subflows to continue receiving and modifying parameters as before. The warning banners and options to remove input variables were removed to avoid user confusion. The “Required” setting remains functional exclusively for API-triggered flows, displayed as a small toggle next to each variable rather than a checkbox.

Users are advised not to use the “Remove input variables” button, as this clears the flow’s variables and may disrupt parameter passing. If variables were removed and parameter passing stopped, users can restore them in the Start node. No other action is necessary to maintain functionality. Support remains available to investigate any persisting issues.

This resolution illustrates the importance of distinguishing between UI/editor features and core workflow execution in ControlUp’s flow management. It confirms that input variable functionality across different trigger types remains intact, preserving the flexibility needed for complex orchestrations involving subflows.

ControlUp documentation on workflows and input variables can be referenced at https://support.controlup.com/v1/docs/create-workflows.

Read the entire ‘Resolving Input Variable Editing Issues in ControlUp Workflows After Recent Update’ thread below:

Today the following release note is posted:
‘Input Variables are now limited to API-triggered flows and can be marked Required. Workflows also warns when a flow with input variables is changed to another trigger type.’

This breaks a important thing: running a subflow from a workflow.

For example, I have created a flow called ‘Get access token’ with input variables ‘URL’, ‘ClientId’ and ‘ClientSecret’.

Until now, I was able to use this flow as a subflow of my main flow. The input variables functions like parameters as in PowerShell functions.

Please rollback this change.

Hey Rico, I can’t reproduce this. My subflows still get their parameters passed from main flows.

Though I guess the UI is pretty alarming.
Plus it won’t let you add/modify variables.

Even with the warning message, device ID is still passed from the main workflow.
(the subflow failed for a different reason)

Yeah it is still passing the variables, I can see. But unable to modify too.

But still.. input variables should still be available for manual trigger. Not only for API. Agree?

Yes.
OR API workflows should be available as subflows

Hi. I’m checking. Will try to rollback it today.

Hi Rico, thanks for raising this, and thanks Dennis for testing it. We found the issue and a fix is in progress. We will release it soon.

You are right that input variables should work for flows used as sub-flows. Running flows was not changed, so sub-flows still receive their parameters from the main flow, as Dennis confirmed. What went wrong is the editor, which now hides and blocks editing of input variables on flows that are not API-triggered. The fix brings the section back for every trigger type.

Until then, please do not use the “Remove input variables” button in the warning. It clears the variables from the flow. If anything stopped working for you, send me the flow name and I will take a look.

Update on input variables: the fix is live.

Input Variables are available again for every trigger type, so flows used as sub-flows can add and edit their parameters as before. The warning banner and the “Remove input variables” button are gone. The Required setting stays available for API-triggered flows, where it is enforced, and it is now a small asterisk toggle next to each variable instead of a checkbox.

Nothing changed in how flows run, and no action is needed on your side. If you used “Remove input variables” since October 9 and a flow stopped passing its parameters, add the variables back in the Start node. If something still does not work, send me the flow name and I will look at it.

Thanks Rico and Dennis for the clear report and the test.

Wow that is really quick! Working like a charm. Thanks for your effort!!

Continue reading and comment on the thread ‘Resolving Input Variable Editing Issues in ControlUp Workflows After Recent Update’.  Not a member? Join Here!