FAQs: Web messaging

The session persistence method set on your Messenger Configuration determines the behavior that occurs when your customer navigates across subdomains of your website and the same Messenger deployment is present.

Expand all

Genesys Messenger runs in its own iframe and uses the Web Storage API to store internal vendor-specific identifiers in the browser’s localStorage, using Genesys Cloud as the origin for storage. Because of this, Messenger is not affected by browser deprecations of third-party cookies.

Messenger supports preview of file types only when it is supported by the browser. Each browser has its own set of file types that it can support rendering, so it can vary based on the browser and OS combination.

For example, .mp4 is a standard file type that is supported in all browsers whereas .mov is only supported in Safari and Firefox browsers in iOS. So Messenger uses a browser API to detect if it can support rendering and show preview. If not, it falls back to the download option where the user has to download the file and open in their native app to view. For information about file types preview, see Supported content profiles.

To migrate from co-browse for web chat to co-browse for web messaging, ensure that:

• Configure Messenger with co-browse for web messaging is enabled
• Your agents have the permission Conversation > Cobrowse > Add

When your customers use Messenger to initiate web messaging interactions, agents can propose a co-browse session directly within the conversation.

To migrate from the legacy co-browse for voice to the new co-browse for voice via Messenger, you must consider the timing of when to make the switch as the two versions of co-browse are not cross-compatible. As soon as your agents are assigned Conversation > CobrowseVoice > Add, the generated co-browse Meeting IDs will only work for the Messenger-based version. At the time you wish to switch from legacy to new co-browse, ensure that:

• Your agents have the new permission Conversation > CobrowseVoice > Add.
• Your website provides a way for customers to enter Meeting IDs for the Messenger-based co-browse, not the legacy co-browse deployment. Meeting IDs generated while using Conversation > CobrowseVoice > Add will not be recognized by the legacy co-browse deployment.

Cross sub-domain browsing can be achieved via your session persistence method, assuming both pages contain your Messenger Deployment. Cross domain scenarios are not included and are currently unsupported by Messenger.

Yes, co-browse relies on the Messenger snippet to continue the session when you navigate across pages.

When you enable Humanize your Conversation for your Messenger configuration, Messenger displays a participant name and avatar next to each message that you send.

Any message that an automated reply or bot flow sends on behalf of your brand appears with the bot name and bot avatar that you specified in your Messenger configuration. If you do not define a bot name, no bot name appears. If you do not define a custom bot avatar, Messenger uses the default bot avatar.

When an agent sends a message, Messenger displays the name and avatar as follows:

• If the agent has an alias and image defined, these are used. For more information, see Add an agent alias and image.
• If the agent has an alias defined but does not have an image defined, a generated avatar with their first initial is displayed.
• If the agent does not have an alias or image defined, the agent fallback avatar is used. 
• If the agent does not have an alias defined, no name is displayed.

No, the messaging threading timeline does not affect Web Messaging Guest session duration. Threading timeline is limited to the internal conversation model. If threading timeline is set to zero, then the internal conversation is ended when the agent disconnects. If the end-user sends a new message over the same Guest session that will generate a brand new conversation ID, which in turn would trigger new flow execution and new transcript for Agent, while the end-user’s experience is not affected. End-user can continue the existing conversation, as long as the Guest session has not expired. For more information, see Messaging threadline timeline. 

Currently, this session duration is not configurable, and is hardcoded at 72 hours. 

After 72 hours of message inactivity, the Guest session expires, and client cannot obtain a valid JWT to access messages via History API. On the client side, however, there is no command or event that can trigger this. Once Guest session expires, the native Messenger generates new a Guest Token, which is used to start a new session.