Description: The Communication Wizard v2 only recognizes the single top-level category set in the block settings when displaying Personalization Segments. Segments organized into subcategories under that parent are not shown in the wizard picker unless they are also directly assigned to the top-level category, creating a significant organizational gap as segment libraries grow.

Additional Details: The current workaround is assigning every segment to both its subcategory and the top-level Communications category simultaneously. While this keeps segments visible in the wizard, it eliminates any practical benefit of subcategory organization from the sender's perspective. The picker remains a flat, undifferentiated list regardless of how segments are categorized in the backend.

The wizard's segment picker also has a single All/Any toggle that applies uniformly across every selected segment. There is no way to apply different logic across different types of segments, for example requiring that a recipient match any one campus segment AND any one ministry segment. This forces organizations to pre-build combination segments rather than letting the wizard compose them dynamically.

Security on segments currently cannot be set at the subcategory level, meaning access control requires individually permissioning each segment rather than inheriting from a parent category.

Ministry Need: Multi-campus, multi-ministry organizations commonly maintain large segment libraries covering campuses, ministry areas, grade ranges, demographics, and more. We manage over 70 segments. Without subcategory support in the wizard, senders face a flat list of 50+ items with no visual grouping, which increases the likelihood of selection errors and makes staff training harder.

The v1 Communication Wizard allowed segments to be scoped per communication list, which provided great organization. That scoping is gone in v2, making the segment picker the only tool senders have to find what they need, and it currently does not reflect subcategory structure. Permissions can be set per segment, but this is a nightmare to set up at scale.

Segments should function as refinement filters on top of a communication list, not as the audience source themselves. The current flat picker UX pushes organizations toward overbuilding segments to fill the gap.

Why This Matters: Rock's goal with the v2 wizard is to make communication more accessible and efficient for ministry staff. A sender who can see Campus segments grouped separately from Ministry segments makes faster, more accurate selections than someone scrolling a flat list. Subcategory-aware logic would also reduce the number of segments organizations need to build and maintain, which aligns with Rock's own guidance that smart use of segments cuts down on the number of lists needed.

The specific requests are:

• The wizard picker should surface segments in subcategories of the configured parent category, not only segments directly assigned to that parent
• The picker should visually group segments by subcategory
• The All/Any logic should be applicable per subcategory group, not only globally across all selected segments
• Security should be inheritable at the subcategory level
• Segments in the wizard picker should be sorted alphabetically, not by creation date (there is already an idea submitted about this, so I won't dwell on that here)