Hey Jennifer,
You could also store Subtasks in the same tables Tasks by creating a "Parent ID" field and using a "self-join relationship." Although, for reporting and managing your templates via the native QB UI, you may be better off creating a child table for Subtasks as you mentioned.
- A Project has many Tasks and a Task belongs to one Project
- A Task has may Subtasks and a SubTask belongs to one Task
Then, depending on your intent, you could use a Pipeline loop through and create all the Tasks at once, such as when a Project is created. Or you could have several Pipelines to create single Tasks when it's predecessor is completed.
Then, you could either have a separate Pipeline create Subtasks when a Parent Task is created. Or alternatively, you could have a step in the Task creation Pipeline to search for child Subtasks and loop through and create when the parent is created by associating them to the freshly created Task ID from the preceding step.
Hopefully, that makes sense!
I could also see how you could architect this system using a many-to-many relationship, where a Projects have many Template Tasks and Template Tasks have many Projects. So you could store the Template Task ID on your actual Task instance if you wanted to run reports from the Template Task context. That could be nice from a manager's perspective to see all open Tasks of a given type via embedded reports (report links). That may save the time of building many Task Status reports since they just kinda work via relationships.
Also, you could create a summary field on the Tasks table that counts all Subtasks. And a second summary field on the Tasks table counting all Incomplete Subtasks (using a condition). Then, if those two values are equal you'd know all the Subtasks were completed and be able to kinda show a progress meter (percent completion).
------------------------------
Brian Seymour
------------------------------