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 groups
#1 Use case A: nested group in a cloud security group inherits apps assignment
#2 Use case B: nested group in a cloud security group inherits license assignment
#3 Use case C: nesting groups under Office 365 groups
assuming #1 means that SCIM associations would also be applied for any nested groups.
Interestingly I do see that it did create the sub-group in the SCIM application it just didn't assign the users to it which were not in the parent group.
Yes; this is really a big deal. One can add groups to a group as a member, but then when provisioning users SCIM does not then apply the users from the sub-groups to the provisioning and instead says it skipped them in the trouble shooting log because they are not assigned. It clearly sees they are members or are assigned, but decides not to assign them to a SCIM application because they are not assigned; very confusing. I only know this from reading the trouble shooting logs and then being totally confused and then found this issue which seems to suggest that what I'm seeing is a known issue. It makes it a real management/admin struggle.Wade Chandler supported this idea ·