Scoped Prompted Variables always using the "default"


I have recently had tickets raised from our Live deployment people stating that their prompted variables are not the answers they were expecting.

When I look at the setup we have a prompted variable with a value and no scope, in this instance set to “false”, then a second value, not prompted and a value of “true”, but scoped to an Environment. This would be production, but in the test example screens below, our scope will be “charlie”.

When choosing to deploy to the Bravo environment, the prompt displays as “false” as expected:

When choosing to deploy to the Charlie environment, the prompt displays as “false”, however we were expecting it to be “true”:

If I make both variable values to be prompted, I see two checkboxes when coming to deploy (was not expecting to see two), and I get one “false”, and one as “true”! Although having both shown to the user would be confusing, so doubt this is an acceptable solution:

I have searched the forum and read this article:

Which indicates it should be reading the variable scopes correctly, however due to my testing of one variable, it feels like I would need to find all of our Prompted Variables and we would have to scope all of the “defaults” to be all the ‘other’ environments. Which will be one hell of a task!

Is this expected functionality? I am certain this used to work and I’m wondering if something has been changed?

I updated us to be using the latest version yesterday (Octopus.2023.2.13151-x64), just in case it was a version thing, but it has not resolved the issue.

Thanks for any help or things to try

Hi @peter.weston,

Thanks for getting in touch!

With the variables configured in this way, I would expect the Checkbox prompt always to appear, regardless of which environment you are deploying to.

However, when deploying to the Charlie environment, the variable defined will overwrite the prompted checkbox.

Checkbox unticked (so value false)

Value output as true due to the scoped value being more specific than the unscoped one

There are essentially two different checks occurring at slightly different points.

On the initial “Deploy Release” page:
Is there a prompted variable that applies to this environment? If yes, show the checkbox - The unscoped value means this is always yes.

Once the Deployment executes:
What is the most specific value to use for this variable - When deploying to environment Charlie, this will force the value to be true regardless of the checkbox response


1 Like

Thanks for the quick response Paul.

So what we are saying is that even though the user can see the checkbox, and its value is “false”, if they ignore it and click deploy it will actually be “true” when doing the deployment to the Charlie environment, because it has a scoped value?

I cannot see our production deployment team being happy that they can see the value on the deployment, but it’s then different to what they have seen. Currently they go and tick the checkbox to make it “true”, if I am reading your response correctly, that action is pointless as it would be overridden anyway?

Sorry, but in that case, why have prompted variables at all if the user interacting with them does nothing if there is an underlying scope? Surely the reason we prompt the user is to give them the choice (especially in our internal QA deployments) so they can decide at deployment time, and not due to the variables being correct.

I will have to investigate all of our projects and revisit the initial setup if that is the case.

That’s correct.

In this scenario, the only reason I could see to have the scoped value is to protect against user error at deployment time.

Let’s say you have environments Dev, QA, UAT, Prod.
You’re OK with the user managing the checkbox at deployment time for Dev, QA, and UAT, but you know that deploying without the checkbox in Prod would cause a problem, so you scope the value to true for Prod. That way, no matter what the user does when deploying to Prod, you are confident the correct value is used.

I do agree that it can appear confusing to show the checkbox when it isn’t being used, but unfortunately, that is a side-effect of defining the variables in this way. As you mentioned earlier, scoping the prompted variable to the specific environments you want it to be used in would fix this but I appreciate that could be time-consuming if there are many projects and environments to consider.

1 Like

Thanks for clarifying Paul, appreciate it.

As long as I know, I can raise it and see how we take this forward.

Have a great weekend.

1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.