Welcome, @anon49335325,
Don’t forget to vote for your request!
Until/if Asana makes such a change, consider using this approach in the meantime (if you haven’t already):
Larry
1 Like
Tasks that requires approval when marked as ‘changes needed’ or ‘ready for rewiew’ should not be considered a ‘completed task’, since it is not!
2 Likes
Hi @Marina_Rebelo welcome to the forum! There is much debate around this. Technically if the task is an approval task one it has been approved, changes requested or denied then the approval is considered complete.
Best practise is by adding an approval sub task to the main task itself so the approval is completed and not the task requiring approval
Or alternatively you could use a single select custom field instead with the options Approved, Changes requested etc that whomever is approving changes and then adds comments to the main task
Well, this is no solution, adding a task for approval is retroactive in process organization. From what I have seen, this is an old request, almost 4 years, and still remains the same.
1 Like
Technically if the task is an approval task [one] it has been approved, changes requested or denied then the approval is considered complete.
So what is the official recommendation when changes are requested? Duplicate the task and pick up the conversation there?
e.g. “Task 1: Design payment form” > Marked for Approval (by designer) > Marked as “Changes Requested” with comments > task disappears from “Incomplete Lists” > Duplicate Task with updated title “Task 1 Round 2: Design payment form” > repeat.
1 Like
A couple options are either 1) When using approval-type tasks, specify them as subtasks of the task to which they apply (see my earlier post above), or 2) don’t use approval-type tasks (see @Danielle-GenD’s post above).
Thanks,
Larry
1 Like
seeing that this has been common topic since 2020 is honestly disappointing! we should not have to add another subtask, another custom field. too many tasks and fields is just overstimulating, messy, and hard to keep track of.
I have two different rules set up:
-
Approval status set to “Approved” – task marked as “Complete” + moved to “Complete” – Asana Bot comment " @(collaborators) Content for (posting date) has been Completed! Download the files attached."
-
Approval status set to “Changes Requested” or “Rejected” – task marked as “Incomplete” + moved to “In Progress” – Asana Bot comment " @(Assignee) Changes requested on content for (posting date). Please update with team feedback notes by (due date)."
when a task is set to “Changes Requested” BOTH rules run – even though they are specified by different approval statuses?? even if i unmark “this rule can be triggered by other rules”.
the current way of approvals is not ideal for a successful workflow. we pay for Asana for ease – to cut down on things that take up our time. I am in Los Angeles CA and my teammate is in London UK, other coworkers in the East Coast. Asana is meant to help our content feedback and work process, and it seems this is something many people have an issue with for the last four years. also it literallydoes not make sense. if you ask for something to be changed, it is not finished.
2 Likes
I tried implementing Approval Tasks into our workflow - but have found them to be a useless feature.
They do not serve any purpose other than a visual indication and they come with a major caveat:
- Tasks with the stage “changes requested” or “rejected” are considered ‘complete’ hence do not appear in the assignees “My tasks” or cannot be easily filtered by in a project
We are trying to use approvals as part of a standard agile approval process, at the end of a sprint:
- Turning the Sprint tasks into an approval tasks
- marking the task as “changes needed” with Feedback in the comments if not approved
I do not see the benefit or difference, over simply using a custom field for the Review stage - as this custom field is needed anyway if we want to filter by the tasks in a project, or have them appear under “my tasks”.
Tasks which were not approved should hence, not be considered complete - as there still is an active to do.
1 Like
Additionally because not approved tasks are considered complete - dependencies will not work with them
yeah if changes are needed/requested the task is still in progress and not fully completed successfully.
It seems useless that the “Approval” feature indicators all mark the task complete - even if there are changes needed. That doesnt make sense to me. Can their be other options instead of just completing the task immediately?
1 Like
Welcome, @Kathryn_Wirtz,
I’ve merged your post into an existing thread where you can click the title to scroll to the top and vote by clicking the purple Vote button.
There are workarounds in the thread, but briefly, a best practice is to make Approvals subtasks of the work they apply to. Consider the approval a very narrowly-scoped action; the act of designating that approval choice completes the action. I think that’s the intent of the design of the feature.
Thanks,
Larry
2 Likes
+1, My team uses automation on our milestones in projects that close milestones when all the dependencies are completed. having to manually go back and undo items because a rejection falsely completed a milestone is tedious.
Currently doing the “workflow specialist certificate” and there is a rule that shows up as an example in the course where an approver choosing “request changes” would break the workflow.
The workflow in the course includes the two rules at the top of the following image:
(reference: “lesson: workflow specialist certificate > build:optimize your workflow > topic 12 of 13”)
If the reviewer chooses the option “request changes” then the automation to complete the main task will trigger because the marking “request changes” counts as changing the task completion status to complete on the back end. This would result in moving the ticket to the complete section, even though there are still changes that need to happen.
I ran into a similar issue when creating workflows for my team and our solution was to avoid ever choosing the options “request changes” or “rejected” but then there was no point in using an approval subtask rather than a regular subtask.
When experimenting with rules I did find a potential solution (the rule at the bottom of the image above) but this solution will likely only work for workflows that reassign the main task rather than assigning [multiple] approval subtask[s].
The designer could then trigger the approval rule (not shown here) again to reassign to the approver.
Sorry for the weird formatting. I was only allowed one embed since I’m a new user.
Bare minimum, a binary for triple option tasks seems counter intuitive, it almost begs for a third status of “in progress.”
I came here cause I’m looking for a way to search for “Request Changes” approval tasks in advanced search. You can select task type as approval but then the status options are not approval tasks based but general task based. So agree with everyone but also just want advanced search for this to make my life managing the selection of images and approval of copy across over a hundred events (while doing my other jobs lol)
1 Like
Can we get an update from Asana team on this item? @Marie @Emily_Roman
Asana doesn’t comment on unannounced features so we won’t hear any updates unless/until they implement this change.
FYI we just added support for specific Approval statuses in our Flowsana rules, so you can now “fix” this behavior with a Flowsana rule:
2 Likes
Recently realized that though you can establish a dependency between approvals, the “blocking” function doesn’t work. There appears to be a dependency, but approver can approve regardless of that dependency. Shouldn’t approvals have the same blocking functionality available that tasks/subtasks do?
1 Like