One-Directional Task and Due Date Propagation/updates From master project template

[Jenny_Hall3]

Hello,

I have a use case where I am needing to use a master project template to manage tasks and due dates for 60 identical, unique projects. When a new task is identified, it needs to be added to the master, and I am looking for a way to use automations to “push” this task and its defined field data start, due dates, category, etc. to all of the other unique projects.

Likewise, I need to be able to push updates to tasks - such as task name, due date, and any other changes from this master across the other projects.

I have been using rules, but noticed that this replicates the task within these projects - like homing them, which causes a circular rules nightmare as well as letting an update in one of these other tasks impact all other tasks (including the master).

I am not a coder, so developing an app that pulls in data is not really in my wheelhouse. Duplicating and moving tasks at this magnitude (each unique project has about 150 unique tasks, some of which have 5-15 subtasks) is not feasible. I was relying on Asana’s automations to make this possible.

Any help would be greatly appreciated!

[Stephen_Li]

@Jenny_Hall3 - welcome to the forum! Could you describe your use case a bit more? It’s not possible to have a project template that pushes new tasks to every instantiation of the template, but depending on what you need, there are likely other solutions.

Some questions: How often (after instantiation) are you adding new tasks to these 60 projects? What triggers those additions? Do you need unique instances of the same task, or can you have the same task shared across all projects? Why have you chosen to manage this work as that many distinct projects? Can you expand on your paragraph about rules (what did you set up, what wasn’t working, add screenshots if possible)?

[Jenny_Hall3]

@Stephen_Li thank you for responding.

The use case is for a large technical implementation that has 58 stakeholder groups (though this will expand). Each of these stakeholder groups are responsible for completing the same set of categorized tasks for go-live (which is why so many separate projects). Each has their own individual project teams and responsible task owners, and have to be granted individual access. To further complicate, some tasks need to be expanded upon (additional subtasks), and due dates are being set as standard, but will vary. I cannot provide more context than this, but a single project with homing to 58 separate projects would be about 10k line items, and with homing… well, I shudder thinking about it.

In terms of regularity of tasks being added, it is not daily. But, we are moving to Asana, and the expanded functionality will mean results could vary, particularly with subtasks (and again, these may be highly unique based on the stakeholder group). From the portfolio perspective (all of these will be within one project portfolio), additional tasks may be identified and added on a monthly, or every two month cadence. Due dates on existing tasks may change at the same rate, but are likely to be done in alignment with the development schedule, so several associated tasks may be updated at once. So even if we have a month where 5 of these are updated, they will need to be replicated across all portfolio projects.

In terms of rules, I have several work management rules I have added, which include:
Updating required fields for reporting based on completion
Updating status based on proximity to due date (approaching, past, etc.)

To manage this specific challenge, I have tried the following:
*Trigger: When a task is added to the “template” master project, add to additional projects (this is what surfaced the homing function being applied to all additional projects where I specified add task, resulting in a loop of rules notifications)
*Trigger: When a task is added, duplicate task and move to specified project (the duplication did not hold the task details. It moved the primary task with details, and retained a task with a [null] name value (not sure if I can do a direct duplication through rules to prevent this). Moving instead of adding to another project solved for the homing functionality in the recipient project, but the master project had that a null task value retained.
*Trigger: When due date is changed, update due date on additional project. This works well, but again, creates homing between the master and the recipient project.

I hope this helps. I have been playing with the duplicate and move function to solve for new task being added, and have even considered trying to figure out if there are other ways to get around this. Unfortunately, we cannot add on any additional workflow tools or products that may help such as Zapier or others.

[Stephen_Li]

@Jenny_Hall3 - thanks for the details! Since you can’t use external tools, I think there are limited options (I’m in the same boat with my org, so you’ll just need to be creative). A few thoughts:

• Is there any way you can streamline your task/subtask list? I’ve had issues previously where I tried to delineate every small detail of work and ended up overwhelming everyone. I like to use the task description as much as possible for instructions/details/etc. and have tasks only represent the level of detail I want to be able to report on.
• I think your best bet is to use a master “template” project (i.e., just a project) like you are trying, but with a few modifications.
• The “template” should be the only project that has rules about adding new tasks. This should avoid any circular logic.
• Perhaps you can use a task-subtask structure where the parent is the meaningful task and the subtasks represent each of your 58 project iterations of that. E.g., Task = Deliver widget A, subtask = Team 1, Team 2, etc. This would work best if you avoid using meaningful subtasks and add info in the descriptions.
• On “template”, create a single-select field with each of your 58 projects as an option. Create a rule that when a task is added, add subtasks to it, 1 for each project (with that project field set), and name the subtasks the same as the parent (this can be done in the rule w/ variables).
• Also create a rule that when a task/subtask is added or the project field is changed, add it to the correct project based on that field.

At the end, you’d have one “template” project with finite tasks (58 subtasks each) and 58 projects with all those same tasks (the subtasks will look like parent tasks in those projects, which is good). Any time you add a new task to the “template”, it will automatically add the subtask version to each project. If you are adding lots of info into the task description, you may want to trigger the first rule on something else so you can also copy the task description to all the children.

[Jenny_Hall3]

THANK YOU. Couple of quick questions:

• On “template”, create a single-select field with each of your 58 projects as an option. Create a rule that when a task is added, add subtasks to it, 1 for each project (with that project field set), and name the subtasks the same as the parent (this can be done in the rule w/ variables).
  Will I need to manually create the subtask name, or can I use a handlebar or something to retain the task name, start date, due date, and other custom fields? This is important as several fields are needed for data mapping to other recipient reporting sources as well as needed for reporting on specifics within the task

• Also create a rule that when a task/subtask is added or the project field is changed, add it to the correct project based on that field.
  caan you tell me a little more about this. If I have layered rules such as when new task is added>create subtask are you saying that I can add an additional layer that adds to the project and can layer these rules within the functions based on the custom single-select drop down? Is it also possible that I can add an additional rule that when that subtask is created it adds to another project as a task? I think that is possible. Just trying to figure out how many things I need to build into this template. I probably could just stand up a new project, pre-establish the rules, and then drop in all the activities to trigger these rules. But half afraid to try just because of sheer number THANK YOU again for providing an alternate solution, this has been challenging.

[Jenny_Hall3]

Realized I didnt tag @Stephen_Li but also, wanted to show a few screen shots of behaviors as follows:

Here is the new activity

I set up the workflow as follows based on my understanding from your comment

I added these as relative values, but unsure how to make it essentially duplicate the parent task because it reads null values later

The parent + subtask are moved to the target project, but have homing on them

Here are the established subtask values based on the relative variables identified - again, not sure how to essentially duplicate the task created as a subtask and then redirect to target project without it sending the whole task with parent and homing back. I am probably missing a step.

[Stephen_Li]

@Jenny_Hall3 - one thing you won’t be able to do is inherit the parent field values down to the subtasks (there is a feedback request here on that topic). If you want them all in the title of the subtask, that’s doable (what you have set up now) but you’ll need to make sure they’re populated first. This might mean triggering on something other than “Task added to project”. I like to create a single-select dropdown called trigger with one option () and trigger on that field changing.

You would want to do a one-time setup of your “project” field with 58 options. You’ll use this in the condition section of rules (this is how you create multiple branches on the same rule).

[Jenny_Hall3]

Thank you again @Stephen_Li I ended up proving this out and finding out some of these pieces of information. I will retest with branching on the condition for the project, but its working!

Thank you again so much, I appreciate the help.