Asana as a Two-Way Email Helpdesk With Make.com

English Forum Asana In Practice
1

We turned Asana into a true two-way helpdesk or ticket system. The workflow has been running for months now. For my team, it’s a game changer. We no longer switch between work management and our email suite (or CRM for that matter).

To this day auto-forwarding emails to Asana burns a paid seat for a bot that does only that. When the email finally becomes a task, you cannot reply directly to the requester. Worse: If they send a follow-up, the system creates duplicates.

As much as I love Asana, the email part breaks our flow.

For internal communication things got a lot better thanks to native Request Tracking through forms. You can reply from within Asana - but only if the form is restricted to your own domain. Which fails for external clients obviously. Even Asana’s own support team uses Zendesk for this AFAIK.

Asana’s integrations with GMail or Outlook require manual steps taken before an email becomes a task. Sluggish loading times kill productivity. They fail at scale. – So another showstopper for support management in many cases.

You could then turn to third-party extensions all of which require extra seats and fees. And honestly, so does the workaround I am proposing here. But no-code/low-code platforms help with a lot of other stuff, too. So maybe some of you already have a subscription with Make or N8N.

Or your favorite vibe coding assistant can help you clone the following ideas. Anyway, this is how we have solved it for us:

Part 1: Inbound Routing
Make monitors a support Gmail inbox. – We also run an external intake form with a mandatory email field, I’ll get back to that in a minute. – Filter incoming emails to drop auto-responders. Try to:support@yourdomain.com`` -(``from:support@yourdomain.com`` OR from:noreply OR subject:bounce) for starters and extend from there.

Anything new gets added to Asana and an automatic reply goes out including a unique identifier as a reference. Like a value from your favorite custom ID field. Or, why not, the actual task ID. Prefix the ID with a distinct text string not used in natural language (e.g., HLPDSKID).

  • If a new email already has it: add this email as a comment to the existing task.
  • If a new email does not have it: create a new task and send out the initial answer with the HLPDSKID.

Also list and download attachments from the email. Attach it to the task.
And inject the emails of requesters and CC’d recipients in respective fields, too.

That’s about it for the treatment of incoming mails. For requests from our intake form, just the requester’s email is enough to use the very same workflow structure: With our initial response comes the same HLPDSKID, and follow-ups get routed to the original ticket.

Part 2: Outbound Routing

  • The Proxy Project We maintain an empty Asana project named “Dispatch Emails”. Whether an agent drafts the reply for an external client or we write the draft up individually – there’s a dedicated Custom Field where the email text has to go. To send the message, a rule multi-homes the ticket into the Dispatch project.
  • The Webhook Filter The Make webhook for sending out emails watches only this dispatch project. We apply a strict filter: Action = added, Resource Type = task, Parent = project. The webhook triggers the workflow exactly once.
  • Global Threading We use Make’s “Reply to an email” module with the reply mode set to “specific recipients”. This gives us the Gmail threadId for correct threading while letting us control To and CC manually — which prevents the system from accidentally replying to itself instead of the customer. Subject lines and RFC headers (In-Reply-To, References) are handled automatically by Gmail.
  • CC Formatting Make outputs CC recipients as a raw data array. We skip complex iterators. We use a simple inline formula directly inside the Asana module to document CCs cleanly in the task comment: join(map(CC; "email"); ", ").

Part 3: Housekeeping

The workflow cleans up after itself to maintain focus. At the end of the Make scenario, the automation executes three steps:

  • Make logs the sent reply as a permanent comment in the task history.
  • It clears the text from the draft Custom Field.
  • An Asana rule removes the ticket from the project. The system resets instantly for the next interaction.

Bottom line
Yes, this took a couple of hours … testing more than setting up. Now it runs smoothly. And I am honestly glad I don’t have to consider a dedicated helpdesk tool anymore.

What do you think, can a bi-directional email flow be helpful to some of your Asana use cases, too? Glad to answer questions about details I have forgotten to include.

Cheers
Daniel

2 Likes
Asana project as Helpdesk/Support Ticket System?
2

Brilliant! I will go through this soon as I have been wanting to have this for years. I have been trialing some other software instead of Asana due to them not providing this which seems crazy.

I would also like to integrate a sort of AI based “Do any of these answer your question” kind of replies that link to a FAQ/Docs system to see if its answered before sending an email to us.

About this though “To this day auto-forwarding emails to Asana burns a paid seat for a bot that does only that.” - what do you mean by that? We forward emails to our Asana email to create new tasks and it does not use a seat or cost anything?

1 Like
3

Hi @Laurence_Cope!

It’s a great idea to have AI write up default answers from your FAQ docs. Those could become part of your initial auto-answer already. AI studio within Asana provides the easiest interface, of course, and the whole body of other support tickets right there can add more depth from actual related cases in the past. If such workflows eat up too many credits from your subscription you can always add an external loop through the AI API of your choice, too.

Reg. your question: I mean the very scenario from the Asana docs that I linked to. AFAIK You still need that extra seat for a forwarding account when there’s a shared email account like support@yourdomain.de that’s not connected to a personal user. You need it if that account is supposed to auto-forward external emails from users without an Asana account. Or have you figured out a native way to receive external mails in one place and them sent in to Asana automatically? Typically you get all kinds of rejection messages because the email headers won’t match what Asana’s security procoll expects.

Of course, I could forward stuff from my personal account. But I don’t want support tickets looped through me and much less assigned to me. I want them to go straight through from the support email inbox to the support inbox project.

With Make I can use different OAuth credentials for GMail and Asana and have the modules act as we please.

2 Likes
4

Hi Daniel,

This look pretty interesting solution. However, are you aware of Service desk for Asana ( Service Desk for Asana + Asana • Asana )? It is not a Zendesk style integration. We create our tickets in Asana as tasks and team communicate with requestor directly in Asana and more advanced functions are included. You can test and give us some feedback too.

Thanks!

5

Hello @Mustafa_Hipporello, thank you for pitching in. I’ll be glad to take a look and your service looks neat. But just to clarify: Here, I wanted to propose a workaround without seat-based extra fees by intention.

According to your pricing page the Asana Service Desk you offer falls in the category I mentioned: $10 / month / Asana project member. A support inbox project will mosten often be shared among say 10 people or more. So that makes it another $100+ / per month I’d need to carve out somewhere.

For comparison, the whole scenario setup in Make uses less than 10k credits for workflow actions in Make. Under heavy load. Which takes it to about $10 / month, too. But once, not per user. :slight_smile:

Cheers
Daniel

6

I see your point. It might be cheaper but when you check our solution, you will see the difference of a full asana native ticketing system. Let me know what you think once you tested.

9

Thanks for further info. I would not use any 3rd party AI if they charge for credits because I pay a lot for Claude already, so using others AI is either not necessary or just not willing to pay on more AIs when I already pay for one. Claude can integrate into Asana, so I use Claude for it all.

About the extra seat, maybe we mix up what forwarding means. I have an email address to create new tasks in my Asana. So I forward emails to that, then they get created. So I am not sure why I would use another paid seat to have some sort of email forwarding? I think what you mean is if I want someone not in Asana to email into it, so send an email to say support@mycompanydomain.com, then to have it created I need to associate that with a user seat somehow? At the moment it can only create tickets from approved email addresses. I dont know, but either way I would have Make.com or something else just create a ticket from emails received to that address, so no need for a user seat. I do not know yet how Asana would deal with the users email, I assume it needs a custom field to store it and to email to that address to send messages back. I have not gone through your steps yet I am a bit busy so it will be some time until I look at it.

If its too complicated I was looking at paying for helpdesk systems and use those for tasks instead of Asana.

MOST of our tasks come via email from non-Asana users, so Asana is just not cut out for that. I find that very strange as there is a huge market for a proper helpdesk system. All asana need to do is enable emailing in and out to non-Asana users, then they have a whole new market to target which can compete with Zendesk etc. But they dont so cant. I find it very weird to be honest. Like I said, I may leave Asana due to this issue. I think Asana target internal Asana users only for some reason. I think they want to sell Asana to our customers. My customers ask me what is Projects and Portfolio and other things which they do not need are for. Many of my customers are not technical, so I abandoned recommending they create Asana accounts.

10

Sure, Claude’s great to use in workflows. Exactly my point: Use what you have.

Yes, email addresses go to respective custom fields when emails arrive, and when we answer the outbox routing reads them from there and uses them to send the answer.

I understand how you feel about the limitations to working with external emails. We are a digital agency, and as much as we try and promote forms, most of our clients stick to sending in requests the old fashioned way.

We can now answer straight from Asana. And collect follow-up questions in the very same task, or “ticket” now if you will. What’s better: Our team can use the very task as their work package like all the others in our internal workflows. Because not every comment means an email. To send an answer, you push the button and trigger the rule.

It closes the loop: External Request becomes Work Item gets taken care of in Work Collaboration and leads to Client Communication when the request has been resolved. All straight from the same place.

1 Like
11

thanks I will definitely check it out when I have time because it sounds like you do exactly what I need for a ticket system.

I will be trying to use a form for the initial request from customers, to be sure we collect all the info we need, that’s OK, instead of emailing. And if I can triage that into a AI FAQ response first hat would help a lot. But some will still email into it. I would not want to use forms for the ongoing discussion as most of our customers will use email, but if they want to use Asana they can also. If I tell them its Asana now, they will still email as they will just forget about Asana, forget the login, whatever. We have seen all this and its a pain to manage. Email is here to stay in my opinion so needs to be integrated. For context, I run a web design and development agency so we have all sorts of customers. People who just dont need computers or IT much for their work, so they will stay away from Asana and stick to email.

12

My scenario exactly. Hence, two paths for the routing of our answers:

  1. One that’s for convos initiated by an external email (with a ThreadID given).
  2. A second one where we send an autoresponder as soon as a form request has been received (sending to the email value from the form entry, starting the email thread from our end with a fresh ThreadID) for follow ups.
  3. Both routes merge in the end and update the same fields and add a comment on the respective Asana tasks.

Have fun taking the idea for a spin. Let me know how it goes. Happy to help if you run into issues we may have had, too.

Cheers
Daniel