Recent searches
No recent searches
Feature Request - Placeholder Option to Display Label or Tag of Custom Fields
Posted Jul 16, 2024
Summary: Currently, placeholders for custom fields that are drop-down lists display the tag (or “key”) associated with the selected option, not the label (or “value”). This can be inconvenient when we want to display the label in macros, triggers, and automations.
Details: Maintaining Liquid Markup for each custom field in every macro and trigger is labor-intensive, especially when we have a large number of custom fields and frequently update the drop-down lists.
Use-case example: For example, if we have a custom field with a drop-down list for “Issue Type”, the placeholder currently displays the tag, such as “issue_type_1”. However, our agents and customers understand the label, such as “Login Issue”, not the tag.
Proposed Solution: I propose a feature that allows us to specify whether we want the placeholder to display the label or the tag of a custom field. This could be implemented as a simple syntax addition to the placeholder, such as {{ticket.custom_fields.field_key~label}}
for the label and {{ticket.custom_fields.field_key~tag}}
for the tag.
Benefit: This feature would significantly reduce the time and effort required to maintain our macros and triggers, and would make our communications more clear and meaningful by displaying the actual labels that our agents and customers understand.
Impact if not implemented: Without this feature, we will continue to spend significant time and effort maintaining Liquid Markup for each custom field in every macro and trigger. This also impacts the clarity of our communications, as the tags do not always clearly represent the labels.
Any workaround you’ve considered: The current workaround is to use Liquid Markup to create a conditional statement that checks the tag and then outputs the corresponding label. However, this is labor-intensive and not scalable, especially when we have a large number of custom fields and frequently update the drop-down lists.
2
3 comments
Allison Cloyd
Yes please, this would be a huge benefit to us as well.
0
Shawna James
Thank you for taking the time to provide us with your feedback. This has been logged for our PM team to review. For others who may be interested in this feature request, please add your support by upvoting this post and/or adding your use case to the comments below. Thank you again!
0
Mark Pinfold
100%. Not sure why there are any downvotes tbh?
Especially without comment. Perhaps theres already good valuable approaches for this that are simple enough? If so, please feel free to explain.
For people who arent ninjas, but not ludites its not super uncommon for people to want an object's key name (field title) for secondary data flows in the context it's been used, not just it's value (tag).
Its already exists in the ZD API field data as (I think?) field.title - it would be super useful for people who are confident enough to engage with placeholders effectively, but not confident enough or time rich enough to pull a queried API call apart and render a key title.
Particularly with Dropdowns, Scotts on the money - it would cut down a significant bunch of messing around and future administrative burden if it could just be exposed directly from within the agent workspace and rendered to customers and clients in a more friendly-format manner.
Whilst I like Scott's syntax proposal, as it's explicitly aluding to key value pairs, my two cents for syntax proposal would be simply to expand upon what youve got to benefit those already deriving workarounds using the tags mixed with liquid markup - not to mention make it more low hanging fruit for ZD Devs who have pumped out a bunch of awesome updates in the past year around objects in general.
So sticking with the Ticket object as an example…
We know from the API, a custom field is a part of an array at the Ticket Object level and has an ‘id’ and a ‘value’ already.
"custom_fields": [{ "id": 34, "value": "I need help!" }]
So why not something like…
Dropdowns:
Current State:
{{ticket.ticket_field_option_title_123456}} - Renders the ‘Value’ of the field 123456 (Tag)
Future State:
{{ticket.ticket_field_option_title_123456}} - No change (not my preference, but purely for minimum disruption)
{{ticket.ticket_field_option_id_123456}} - Renders the ‘Field Name’ of the field. A little counter intuitive and potentially confusing for customers, but calling the ‘Value’ of a field ‘title’ in the first place kinda already was.
‘Flat’ Custom Fields Future State:
{{ticket.ticket_field_123}} - Renders the ‘Value’ of the field 123 (Field Value Output of some sort depending on data type)
{{ticket.ticket_id_123}} - Renders the ‘Field Name’ of the field 123. (Not to be confused with ticket.id)
Benefit being, people can set even basic templates to be
Hi, {{ticket.requester.name}}
Heres your info for {{ticket.id}}
{{ticket.ticket_id_123}}: {{ticket.ticket_field_123}}
{{ticket.ticket_id_1234}}: {{ticket.ticket_field_1234}}
{{ticket.ticket_id_12345}}: {{ticket.ticket_field_12345}}
Any future administration over the field itself should, in theory, update automatically across whole domain's environment in any macros, triggers, templated/dynamic work.
Not sure, but hopefully would extrapolate out comfortably enough for all current dot-notation-atomised object referencing frameworks in Zendesk (Users./Custom Objects./Orgs. etc)
I dare say there's going to be crossover from the proposal that conflict with elements that already exist that I havent yet needed to tinker with, so plenty of good reasons for the syntax to be wrong.
But exposing the field name quickly for an agent or workflow is actually just… kinda handy in a million different contexts.
0