I have a “Task” database that references itself to create a Parent (One) to Subtask (Many) relationship.
I’m trying to create an automation where subtasks always inherit a specific set of relationship fields from their their parent tasks. For example, if Parent Task is added to a “Sprint”, I want it’s Subtask to also be related to that sprint without having to set the sprint field manually on each Subtask.
Sounds easy enough, but I’m having a hard time preventing loops, because a task can be both a parent task and a subtask at the same time and updating the sprint field in those situations triggers the rule again.
I could just create a bunch of helper formulas, like Parent Task’s Sprint = [Parent Task].Sprint and then if/when those fields change, copy them to the task that triggered them, but I’ve been avoiding that so far since it doesn’t seem very elegant to have all these duplicated fields purely to get around the loop detection.
I don’t understand why you have set up the automation as you have: you are triggering on a field updating, and then updating the triggering field on the same entity.
I think you need to make an automation where the update action affects an entity that is not the triggering entity, i.e. if a field changes in one task, update the child tasks, or (as @Matt_Blais suggests) if a task gains a child task, update the child tasks.
@Matt_Blais I don’t think that would work for me because if a parent task’s due dates needed to be mirrored to every child task, and then the parent’s due task changed after the linking had already been done, the “entity linked to a task” trigger won’t fire…
@Chr1sG I have the filter “When Parent Task is not empty” which I was hoping would only update the fields on Subtasks. The issue is some Subtasks are also Parent Tasks
Anyways, my solution is to use helper lookup fields, which I didn’t want to do, but it doesn’t seem like there’s a clean option that would work with just a single rule.
