Since the resolution of this issue: https://github.com/OctopusDeploy/Issues/issues/2792
a tenant can only progress lifecycle phases if that specific tenant has been deployed for the previous phase. This meets the intended design discussed in the RFC(s) which is to ensure releases are deployed to environments for a specific tenant in the correct order.

The canonical example for this is: "For certain customers we are required to deploy a release to their UAT environment before promoting that release to their Production environment."

This suggestion is to allow a tenant to progress if X other tenants have been deployed for a phase, where X is a configurable value.

The example here might be: "I want to ensure a certain release has been deployed successfully to at least 5 tenants in the UAT environment before the release can be deployed to any tenants in the Production environment."

This may be quite difficult to model and implement, so we will need to be careful about how to approach a solution for this scenario.

In the meantime the best solution is to only connect tenants to multiple environments where you want to enforce a strict linear progression.

A potential workaround: for each logical "tenant" create multiple tenants each connected to a single environment. This would circumvent the tenant-aware lifecycle rules.

For example: "I have a tenant called 'BestCustomer' and sometimes we want to deploy releases to a UAT environment, sometimes we want to go straight to Production. I created 'BestCustomer-Production' connected to the Production environment, and 'BestCustomer-UAT' connected to the UAT environment. Now I can use this permissive lifecycle to promote releases as I see fit."