Agent Workspace: Keep content from internal note if changing to public reply

1264663901569 – The crux of the feedback is that the legacy editor pane color difference between public comment and internal comment was sufficient for many teams to call out the difference.  Allowing a comment or comment editor to be defaulted to internal comment is great, however, similar to the legacy experience, if the agent toggles the comment editor from internal >> public or vice-versa, the comment text should be retained.  People are reporting frustration at having to highlight and copy + paste the message body as well as toggling over in order to avoid having to completely re-write the intended message.

Thank you for responding to this post.

I am collecting all of your feedback and will prioritize accordingly. Thank you!

The UX is confusing and its unclear what is going to happen on submit. Consider the case where I start typing in public reply, realize I'm in public reply mode, and then switch modes to internal note. I get a blank box, so I start over and type again. If I switch back to public reply, my original text is still there. When I submit the form, it is unclear if both text inputs should send, or just the active one.

This is a solved UI problem. Only use 1 input box, and indicate which mode it will be submitted in.

1900354184804 1264663901569 

Thanks for the follow-up.
 

This has been a pain point for over 3 years now, and while draft mode is useful in other contexts, it doesn't solve the core issue. The original ability to switch between internal notes and public replies without losing content was critical to many teams' workflow.
 

Most support teams rely heavily on keyboard shortcuts to move quickly. Being forced to manually copy-paste just to change the message type adds friction, breaks flow, and increases the risk of errors, especially in high-volume environments where speed and precision matter.
 

Draft mode doesn’t preserve content when switching modes mid-reply. That means a feature we used daily is still missing, with no real replacement. This isn’t a “nice to have” — it’s a basic UX expectation that’s been left unresolved for years.
 

We strongly urge the team to prioritize restoring this functionality, or at the very least, build it properly into the draft experience. The workaround is not sufficient.

Hi 1264663901569 

>1. You wanted the ability to carry content over from internal notes to public reply and back and we tried to solve your use case with draft mode. Is draft mode able to solve your need?

For us draft mode did not work out at all: the biggest problem with draft mode is that after a while, people automatically click “Send” to pop-ups. Agents get used to the fact all the time to send response you need to click it and it is rather becomes an automatic action, rather than an instrument to prevent accidental internal notes to be sent to a customer.

Hello everyone,

Thanks for your responses here. Its been a while since we released draft mode. I want to do a quick check-in here. If you can please answer a few questions -

1. You wanted the ability to carry content over from internal notes to public reply and back and we tried to solve your use case with draft mode. Is draft mode able to solve your need?

2. If not, can you explain why draft mode does not work for your workflow and why you need the content to carry over? Thank you!

Hi All,

I’m an independent Zendesk app developer, and after seeing all this feedback about being able to easily maintain content between internal notes and public replies, I decided to build out this feature into a Zendesk app. We have recently launched an updated version of our Drafts app on the Zendesk Marketplace, which includes a button to copy internal notes to public replies.

This app is free to use, so feel free to install it here and see if it can help.  We'd appreciate any feedback that you have as well!

Thank you ~

Beyond this, I'm curious as to why Internal Notes and Public Reply are even in the same part of the UI. Its like ZenDesk wants our agents to mistakenly send internal notes to customers. Seriously, please move notes to a different part of the UI. Perhaps make a “Internal Note” button and then have that expand a separate section to write notes in. There's no need to make some complex engineering solution to save drafts here, just separate out the input textfields to prevent mistakes and you get the ability to send notes and replies for free. 

Is there any update on when this loss of function will be re-enabled, or at least configurable by admins, to retain the text content when toggling from internal comment to public comment?  In my view, this is actually presenting as a bug as opposed to a security feature, for the reasons outlined below:  

Draft mode unfortunately does NOT address the major user experience issues associated with this change, and unfortunately our org has had to revert entirely from Agent Workspace, losing much of the efficiency features that we have, due to the fact that we use 100s/1000s of macros legacy to agent workspace that default the comment type to internal while the agent customizes minor areas before publicly sending.  

This forces people to manually copy + paste, and also we have no ready way to determine which legacy macros automatically set comment to private to make any adjustments.  
 

In addition, the feedback that we are getting is it increases the risk of sending an incomplete message to the requester.  None of this is addressed by having agents manually click DRAFT MODE.
 

To my understanding this change wasn't communicated as part of the agent workspace migration, that admins would have to figure out a way of determining within their 100s and 1000s of macros which ones default to private versus public and make the adjustment.  

We've had to roll back agent workspace entirely because of this, as we have no ready way of determining how many of our macros will need to be edited.  

Amon Wong and Crystal Bustil - draft mode is present in the agent workspace now and if it is turned on, then you can have the default set to be public reply and then enable draft mode. The icon is in the far left from any public reply window and once enabled, then you have to hit an ok confirmation for the email to be sent. Until draft mode is turned off, the state of draft mode persists between tickets.

This has resolved the issue quite well for our team, although there have been some other updates that make keeping public as the default reply mode more feasible now (tickets with messaging no longer default to messaging after an email has been sent - which is a huge improvement!)