Announced on | Rollout starts | Rollout ends |
August 1, 2023 | August 1, 2023 | August 15, 2023 |
Zendesk is excited to announce improved collision management to control to how tags appear when multiple agents are working on the same ticket. This change prevents agents from losing tags on unsaved tickets when another agent causes a change to the ticket.
This announcement includes the following topics:
What is changing?
Before this change
Consider the situation where Agent 1 updated a ticket to add a tag, but hadn't saved the ticket, yet.
If another agent, Agent 2, triggered an event on the ticket (for example, via a trigger, macro, or automation), the unsaved tags added by Agent 1 were removed from the agent interface. This made it essential for agents to review the Tags field before submitting the ticket to make sure the tags they added were still there.
For example:
- A ticket initially has the tags "blue, magenta"
- When Agent 1 adds a new tag "yellow" without submitting the ticket, the tag field shows "blue, magenta, yellow"
- When Agent 2 adds a new tag "white" and submits the ticket, Agent 1's unsaved changes get removed and the Tags field is updated as "blue, magenta, white".
After this change
This update changes the way we merge tag changes from the server. Now, when Agent 1 adds a new tag without submitting the ticket, the Tags field shows everything that existed before editing and after editing. When Agent 2 adds a new tag and submits the ticket, Agent 1's unsaved changes will still persist, with the addition of the new tags submitted by Agent 2.
For example:
- A ticket initially has the tags "blue, magenta"
- When Agent 1 adds a new tag "yellow" without submitting the ticket, the tag field shows "blue, magenta, yellow"
- When Agent 2 adds a new tag "white" and submits the ticket, the unsaved changes by Agent 1 are merged automatically with the tag changes from the Agent 2. The Tags field will read "blue, magenta, yellow, white"
Why is Zendesk making this change?
We heard your feedback! Zendesk’s collaboration ability allows for multiple agents to make changes to tickets. For a long time, tags that an agent applied may or may not show up, depending on who saved the ticket most recently. This caused tags to be missed from the tickets. This change reduces the need for agents to to double check tags before submitting a ticket.
What do I need to do?
You don't need to do anything. This change will be automatically rolled out to your account.
4 Comments
This is awesome! Although your example mentions the concurrency between 2 agents, will this work along with other Tag changes, such as those from the following endpoints:
and
Therefore having all ticket updates from the Ticket interface have its ticket.tags diff resolved to add and remove instead of replace?
I have a similar question as Rafael. Does this have any impact on the API updates? We have always had problems with API updates for tags where the tags will be lost when another update happens.
Hello Rafael and Jagan,
Rafael - Correct, the ticket.tags diff is resolved to add and remove rather than replace.
Jagan - This is just a frontend change, and relates to how we solve tag collisions in the ticket UI. Since the tag changes will persist in the UI, the API will update depending on if the agent submits the tag changes. Scenarios with HTTP 409 errors were not considered here, but may be looked at more in the future.
please confirm if this feature only applies to manual updates of tag field or automated tag updates by trigger/macro/check-box, drop-down field updates
Please sign in to leave a comment.