My team wanted to add subtasks to a form submission based on the data that was submitted. We have three questions asking if you need help with marketing, a speaker, and swag. For each of those three options, we have a series of subtasks we want to add to the parent task. Trying to do this using a few simple rules lead to all of the rules triggering simultaneously and the subtasks being mixed together, see Rules triggering and running simultaneously where I tried to explain my issue.
I explain the problem and demo my solution on YouTube https://youtu.be/Xn6ek1zpvOI
I recently came up with a solution to this problem which was easy to implement using the new Workflow tab. This solution can be expanded to a lot of different use cases to customize how a form submission is processed. I’ll do my best to explain what I built below, but it may be easier to watch this video demonstrating the problem and the solution linked above, including a full walk through of how to build it. There are chapters in the video to make it easier to jump around.
Basically, instead of having three simple rules based on three yes/no questions, you create a section in your project for each question. You then use a rule to move new tasks (form submissions) into one of those new sections. Within a section there are rules to add subtasks based on the answer to that section’s question. At the end of each rule, the task is moved to the next section. This way the rules are processed sequentially, and don’t run simultaneously. Using sections like this also makes it easy to visualize how a submission will be processed and what logic will trigger.
As I show in the video, you could also use this architecture to assign these subtasks to different people or assign different relative due dates based on the form data. Additionally you could multi-home the task based on the form data, or really trigger any of the possible rules. For subtasks, it is critical that you take the extra step to add automation sections to your project, otherwise the subtasks will be all mixed together. Using these sections and the workflow builder makes it easier, I think, to see how form data impacts the automation.
Since recording the video, I have changed the names of my automation sections to “[Automation] Marketing”, “[Automation] Speaker”, and “[Automation] Swag” to help differentiate them from other sections in the project which people are intended to interact with. Maybe the robot emoji would be good here instead.
I’ll also note, it’s critical that questions in the form map to either single-select or multi-select custom fields in your project, so that rules can trigger off of the values, AND these questions must be required in your form. If the custom field had no value, my automation would get stuck in the section corresponding to that field, but by requiring the question to be answered, you know it will have a value. Then it’s just a matter of accounting for each possible value with a rule in that section. Asana also recently increased the number of rules allowed per project, which helps make this approach even more feasible and expandable to more complex forms.
Thanks for checking this out. The video does a better job demonstrating my solution, and I’d appreciate if you check it. I’m curious to hear community feedback on this approach to using Workflows and how you might use or improve this process!
thanks a lot !