Question
How can I ensure the privacy of unauthenticated customers who use the Web Widget on a shared browser in the Agent Workspace? What happens when customers use a shared browser?
Answer
When customers use a shared browser the system attributes the same email to two separate users. For example, if user A starts a conversation using email A and name A, Zendesk creates a ticket with user A as requester A.
If user B starts a chat on the same browser with email B and name B, Zendesk creates a new ticket and attributes it back to user A due to the persistent nature of messaging.
To prevent this, customers with a shared browser setup should use the incognito mode on their browsers when initiating a message on the Web Widget. Visitors can also clear their cookies after they are done with each conversation.
If you are currently on messaging and have a setup where it is common for users to share a browser, set the Web Widget settings under the Authentication tab to Forget history. This setting ensures that the conversation starts fresh every time a customer initiates a conversation and previous conversations will not persist across the Web Widget and messaging channels. The Forget History feature is session based. You'll need to open up a new browser tab in order for the conversation to start fresh.
For more information, see the article: About messaging.
9 Comments
Hi,
Can I set forget history for iOS and Android?
Forgetting the history feature is not available yet on the iOS and Android channels because that is exactly the whole purpose of Messaging. To be both synchronous at asynchronous at the same time and conversations to be present at all times and any devices. The workaround for now is to create a trigger that will close Messaging tickets so it starts fresh. I hope this helps! Thank you.
Hi Gabriel,
We had configured a trigger to close the ticket after it is set to solved. Unfortunately we still see the history in the messaging.
We are using version 2.3.0 of the SDK for both iOS and Android.
It seems that this is a current limitation in iOS and Android. The option for Forget History is available in the messaging widget only and does not apply to iOS and Android.
For reference, please see this article: Mobile limitations
Thanks,
Hi Gabriel,
I think the mobile limitations only mention that the history is limited to last 100 message.
Conversation history :The conversation history is limited to the last 100 messages.
For each new ticket, we do not want to show the messages of previous tickets. As per your comment previously, closing the ticket should start the conversation fresh. Would like to check if this was a misunderstanding and current behavior will still show messages from previous tickets?
The workaround for now is to create a trigger that will close Messaging tickets so it starts fresh. I hope this helps! Thank you.
Upon confirming, this is not natively possible as this feature is only available to the Web version of the Messaging Widget, but not the SDK. This feature was released with the idea of protecting users that are sharing browsers with other users.
I encourage you to create a new post in the General Product Feedback topic in our community to engage with other users who have similar needs and discuss possible workarounds. Conversations with a high level of engagement ultimately get flagged for product managers to review when they go through roadmap planning.
It would be helpful to provide the customer with an option to either start fresh with a new ticket, or continue with the existing messaging. While testing, I have found it annoying that there is no easy way to go back to the original flow options. The only way I am presented with options is by asking a question, but that means I miss all the provided options from the flow and am limited to only what comes up based on my question.
I think this is a limitation with messaging in general because I may want to continue with my existing message, but I may also just want to start over and giving the customer the agency to do this would provide a better customer experience.
Hi Ana,
I can understand where you're coming from here. There is already a discussion about building this feature here. I highly suggest that you add your use case to the thread to have it gain more traction.
Hope this helps.
This needs to be addressed yesterday. Web browsers are not the only devices that are shared with many unauthenticated users. This is a major limitation, and the concern was raised over a year ago.
Please sign in to leave a comment.