I am trying to launch a new Web messaging deployment, and i have a few issues i cannot resolve by looking through documentation.
I have changed my Threading timeline a few times. if i update that timer, does it automatically become active with the deployment already launched? are there any steps to get it to recognize that timer has been changed?
I currently have the threading timeline set to 10 minutes (assuming there isnt anything i need to do for it to use an updated time) and when the customer comes back to initiate a new message within that 10 minutes, they see the conversation history, with the start new button at the bottom. as soon as they hit the start new button, the history disappears for the customer and the agent never sees any history.
Thank you @Angelo_Cicchitto, i had seen that FAQ. i guess i'm not clear. if we aren't doing authenticated web messaging is all interactions considered 'guest'? and therefore not beholden to the threading timeline?
I thought i was going to be able to run the API call /api/v2/analytics/conversations/{conversationId}/details on the website to clear customer cookies to see if conversationEnd was present. i thought conversationEnd only happened when the threading timeline expired. however, i'm finding conversationEnd appears as soon as the agent wraps up the interaction. so not a valid way to see if the threading timeline has expired. is there any other way that we can see if the threading timeline is still active in order to make sure the customer experience follows our threading timeline as guests?
I figured out the 'start new' button i referenced in my original question was caused by using "Display conversation status and disconnect session" in my configuration. that was preventing the history from being retained for the agent and customer. so i have resolved that.
Another question i had in relation to the FAQ link you sent is what is the 'internal conversation model' that is referenced in the answer? does that mean Authenticated web messaging?
Also, are changes to the threading timeline reflected immediately in the deployment? does anything need to be done if that threading timeline is changed once the deployment snippet has been pushed to a website.
I know this is a lot, and I appreciate your (and anyone's) help/insights
With Unauthenticated deployments, the customer's side will always show ALL of the conversation history regardless of the threading timeline as long as cookies/cache are not cleared?
Because of #1, the pre registration form MUST be in a bot because it does not require the customer to refill the form out on website because the messenger popup window is always available to restart a conversation as long as cookies/cache haven't been cleared
There is no way to tell if a conversation is still within the threading timeline when a new conversation is started?
If the threading timeline is changed, is it effective immediately on the deployment? No additional steps need to be taken?
I tried to open a ticket with support and they said these types of questions are more appropriate for the Dev Forum.
We refer to the customer-side as the "Guest Session" and that always holds the most recent messages over the past 15 days. We are soon releasing a new feature that allows End-Users (or JS on the page) to "clear" the current conversation, this might be interesting for you: Genesys Cloud Ideas Portal
With messaging we would recommend to use Bots for visitor qualification
Within your Architect Flow, you can use pre-built variableMessage.IsNewConversation to determine if current session is new or returning visitor
Checking with experts to confirm whether changes apply also to existing conversations