Thanks for the question about scoping accounts and variables, and apologies that the information on screen isn’t proving to be helpful in understanding what is going on.
In your case it is probably because the
Refs-Octopus-NonProd account itself has a
Restriction on another environment, and when we try to promote the deployment to production the
AwsAccount variable, having been ‘unscoped’ on environment (implying it can be used in all environments) we need to check to see if
Refs-Octopus-NonProd is allowed to be used there.
I can replicate your behaviour by setting up the following scenario. First create an Account with a Restriction on the dev environment, I create a second account with a restriction on the prod environment.
Then I recreated your project variables in the same way you described.
The deployment to Development environment works because the environment restriction check survives. But in Production it fails, because
aws-test-account is explicitly restricted to Development only, while being referenced by a variable value that is available in all environments (‘unscoped’)
In general aligning the variable scoping with the Account restriction should work. In practice the fix depends on what you want to do. I suspect you want to apply further scoping to the variable like this, so that it is only ever used in that environment.
The other approach would be to relax the restriction on the Account itself, however this doesn’t look like it fits your scenario.
I hope this helps? Please let me know if you feel there is an approach we could take to make this clearer.
All the best,