Applying a Tag that triggers a Rule

Hey there, just upgraded and loving the Rules feature.
Now, I’m very surprised not to see Tag as a trigger for those. As soon as you enter a subtask, you can’t use any of the rules… very disappointing.
Thoughts?

7 Likes

Hi,

You shared two different feedbacks right?

  • having tags work as trigger
  • having rules work for sub tasks

The first one is a good idea, even though the tag feature has been « ignored » for a long time and did not evolve at all, so not sure it will be worked on.

The second one actually make sense and is by design: subtasks are not part of the project so rules don’t apply to them :man_shrugging::sweat_smile:

3 Likes

Hi @Laurie2,

FYI while Asana’s rule triggers do not support tags, Flowsana’s Rules do include triggers for “Tag [tag name] added” and “Tag [tag name] removed”, so you can invoke a Flowsana rule when a particular tag is added or removed from a task.

2 Likes

Hi Bastien,

Thanks for letting me know that the Tag featured has been ignored for a while…
I’m attaching below how my team uses Asana for client work. We’ve dozens of clients, so we treat each one as “a static task” under the overall “client project”, and have all the tasks related to a client as “subtasks” inside it. Those are the ones weI’d like to be able to assign Custom fields to, and rules…


Thanks!

1 Like

Great thank you. I’ll look into it!

Hello @Bastien_Siebman the subtasks certainly, by default they are not part of the projects, but by displaying the properties panel of the subtask or subtasks, these can be added to the main project panel to which they belong, and can coexist outside like any other task In fact, I have Subtasks within an objective task that lives in a “Goals” project and the subtasks of this “objective” task live in a project called Q1 2020, so the rules should apply as with any other task.

“I have Subtasks within an objective task that lives in a “Goals” project and the subtasks of this “objective” task live in a project called Q1 2020, so the rules should apply as with any other task.” < any chance you can share a screenshot for this? definitely interested!! thanks!

1 Like

Hello @Laurie2, even better, i record a screencast for you :wink:
Here you have the link to review it: Loom | Free Screen & Video Recording Software | Loom

please let me know about any questions

3 Likes

Love it! and what perfect timing than Jan 1 to implement this! thanks so much @JMartinez!!

2 Likes

Delighted to have been helpful @Laurie2 and specially on a date as marked as the beginning of the year to help you and your team improve your effectiveness with Asana.

2 Likes

I usually advise to have one dedicated project per client, and inside the client task you @-mention the client project. Having dozens of projects is really not an issue, especially if you have a “Table of Content” of some sort, serving as an entry point. But we are derailing the initial subject of the thread!

I always advise against this. This is very advanced Asana stuff, and you need to have your mind very clear about what you do. However, having the subtasks live in another project is kinda fine.

1 Like

@Laurie2, I read one post about moving your clients up one level into the project. I would second that, but go even further. Each client should be its/his/her own team. With this, you can set up templates for projects with each service that you provide (annual review, site design, etc.) You can create your standard 5-10 templates that include the scheduled tasks that each service gets, set up the timeline, and then modify to your likings. The best part, you can then use multiple portfolios to track progress at the project level and use the Rules. My rule of thumb: Never use sub-tasks as a regular routine. They should only be used when a specific situation calls for more specificity. The reporting, parent/child, and overall organization is not built for how you are tyring to use them. You’ll only get frustrated and export to csv for management. Spoiler alert, you wont like how that looks either.

2 Likes

Very good points @Heath_Jackson!

1 Like

Thanks for explaining the logic behind it! Appreciated

1 Like

We just underwent an entire “level up” where we switched from managing 20+ clients as Projects to managing clients as Teams. We wanted all of the benefits that @Heath_Jackson described above. We’ve had to change a bit of our nomenclature for project names, but the efficiency and tools gained have been worth the little bit of disruption.

1 Like

That’s fantastic, @Becky_Martin1! Here are some tips that I use. Maybe you can make use of them, too.

  1. Use the “Convert to Template” functionality on projects that will be used over and over. Don’t duplicate, but create new project from template. This will allow you to choose the start or end date with an auto balancing of the task and milestone dates to coordinate.
  2. Create multiple portfolios to help those that manage clients. Add all of the Projects (client services) that are applicable and use that as your status update, workload capacity planning, and high level timeline. When your team updates the boss, use each of your portfolios to have the conversation.
  3. Use advanced search to create additional ways of tracking. Save them and share them with others. (Example: Contains the words - Annual Review (making this up of course); In Teams - X,X,X; Assigned to - X; Completion - Incomplete; Completion date - within 30 days.)
  4. Create a company-wide procedure for using the Team Conversation instead of email for client work.
  5. Create a Team that is public to everyone for storing Template Projects. Just ensure that your colleagues place them in the correct team when creating.

All great tips.

1 & 4. In use, and so valuable.
2. We’re still figuring out how to best use Portfolios (it’s not done what we hoped), so this is helpful. I need to block off some time and really dig into this and Workflow.
3. I had never thought this!
5. Great for when we start scaling beyond the 3 of us.

Mostly curious - why do you ‘always advise against’ adding a subtask to its own project? Is it just a matter of it adding noise to the project view?

The way I’ve been thinking of Tasks/Subtasks is like mini-projects within projects - I don’t necessarily need a full Project, but I want the parent/child relationship, and want the same control/visibility for both Tasks and subtasks. There’s some functionality that you don’t get unless you add the subtask to a project (significantly, being able to view them and manage the schedule/dependences for each in the timeline/calendar). So I’m curious if there’s a crisp/documented POV on the function and use of subtasks. Appreciate any insight you can share

I’m not sure how crisp it is (!) but here’s my take, for what it’s worth, and others’ are present in that thread too:

Larry

1 Like

Because that is very hard to understand unless you are an Asana power user + you can be sure you’ll forget to multi-home some of them and will end up with a partial view. And now the subtasks are displayed inside the main view, you have less and less reason to do such a complicated thing.

1 Like