Alan Pugh

Krzysztof Klimek It looks like you selected dark mode from the conversation menu rather than the profile menu

This is a great addition! When adding an article link via Knowledge panel, this is still coming across as plaintext with the long URL. Making this work similar to non-messaging channels would be a great next step!

Will Poon Any updates on rich text for Messaging?

Checking in on my request above from 2023. Dane any updates?

Brenda Piersak Not yet, it's something I'll need to add as a product suggestion. When I get around to that I'll post it here.

Rafa, messaging tickets do update via chat transcripts, but the first transcript isn't posted until ten minutes in. 

What we'd like to do is have a capacity for inactive conversations, as the uncapped scenario isn't ideal for small teams where only one person is “on chat” at any given time and the rest are focusing on backlog. With this method, the person “on chat” gets all the inactive conversation backlog, which isn't what we want. 

Adding a use case here:

We conduct account/transaction reviews and often reach out to our users via the email channel in Zendesk to request documentation. However, sometimes these messages are missed because they go to spam or the user is not actively checking their email.

We would prefer to send a notification directly in our app since that's where the user is doing most of their work. 

My goal is to use the first message the end user sends in the Messaging Widget as the subject.

I've managed to create a webhook to update the subject of a Messaging ticket automatically, which is pretty straightforward.

What I'm struggling with is getting the first message sent by the end user in the Messaging widget, which doesn't seem possible without a real-time API. 

The Tickets endpoint doesn't pull in the chat messages as comments, and the Event Audits endpoint pulls in the entire conversation as a single comment. Any other thoughts on how to pull in a single message in real time?

Amisha,

Thank you for the update. I certainly understand the explanation and the desire to default toward safer outcomes, and I see  how this approach feels like a shift in that direction. 

If I'm not mistaken, the white-vs-yellow agent UX for public and private comments has applied to all versions of agent workspaces for a number of years and addresses this in a consistent, visible way.

On the other hand, “internally-generated tickets which require agents to contact end users” seems to be a common workflow for Zendesk users. I'm not convinced that disrupting this workflow is necessary to prevent accidental public comments when the UX does such a great job of addressing this already. 

I appreciate the quick response and hope that we can find some level of compromise to bring back this functionality, at least optionally for those who rely on it.

Patrick Bu Jonassen Matt G. I've created a feature request to make this optional if you'd like to upvote it: https://support.zendesk.com/hc/en-us/community/posts/7310882774426 

This is having a major impact on our team and the explanation that it's an improvement in logic doesn't track. The feature is called “Public by default” and the improved logic is to make some tickets not public by default. It breaks the feature.