@thbrandtsu did you get it to work?
Hi Sven,
Sorry for the delay, I had to pause and come back to this.
I really appreciate your suggestions. I ended up not replicating exactly what you shared, though your concept inspired a similar solution.
One concern I had was in case a task was buried more or even less, a hardcoded {parent}.{parent}.{name} would break.
So I ended up adding a calculated field to be placed on any task where work is being assigned (not a grouping task). This field checks its ancestry by looking for a Job Number field which is present on the main Deliverable form.
It looks for the name up 4 parents, so great-great-grand-parent 🙂
IF(!ISBLANK({parent}.{DE:Job Number}), {parent}.{name},
IF(!ISBLANK({parent}.{parent}.{DE:Job Number}), {parent}.{parent}.{name},
IF(!ISBLANK({parent}.{parent}.{parent}.{DE:Job Number}), {parent}.{parent}.{parent}.{name},
IF(!ISBLANK({parent}.{parent}.{parent}.{parent}.{DE:Job Number}), {parent}.{parent}.{parent}.{parent}.{name},
"Too many sub-tasks")))))
Of course, now we can pull this field into reporting: "give me all tasks where DE:DeliverableAncestor is not blank and group them by that value".
In my early tests, it seems to be working.
FWIW, I have strayed away from using forms with only calculated fields due to not wanting to confuse PMs with remembering to add various utility forms and also feeling like clutters things up. That said, you have opened my eyes some to the potential value add.
Additionally, we have had some other talks as to what exactly needs to be reported upon and want to explore using a "Milestone Form" which would identify particular tasks as dates to pay attention to as opposed to just pulling in every task with the above Deliverable Ancestor form.
Overall, both methods head one of your initial cautions to be more intentional about what is pulled in vs queries on queries.
Thanks again for "rubber ducking" this with me.