In a case like this
| Full name | State |
|---|---|
| 1 | Open |
| 1.1 | In progress |
| 1.2 | Done |
| 2.1 | Done |
| 2.1 | In progress |
| 2.1.1 | Open |
how do you image this would look in practice?
Prioritize sort based on state, and ensure subtasks stayed with their parent.
So it would be:
- 1 (1.1, 1.2)
- 2 (2.1, 2.1.1)
Sorry, I’m on mobile at the moment and can’t provide helpful formatting. But it would be similar to how just sorting is now (with only one level of self-relation grouping). The grouping is maintained, and the sorting applies within each level.
In this case, it worked out great: since some fields are only populated for specific rows (and are empty for other levels), I can sort by those fields first and then apply a general sort for all records. Thank you very much! 
The issue remains, however, for cases where all rows share the same fields but still require different sorting logic based on their level — though I imagine that’s a much rarer scenario.
This serves as food for thought on whether the functionality we discussed above is necessary.
1 Like
Just for clarity and as a possible workaround 
For these sub-numbers, we created an additional field that only gets populated for them, copying the value we want to sort by into it. (For example, if the name contains dot in name - for ‘1.2’ or ‘2.1’, the Status is copied into this specific field). Then, we sort first by this field (external field status) and then by ‘Full Name’.
This probably will achieve the result.
Thanks for a fruitful discussion.
Sidenote: a recursive formula can be used to get info from the highest level for every child/grandchild/… item in lower levels, e.g. something like this
TopLevelState := If(IsEmpty(Parent),State,Parent.TopLevelState)
and I can imagine there might be use cases where this need can be solved by creating such a formula and using it as part of sorting rules.
1 Like