Hey, everyone. Our team noticed a limitation with Zendesk’s ticket sharing that’s causing some issues with how Dynamic Content loads comment text in our macros, and I'm hoping to get some more attention toward it.
Quick background: we make heavy use of Zendesk's Dynamic Content manager to help keep our non-English support responses consistent and organized. It works well for the majority of our tickets, and allows us to store and maintain our macro text via the DC variants, which reduces duplication: we can create 1 macro instead of 12+ (the number of languages we support) for the same issue/process—making upkeep and organization easier.
However, the Dynamic Content system appears to depend on the “Requester Language” (or “User Locale” in reports/API) field, which has presented a problem. When working with Zendesk-to-Zendesk shared tickets, this language field does not does not map over to the spontaneously-generated ”shadow” user account in the receiving Zendesk when a ticket is shared. This means that even if we know that a user’s language setting is French on the source Zendesk, the value will always be set to default language of the receiving Zendesk (English, in our case). Worse, this field cannot be edited in the shadow account .
We can work around this for certain things such as queuing: we apply a language tag on the source/sending Zendesk, which then triggers the ticket to be routed to the correct language agent team on the receiving Zendesk. With the actual locale value forced to stay on English, though, the Dynamic Content string will only ever load the English variant text when applying macros, and we can’t seem to force the appropriate stored language variant text to appear. This means that the system we’ve set up for our natively-created tickets will have to be tossed aside when handling shared tickets, and replaced with multiple macros (1 per language supported) for each issue. This makes the job of our process supervisors much more difficult when it comes time to roll out changes and make certain that all languages are up to speed.
Not having that language data mapped in shared tickets—plus having the language field locked to edits on the auto-generated shared user accounts—causes other issues as well. For reporting language volume, we would have to use two different systems: one based on tags, and one based on the locale data provided natively in Zendesk, and then try and filter out any overlaps between the two reports. My biggest complaint is the added challenge this presents for our team in maintaining the same content/macro actions in multiple areas, and devoting time and other resources to try and bandage Zendesk’s own native systems not playing nice with each other.
If there’s any workaround for this that we haven’t considered (beyond macro duplication), I would definitely like to know more, but would also ask the Zendesk team to consider improving this in the product itself.