Curious about the workflow/need, because I’ve never run into this kind of requirement. And did Support/Engineering explain the status of the request?
Thanks,
Larry
We are a large Marketing/Communications department, and when we are kicking off a campaign we want a task per team to live in projects as the BRIEF and multi-homed in Calendar projects for tracking activations. In order to get a task per team, I need Asana to read the main Campaign BRIEF task and create subtasks per team that includes details specific to their team pulled from this Campaign BRIEF task. We have one field to mark which teams to create requests for, and originally wanted Asana to read this field and create a subtask per team (multi-homed in their respective intake projects for review/acceptance) - however if we try this in ONE rule, it reads the first match to trigger and skips all others. Separating this into multiple rules so that all selections could be read THEN trigger a conversion to Project using a template ended up skipping some rules/subtask creations before converting (no order of operations for rules). So we ended up splitting the rules, AND splitting into sections in this “background project” to get that order of operations we need to ensure all rules are read BEFORE converting the Campaign BRIEF task into a project.
Converting the main task into a project also adds those subtasks into the project, so we have one overall project for tracking all activations in the campaign and can click into the request tasks for other teams if we need to get into the weeds on their progress. Can also build a portfolio to house all projects if we want to see that view (haven’t found a way to automate this, but would LOVE one) - however some teams work from a task only (social, paid media, etc) and do not create full projects, so a portfolio would still miss some high-level details.
Support/Engineering says they have received “multiple reports” of this issue, but have no answers.
Thanks, @Beth_Seeber.
I’m not sure I can fully comprehend, but most rule timing issues I’ve been able to address by gating the dependent rule with a separate When task is in section X, which means it could be done in one project, then ensuring that doesn’t happen (that the task isn’t moved there) until all precedent rules are known to be complete.
I’m not sure if that would help (and I don’t think this is something to be worked out async in a Forum!) but I did want to throw that out there just in case.
Thanks,
Larry
I appreciate the reply! Though I’m pretty sure it’s a timeout issue above all - swapping places of the sections and adjusting rules to the new order still makes it time out at the same point (# rules fired) in the flow. As you said, there is no way currently to ensure all rules are fired before the rule to move the task to the next section fires and any remaining needs are missed.
Order of operations for rules would fix this, or at least limit the number of rules needed to work this (extensive) bandaid solution.
1 Like
Until we have more control over rule order in the future (hopefully), I have a “Subtask Phase” field (that I now have made private so only I see it and it’s not cluttering up tasks). I have added Phase 1 through Phase 4 as choices in the field (works for my most complex flows), but you could add more as needed. I then have the rules creating subtasks able to rely on initial triggers and what the subtask phase is currently set to, in addition to any other criteria of my flow (section/other custom field choices). Here’s a condensed example of how it’s helped:
- Form initially submitted by HR to IT
- Create initial subtasks for this issue type and then set subtask phase to Phase 1
- When subtask phase is set to phase 1 > move to In Progress
- When moved to In Progress, if subtask phase is set to phase 1, create more subtasks and then set subtask phase to phase 2
- When subtask phase is set to phase 2, if custom field is set to “Replace existing hardware,” create next set of subtasks related to that specific need
You can introduce branches in your rules so that if the subtasks generated at Phase 2, for example, vary based on the choice in another custom field, making sure each branch action sets to Phase 3 when it’s done (and have a branch catching “otherwise” to set to Phase 3 when some outliers won’t need phase 2 subtasks but will need to proceed to whatever phase 3 triggers).
Hope this small example helps. I also have a background automating project helping me with this specific project so that we have a form facing HR that is not accessible to anyone else and funnels requests to an IT space where other “tickets” are managed from a more general form available to everyone. Going this route with your most complex flows gives you more flexibility around the 50-rule limit.