Hey @antoine s​, there's currently no way to programatically show a specific conversation in the Messenger. Would you mind telling me a bit more about your use case here, please?

Hi @eric f11​ sure I can explain an instance of our cases: in our workflow between employees and users, we sometimes trigger conversations to request information from the user. This requested information, since it is part of the workflow, has to be traceable in our application (for our employees and users to be able to check the status of this conversation, add something to this particular topic, redirect the user to this exchange for accountability purposes... all these controlled with a necessarily simple JS event). Therefore, we store the conversation IDs, so we have the history. And here we are : how to inject these IDs into the Messenger to pop a particular conversation back up, so that our employees and users can easily access said history.

How do you currently store the information requested for the user, @antoine s​? Is it only visible within the conversation itself, or do you track this as user attributes?

@eric f11​ sorry I wasn't clear: we don't store directly the information that is yielded by the human exchange (be it the request or its answer), instead we simply store the conversation ID. This way we can either retrieve the conversation through the HTTP API or create the URL to the conversation in the Inbox.

The missing bit being the ability to show the conversation in the Messenger, so that our users and employees could easily (i.e. from clickable items in our app) be reminded of - and continue discussing about - a particular topic.

Got it. Can you tell me a bit more about what kind of information you store here? It strikes me that the solution here may be to pass this information as either user or conversation attributes.

Hey @eric f11 I'm not sure what you mean by the kind of information we store: "we" store a reference to "your" conversation object, and that's all: the human exchange is specific, case-by-case and can only be handled by humans.

Let me sum it up, from the example I took originally, to avoid the XY problem:

• we are trying to achieve a task for our customer, and we miss some information
• we trigger a sub-task that the customer can see in our UI, with a text asking for this information
• internally, this trigger will create a conversation with said text
  • message type is email: we need the customer to receive an email notification, which is not the case when we trigger an in-app conversation
• if the customer reaches their mailbox, they can answer, no issue here
• otherwise, if the customer reaches our application, they see the sub-task (point 2 above)
• now, this sub-task would have a clickable link/action to allow the customer to answer from there
  • and here we have the issue: how to pop the Messenger with the right conversation pre-loaded
• last but not least, accountability: later in the future, the customer should be able to find again this conversation easily from the history of their tasks
  • same solution is applicable

So, we could indeed provide a reference to the task in the conversation object as a custom attribute. We're doing the linking the other way around: the task holds a reference to the conversation, works the same in the end. However, the customer still can't see (and write a message into) a task-related conversation, directly from the task in our UI (hence using the integrated Messenger).

Hope this helps, and thank you for your time!

My apologies, I misunderstood that there was specific information asked in each conversation that could be stored as attributes. Right now, I don't have a workaround available for you to call a specific, unique conversation, but I'm happy to share this feature request for you via our @Product Wishlist​ group.