Bring back the previous approval subtask behavior in rules

[Thaïssa_iDO]

Hi,

I’d like to share feedback on a recent change regarding approval subtasks created via rules.

Previously, it was possible to create approval subtasks using the “Create subtask” action, which allowed them to:

• Exist at the same level as regular subtasks

• Participate in the same dependency chain

• Be used as blocking or blocked steps in linear workflows

This made it possible to build clear, dependency-driven processes where approvals were fully integrated.

Now, approval subtasks can only be created using the “Create approval” action. As a result:

• Approval subtasks cannot be mixed with regular subtasks in the same action

• Dependencies cannot be created at the same level

• Maintaining dependencies requires creating additional subtask levels, which breaks many existing workflows

As confirmed by support, we can’t create dependencies between approval subtasks and default subtasks at the same level anymore.

This is a significant limitation for teams relying on dependencies to model approval-based processes.

Would it be possible to restore the previous behavior, or allow approval subtasks created via rules to fully support dependencies at the same level?

Thanks for considering this feedback.

Best,
Thaïssa

[lpb]

Thanks, @Thaïssa_iDO, for adding this.

@Forum-team, This is an unexpected, troublesome loss. Might the functionality be restored soon? Any chance for escalation?

Thanks,

Larry

[Joanna_Colgan]

Hi @Thaïssa_iDO
Thank you for flagging the problem and documenting it so clearly. I have flagged this with our product team! I will be in touch when any updates are available.
Thank you @lpb for your help!

[Garrett_Knoll]

I had also already been on this having been worried one of my teams caused it (they weren’t - not that that matters!), but we’re working on diagnosing and @lpb I’m on it

[lpb]

You’ve got our backs, @Garrett_Knoll–thank you!

[Katie_Melby]

THANK YOU FOR BRINGING THIS UP! I submitted an issue ticket (case 08763376) because this also impacts ability to set the subtasks as milestones and custom tasks. I deleted a rule from a project that included subtasks that were custom and milestones and when I went to add it to another project it was no longer there. I was told:

“I’ve received an update from our dedicated team confirming that this behaviour was adjusted because we focused on task types other than milestones. As a result, this functionality has been bundled into another rule action. Unfortunately, users will only be able to create tasks using the action shown in the screenshot.

That said, if you need some subtasks to be converted to other task types, you can use an alternative rule to achieve this. For example, you can set a specific custom field on the subtask and then configure a rule similar to the one shown below.”

I responded and asked them to reconsider their decision because I was already in the process of deleting workaround rules that required adding subtasks to sections/projects and/or removing extraneous fields to convert them.

[Thaïssa_iDO]

It seems the old approval substask behavior is back

Thanks @Joanna_Colgan , @Garrett_Knoll !

[Nadeen_Saleh]

Hey everyone - one of Asana’s Rules PMs here! I wanted to follow up and thank you all for flagging the gap this change caused. The change was actually a side effect of a separate bug fix, and your screenshots made it clear we’d created a new friction point. The team has restored the previous experience.