I have a feature request for the Messenger Framework



I mean notifications prior to the user interacting with the app. I think once the user has interacted with the app, we could launch the custom iframe to allow for two way interaction (forget what it’s called).


Is Multi-Line text input implemented? If it is, I can’t find it in the documentation.


@volkan There’s no multi-line input field just yet, although there’s no character limit as far as I’m aware on the text input component - any use case you can provide for this feature request?


I’ve seen it in Ask Nicely app screen shots and I want to use it like that too, how did they do then?

It’s about styling not functioning. It would be nice to give multi line text to the user so they can see what they wrote.


Hey @volkan , Ask Nicely (and several others) are using a sheet with a custom form in the iframe of the sheet to get that multi-line text box. That’s how we’re currently recommending all developers implement text boxes.


I see, we use standard form. Will Mutli-Line text be added to standard form in the future?


We’re not sure right now. It certainly won’t be added in the next quarter at the very least. We’ve had quite a few requests but there are some technical/design challenges there that make it non-trivial. I’ll definitely keep the community up to date on it though as we prioritize changes in the future.


It would be useful if the user or lead id is also included in the context. Now I have to get the conversation first from the API and then the user/lead.

edit: I see the /submit endpoint already adds the user object, this is exactly what I need in the /configure endpoint as well to add actions based on if the user has en email address or not.


Hey @Sijmen :wave:

Glad you found it for the submit request - the difference with configure and initialize here is that while they may be associated with a conversation/message, they are not associated with a user/lead yet (ie. the app is being customized and created, not sent to, nor interacted with by a user/lead).

Therefore, your workaround using the API is best for now - cheers for the feature request though!


@Sijmen - To expand on what @zach mentioned, the /configure flow can be used when setting up an app in the Messenger homescreen, in Operator or in an auto-message. In all these cases the app won’t know yet who will be the user or lead viewing it :smiley:


What about checkboxes? Is this something you’re considering to implement soon? :slight_smile:


Good question! @hellojeanpierre?


@daniel would you be looking for multi-select in an array of options (like an improvement to the single-select) or explicitly checkboxes pattern?


We’d definitely appreciate multi-select in an array of options ( with no reload effect, when checking another option ). Checkboxes aren’t a necessity for us.


So, is this something you plan to implement anytime soon :slight_smile: ? @hellojeanpierre


What does soon mean? :smiley:Adding multi-select makes sense at first glance, but I have no concrete timelines yet. Have you considered some alternative way? like using a list and every time you select something it adds to “selected” list (or remove the item).


@hellojeanpierre Sorry to be replying so long after the fact to your answer about user agent information! We’re adding a bunch of new functionality to our Messenger app, and I just saw your answer, here.

You’re right, of course. We can look up the user_agent_data using the REST APIs. But it takes two API calls (a /conversation call and then a /users call).

If it were easy on on your end to put the user agent string into the initial configure context, that would speed up and simplify our code.


That makes sense, thanks for clarifying @kwindla.

In the configure flow, the user object might not always be available. For example, if someone inserts an app in an outbound message sent to an audience or inserts the app in the homescreen of a messenger you wouldn’t know who is the user.

However it makes sense that in configure flows in conversations that we pass the list of participants in that particular conversation. I’ve added this in our backlog but we won’t have capacity any time soon to take it. I’d suggest at the moment fallback to a API call .