Global Rules would rule! Create a library for Rules

I find myself constantly recreating a certain set of Rules over and over. It’d be amazing if I could turn a Rule into a Template.

For example we create Feedback/ Results notifications connected to Slack for each person. We also have delivery reminders if they haven’t moved into the next stage in X amount of time.

1 Like

Hi @SamW !
It is possible to add rules to a project Template so that when you create a project from that template, all your rules will be ready to go… is that not feasible for your workflow?

1 Like

Hi Richard that’s a good idea, but unfortunately we have a few primary projects and that’s where all of the new rules need to be placed. We don’t make many new projects very often.

1 Like

Ah, I understand! Well let’s vote at the top of this thread that @Andrea_Mayer merged us into :wink:

(thanks Andrea!)

2 Likes

I’m experimenting with rules, and - although they are quite basic - they are great.

I’m really scared of putting rules in project templates for fear of one day wanting to add, change, or remove them.

This in my case might mean having to manually update hundreds of projects. This leads me to avoid rules whenever possible.

The tricky thing to implement this, is probably the fact that sections and customisation options can vary from project to project. Perhaps being able to link or lock them to the template might provide a solution.

As for practical solutions go, even a not so subtle “bulk replace rules” option would make a world of difference.

1 Like

Hi @Jan-Rienk_Hemminga !

The rules in Premium are fairly limited. Have you tried the custom rule builder in the Business Plan? If you are looking for more options, you can try out Flowsana, Make or Unito. And for some creative inspiration, check out The coolest Asana rules 😎

I understand how you feel, it can become overwhelming. But there is very elegant alternative: simply add just one rule to your templates: if task added > add task to a ‘master’ project.

To elaborate, if you are on the Business Plan, you could do the following, which I have setup for numerous clients and has proven very effective for scaling and managing hundreds of projects:

  1. So say you have one project per client (generated from a ‘Client’ project template)
  2. You also create a ‘master’ project called eg. ‘All clients tasks’ (which could even be private to just you)
  3. Since your ‘master’ project will collect all new tasks from all your client projects (via multi-homing), you can setup up all the rules in just the ‘master’ project which will apply these rules to all your client projects.
    So you can use this ‘master’ project for your rules library :wink:

You can repeat the above for other ‘sets’ of projects, like marketing/social media posts, sales etc, and have a ‘master’ project for each of these ‘sets’ of projects or departments with their own set of rules that will apply to all their projects!

:bulb: for best performance results, make sure to start all your rules in your ‘master’ project(s) with the trigger: ‘task added to this project’ followed by your trigger(s) → your action(s)

Hi @Richard_Sather ,

Thank you for your constructive reply.

We’re on the enterprise plan. I know there are other options. But I feel this should be a part of core Asana though. Like Trello has with Butler. Will take it into consideration though.

I did think of this workaround, but there are a couple of cases where this doesn’t work.

  • Having all tasks and rules multi-homed to one project is a potential compliance issue, since we have clients whose data (and employees working on those clients) we strictly separate since they have conflicting interests.
  • When wanting to sync sections for instance through custom fields you need these rules in all projects.

Hi @Jan-Rienk_Hemminga ,

Undestood, the rules I was implying to be used are usually generic such as if ‘Status’ custom field is changed to ‘Completed’ then automatically complete the task. Or if ‘Priority’ custom field is set to ‘Critical’ add the task to ‘Critical Issues’ project or add a comment @ team leader.
Such rules are easier to manage and scale later on by having them in one project rather than in numerous projects that need to be edited one-by-one if something changes later in the workflow/process. (eg the ‘@ team leader’ member changes and you need to edit their name again).

But referring to your cases where you feel this approach may not work, let me take you up on that challenge :wink:

As I mentioned, the master project can be private to you or a trusty Asana admin who will manage all the rules, so only this ‘rule admin’ would see all tasks - this person would also be the rule creator/owner. All rules will still run, even without all members or guests from other teams/projects needing to have access to them. Therefore these members would have to request a change to a rule from the ‘rule admin’ (this part may indeed not works for all cases) who would have a holistic view and understand the effect of any changes across all projects.

Whether you use collapsable sections, or custom fields for creating ‘sorted’ sections (by disabling the sort by section feature) you can create a single rule for each section to multi-home the task to the relevant section in the ‘master’ project. Then in the ‘master’ project you could create a set of rules that trigger only for tasks within that relevant section. Thus the actions would apply to the relevant section in all of your ‘client’ projects.

The above setup clearly requires conventions to be in place, meaning each member is ‘educated’ to use such a ‘client’ template-generated project consistently in the same manner. i.e. if someone wrongly renames a section to use if for something else instead, then the rules may result in unwanted actions. This is another benefit of using sorted sections based on a custom field’s options which produce ‘fixed’ section-titles (the custom field can be set to be editable only by the owner or admins) and thus provides overall consistency.

Yes, this is my setup. I even have a dedicated separate admin account for this purpose (mainly to prevent employee turnover to break stuff). Compliance requirements are quite strict though, so I will have to check if this will be sufficient. My point is that if it was just the rules being centrally maintained I wouldn’t even have to check because there is a clean break between content and automation.

Since there are no if statements in core Asana I don’t see how you could do with anything less than three rules per section in the “slave” projects:

  1. added_to_project AND in_specific_section) --> add_to_project(project_x, specific_section) // to catch newly added tasks
  2. section_changed_to_x --> change_field_value_to_x // for when section changes
  3. field_value_changed_to_x --> move_to_section_x // for when field value changes

Even if they could be handled with IF statements, changing the workflow/sections in any meaningful way would result in having to update every project or accept a mismatch. Or am I missing something?

Also, there is the related issue that upon creation first the tasks get populated, then the rules. So there is always a manual action required for multi homing after setting up a project through a template.

You are right, it is not very Poka Yoke, so I feel this should be avoided whenever possible.

1 Like

Reiterating how useful this would be when managing multiple different projects. Is this on the roadmap?