Questions around `AttachedResource` responses to `On submit callback` for modal form app components

[Layfando]

Hi all ,

We’re in the process of developing a custom app and we’re wondering if our intended app flow is possible within the constraints of Asana’s app components.

---

App Flow:

• The entry point is a button that brings up a modal form.
• In the form, the user makes a selection that brings up an updated dynamic form. We have several branching paths with different forms here, all resulting in the user eventually submitting their chosen form.
• At this point, our app server takes over and affects changes in Asana (and across a bunch of other systems) via API. No further interaction with or modification of app components is desired.
• Users should be able to initiate the app flow again, starting by interacting with the aforementioned entry point.

---

And here’s where our concerns come in, as it seems that the last two bullet points might not be possible as envisioned.

In the documentation for app components, it says:

Once a form is submitted, the information is sent to the app server and Asana will perform different functions depending on what the server responded with.

And in the documentation for handling the On submit callback for modal forms, the schema shows that Asana expects the app server to return an AttachedResource response which it will then attach to the task on which the app flow was run.

I haven’t been able to find a definition or schema for the AttachedResource object, but looking through the example apps, it seems that it’s possible to return a minimal response consisting of just two fields (resource_name and resource_url), as shown here.

This brings me to a couple of questions that I would love to get your insight on:

• Is it possible to end the app flow after form submission and have Asana not perform any follow-on actions? Most apps tend to display a widget with information from third-party sources. Is it possible to avoid this?
  • For example, can we respond to the On submit callback without returning an AttachedResource response or by returning an empty response that will not result in the creation of an attachment to the task where the app flow was run?
  • Alternatively, what would if we don’t return a reponse to the On submit callback at all? What happens when the 10-second timeout is reached?
• Are there any examples / definitions for what AttachedResource objects can look like?
• Is the idea that the entry point app component must always be replaced by the AttachedResource being returned? As mentioned above, we’d like for the entry point to return to its normal ready state after form submission.

---

Thanks so much for your help!

[Phil_Seeman]

Hi @Layfando,

The answer is, yes, you can accomplish what you want - but it will require using a somewhat kludgy (IMO) approach. I’ll explain, and you’ll have to decide if you want to do it or not.

@Layfando

the user makes a selection that brings up an updated dynamic form. We have several branching paths with different forms here,

This part is definitely possible using the on_change_callback endpoint; changing the contents of a modal form based on user input on that form is exactly what that endpoint is for, and it works great.

@Layfando

and Asana will perform different functions depending on what the server responded with.

Don’t worry about this part; it just means Asana will display a widget or not - it doesn’t take any other actions that would mess you up.

@Layfando

Most apps tend to display a widget with information from third-party sources. Is it possible to avoid this?

Here’s where you run into trouble. The short answer is, no, it’s not possible to avoid it - an App Component on a task is designed exclusively to show a widget; that’s essentially its whole point.

More specifically, when the user submits the modal form and Asana calls your on_submit_callback endpoint, you have two choices: one is to send back a 200 status code (i.e. “everything is good”), at which point Asana will display a widget; or you send back a status code other than a 200, like a 400 or 500, at which point Asana displays “Something went wrong” in red in the bottom left corner of your modal form.

You definitely don’t want the “Something went wrong” as the experience for your users, so you’re left with sending a 200 and getting a widget.

Now we get to the fun part. How does Asana know that an App Component has been submitted on a task and a widget should be displayed on it? The answer is, it creates a special type of attachment on the task. If your app server were to go and delete that attachment as soon as it gets created, then voila, the widget disappears and you’re back to the entry-point state you desire.

To do this, in your on submit callback endpoint, after you return the 200 and the AttachedResource (more on that below), you’d call the Get attachments from an object endpoint to get a list of the attachments on the task because you’ll need the attachment’s gid in order to delete it. I suspect you’ll have to do that in a loop that keeps checking the task’s attachments, because when you immediately send back the response, it’ll take some time (though probably just a second or two? I didn’t time it) for Asana to add that attachment.

Doing this loop and deleting the attachment after the widget displays briefly is the part that’s a bit kludgy IMO, but you can do it if you want!

If there are multiple attachments on the task, how do you know which one is the special one that you need to delete? The answer gets to your question about the AttachedResource object. It’s exactly as you say: it’s just a JSON string consisting of a resource_name and resource_url. Guess what? The string value you pass as the resource_name will be the name of that special attachment! So just use a unique name value that you’re sure no one would use as the name of a regular attachment, then look for that name when you get your list of attachments on the task, grab its gid, and that’s the attachment to delete.

BTW in your case, you won’t really care what the value is of the attachment_url that you pass back, but the URL does need to have a root matching the domain of your App Component server. What comes after that root in the url you send doesn’t matter, because that URL is what Asana calls when a user clicks on a widget, and you won’t have any widgets for users to click.

Let me know if you have any questions about any of the above!

[Bastien_Siebman]

@Phil_Seeman I am a bit surprised. I create an app that allows our user to send emails.

here’s the button

here’s the modal displayed

Once submitted, it never creates a widget. It just sends the email. I didn’t have to write any code to delete an attachment… Am I doing what @Layfando wants to do?

[Phil_Seeman]

@Bastien_Siebman What are you sending back to Asana in your on_submit_callback reponse? In my testing I wasn’t able to get any result other than a widget or a “something went wrong” message. Maybe I’m missing something - entirely possible!

[Bastien_Siebman]

I am sending back this { action_result: 'ok' }

[Layfando]

Hi @Phil_Seeman

Thank you so much for the thorough explanation. I unfortunately stumbled a bit too late over this post … reading that first could’ve spared the both of us some time

It’s been very helpful to have you walk through the process, and I suppose we’ll land on the approach where we just delete any attachments that the On submit callback produces.

Of course, we’ll try @Bastien_Siebman’s approach as well – if that works, that’s definitely preferable and indeed what we wanted to achieve in the first place.

Thank you both!

[Phil_Seeman]

@Bastien_Siebman

I am sending back this { action_result: 'ok' }

Well that’s definitely undocumented and unexpected - action_result is only supposed to be for App Component rule actions, not for App Components on tasks!

[Bastien_Siebman]

I found a workaround by mistake then!