Feature Request: Conditional hideWhen for User Entry #31

New Issue

michael · 2026-01-19T18:31:18Z

michael commented

2026-01-19 18:31:18 +00:00

Originally created by @helder14 on GitHub.

Hi there,

It would be very helpful if Setup Manager supported a hideWhen condition on User Entry steps so they can always be defined in the workflow but only shown when necessary.

Current behavior
• The User Entry step is either always present or not at all.
• If defined, it always pauses the workflow waiting for user input.
• There’s no way to dynamically hide the step based on previous actions or outcomes.
• Scripts run as part of the steps, so the UI is already drawn before their results are known.

Limitation

For example, if a naming script succeeds, I don’t want to ask the user for input. If it fails—or if a boolean flag says input is required—I do want to show the User Entry. Today the only option is to always show the step or move the fallback logic outside Setup Manager.

Desired behavior
• Allow a pre-start script (executed before the steps are displayed) to determine whether the User Entry step should be hidden.
• Support a hideWhen condition based on either:
• The exit code of that script (hide if it succeeded).
• A simple boolean flag (true = hide, false = show, or vice versa).

Example

Imagine the workflow runs a pre-start script first. That script tries to set the device name automatically and sets a boolean value indicating whether user input is required. Then, when the steps are shown on the screen, the User Entry step is either hidden or visible depending on that boolean.

In practice:
• If the script succeeds and the boolean says “false,” the User Entry step never appears.
• If the script fails or the boolean says “true,” the User Entry step is displayed as part of the flow.

Benefits
• The list of steps the user sees on screen is stable and doesn’t change midway.
• Cleaner workflows: the step is always defined but only visible when needed.
• Straightforward logic: true/false decides visibility.
• Matches real-world setups where User Entry is usually just a fallback.
• Backward compatible: if no hideWhen is defined, behavior stays the same.

Thanks for considering this enhancement!

Originally created by @helder14 on GitHub. Hi there, It would be very helpful if Setup Manager supported a hideWhen condition on User Entry steps so they can always be defined in the workflow but only shown when necessary. Current behavior • The User Entry step is either always present or not at all. • If defined, it always pauses the workflow waiting for user input. • There’s no way to dynamically hide the step based on previous actions or outcomes. • Scripts run as part of the steps, so the UI is already drawn before their results are known. Limitation For example, if a naming script succeeds, I don’t want to ask the user for input. If it fails—or if a boolean flag says input is required—I do want to show the User Entry. Today the only option is to always show the step or move the fallback logic outside Setup Manager. Desired behavior • Allow a pre-start script (executed before the steps are displayed) to determine whether the User Entry step should be hidden. • Support a hideWhen condition based on either: • The exit code of that script (hide if it succeeded). • A simple boolean flag (true = hide, false = show, or vice versa). Example Imagine the workflow runs a pre-start script first. That script tries to set the device name automatically and sets a boolean value indicating whether user input is required. Then, when the steps are shown on the screen, the User Entry step is either hidden or visible depending on that boolean. In practice: • If the script succeeds and the boolean says “false,” the User Entry step never appears. • If the script fails or the boolean says “true,” the User Entry step is displayed as part of the flow. Benefits • The list of steps the user sees on screen is stable and doesn’t change midway. • Cleaner workflows: the step is always defined but only visible when needed. • Straightforward logic: true/false decides visibility. • Matches real-world setups where User Entry is usually just a fallback. • Backward compatible: if no hideWhen is defined, behavior stays the same. Thanks for considering this enhancement!

michael closed this issue

2026-01-19 18:31:18 +00:00

michael commented

2026-01-19 18:31:18 +00:00

@scriptingosx commented on GitHub:

Implementing logic like this will render the Setup Manager workflow and configuration profile structure too complex.

You can run Swift Dialog for customized user entry from policy scripts and/or shell actions while Setup Manager is running. This way, you can implement any custom logic and user input action you might require.

@scriptingosx commented on GitHub: Implementing logic like this will render the Setup Manager workflow and configuration profile structure too complex. You can run Swift Dialog for customized user entry from policy scripts and/or shell actions while Setup Manager is running. This way, you can implement any custom logic and user input action you might require.

michael referenced this issue

2026-01-19 18:31:32 +00:00

Feature request: Add restart finalAction #102

michael referenced this issue

2026-01-19 18:31:36 +00:00

Restart request #118

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jamf/Setup-Manager#31