Non-overlapping manual child groups — can this actually apply during Dataflow/template generation, not just drag'n'drop?
Hi all,
I've picked up some great tips and tricks for my workflow from this community, so thanks for that. I have a question about how the "non-overlapping" option for manual child groups actually behaves.
What I expected:
I assumed that ticking "non-overlapping" would mean each element gets placed into only one group — even if my rule logic would otherwise match it to several groups. In other words, I expected the setting to resolve the conflict automatically and enforce one-group-per-element.
What actually happens:
When I generate manual child groups via a Dataflow query step or from a template, I still end up with elements matched into multiple groups, even with "non-overlapping" ticked. The setting only seems to kick in when I manually drag an element from one group to another — at that point it removes the element from its previous group. It doesn't seem to prevent or resolve overlaps that come from the query/template rules themselves.
My question:
Is there a way to get this same "one group only" behavior to apply automatically during Dataflow/template generation — so that if my rules would match an element to multiple groups, it's still only added to one of them (based on rule order, priority, or some other logic) — instead of having to manually drag-and-drop overlapping elements afterwards?
I understand the underlying issue is that my query conditions aren't mutually exclusive, and some manual checking will probably always be needed. But if there's a setting, rule-ordering trick, or workaround that makes the non-overlapping behavior apply at generation time rather than only on manual drag'n'drop, I'd love to hear about it.
Thanks!
Comments
1 comment
Hi Piret,
At the moment, I don't think there is a workaround for this type of situation. To avoid these issues, the grouping queries would need to be more precisely defined.
It would probably help if we could define exclusive rules for the groups in addition to the current inclusive rule. At the moment, we can only define inclusive group rules, meaning that a query specifies which objects should be included based on the name of the group.
With an exclusive group rule, we could, for example, specify that objects must not belong to group “X” while still requiring them to have certain property values. This could make it possible to prevent overlapping groups during group generation by adjusting the order in which the groups are generated.
Please sign in to leave a comment.