We’re currently evaluating an option that will provide the functionality offered by nested groups, but removes the complexity nested groups adds. We appreciate your patience on this ask and want to ensure we deliver a solution that benefits all of our customers. Below are use cases that we’d like for you to stack rank, with #1 being priority for you. We thank you for the continued comments and feedback.
Use case A: nested group in a cloud security group inherits apps assignment
Use case B: nested group in a cloud security group inherits license assignment
Use case C: nesting groups under Office 365 groupsAnonymous commented
Dynamic groups do provide value, but cannot be used in all situations and relies on attributes of an AD user account which is not practical in a large enterprise environment. These are static and don't change nor do we delegate to users the ability to change. In cases where we want to delegate to system owners the ability to manage access (say a CRM instance) we typically would authorize via an AD group and give ManageBy rights to the owner. In a Hybrid environment you want to try a limit the number of places where users\teams need to manage their groups. we don't want them having to manage in both AD and Azure. In the example of CRM online, we authorize via a Group, but it has to be an Azure Group as external users (3rd party support) needs access and since they cannot be added to an AD sync group they must be added to the Azure group. All of the on-premises users are a members of the AD sync'd group which would allow the owner to manage as they have always, but since nesting breaks here the user have to be a member of both groups. Seem ridicules . this is just one example where Nesting is needed.