Recent searches
No recent searches

Mark Pinfold
Joined Jun 08, 2022
·
Last activity Jan 20, 2025
Following
0
Followers
0
Total activity
97
Votes
41
Subscriptions
27
ACTIVITY OVERVIEW
BADGES
ARTICLES
POSTS
COMMUNITY COMMENTS
ARTICLE COMMENTS
ACTIVITY OVERVIEW
Latest activity by Mark Pinfold
Mark Pinfold commented,
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.
View comment · Edited Jan 20, 2025 · Mark Pinfold
0
Followers
0
Votes
0
Comments
Mark Pinfold commented,
Great work and solid steps in the right direction.
Would it be plausible to assume that Zendesk are working on capacity to copy over data of custom fields into Child tickets?
This would be the droids we are looking for.
View comment · Posted Oct 17, 2024 · Mark Pinfold
0
Followers
0
Votes
0
Comments
Mark Pinfold commented,
Helvijs Vigners - What's your use case?
Ive had varying degrees of success with some implementations of workflows whereby end user ticket data is converted to article content using a mixture of dynamic content placholders and liquid markup.
View comment · Posted Aug 31, 2024 · Mark Pinfold
0
Followers
0
Votes
0
Comments
Mark Pinfold commented,
For those coming across this in the future:
Above works a charm: But dont convert the API key to Base64 like you would for other API requests.
It would appear Excel handles the encoding for you. Winner.
View comment · Posted Aug 14, 2024 · Mark Pinfold
0
Followers
0
Votes
0
Comments
Mark Pinfold commented,
Huge Kudos on the update to lookup fields reference via placeholder. This has such huge potential.
Is it reasonable to assume that this handles the concerns Zendesk have had about accidental data breaches in the context of Admins requesting lookups to be customer/end user facing?
If Admins can now apply dynamic filtration to the field and utilise placeholders to seek out the next tier of data for their own BTS workflows, is Zendesk now roadmapping implementing lookup fields for End User facing forms?
View comment · Posted Aug 02, 2024 · Mark Pinfold
0
Followers
0
Votes
0
Comments
Mark Pinfold commented,
Seeing as this is still relatively recent in terms of interest, I thought Id share my experience of this.
I tried the above methods and ended up implementing something that offers the best of both worlds.
The first method (individual custom field application) works great. but I had concerns around the required extra vigilance in administration and tracking of which fields have this applied (already several hundred fields in operation).
Also required an update in behaviour that ensured more vigilant confirmation testing of every field's presentation moving forward.
The second method (global application) by Terry works great for all fields by targeting the
elements, but my experience was that text would spill outside of the request form div container. Unless I added manual line breaks to handle the word wrap.
This quickly made my older fields look chaotic and messy.
So if anyone wants to mix these two great ideas, the following is something I have applied at a global level in the style.css:
/***** Global Request Form Customization *****/
.request-form p,
.request-form .hint {
white-space: pre-wrap !important;
word-wrap: break-word !important;
}
I placed the code in the same region as all of the "My Activities and New Request"" style handlers.
(greyed code for orientation purposes only)

Example is in a query initiated workflow I am implementing for our HR department as they transition from shared mailbox task culture to Zendesk.
As you can see, this means I can add no-code line breaks in field descriptions whilst conveniently handling any text wrap spill.
Ill provide further feedback if this bites me, but “so-far so-good”.
The field set-up:

The finished product:

Hope this helps someone some day.
View comment · Posted Aug 02, 2024 · Mark Pinfold
0
Followers
0
Votes
0
Comments
Mark Pinfold commented,
Option to pass along custom field data from parent to child ticket is a total no brainer. Just right there in the child ticket widget. Youre so close to “there”, but not quite.

The customer (agent or end user) expectation is that a “child” ticket is exactly that. A relative of its parent. Including its genetic code and inherent makeup, should that be required.
The custom fields API has the ticket data available from the parent, its plausible to believe that with some filtration pertaining to the nature of the parent ticket ("Form" being the obvious one to provide semblance of consistent object schema) these fields could be presented and passed alond simply enough as checkbox items similarly to the “select fields” option that is currently available.

EG: HR workflow. Where the core ticket contains various information types. Some would be sensitive and contained in the body of the parent ticket. Some Macro scenarios would want to create side conversations and actions arising. The child ticket should have an option (next to attachments, for example) to carry Parent ticket information into the child ticket. The child ticket could be an assigned action for an incident, or a new candidate in a recruitment workflow. You name it. The possibilities are endless. If you allow them to be…
EG2: Maintenance notice: Client submits request for maintenance or infra works. Ticket between agent and end user (client) develops to a point whereby external suppliers are required. One of the exact purposes for Side Conversations.
Child ticket is a scope / quotation workflow that would benefit significantly from information contained within the parent ticket.
Of course, There are other ways around these specific scenarios (webhooks, custom even triggers etc).
But currently a lack of native functionality is causing just that. Workarounds. The problem with workarounds is that they generate great burden on Zendesk Admins to produce hyper specific or otherwise creative workflows for teams who could (and would prefer to) engage in ‘follow the bouncing ball’ processes.
This ‘cause for creativity’ in turn creates White Elephant employees in orgs. When that Administrator leaves, there is significantly greater risk for Zendesk of client churn if the successor opts to “Work Around” the existing pile of workarounds in the handover notes by ditching Zendesk and choosing a more ‘user friendly’ solution - even if it's less ‘powerful’.
Users will always choose a path of least resistance where possible, even if it costs them.
The 80/20 split has proven that for some time now.
Zendesk is a great tool and its customization capacity is outstanding. Personally, I love it.
But its user friendliness is by far one of its biggest known pain points. Scenarios like this (of which there are plenty) will only continue to lose ZD customers, both potential and existing, to the booming low-code / no-code competitors who pitch OOTB solutions.
View comment · Edited Jul 30, 2024 · Mark Pinfold
0
Followers
0
Votes
0
Comments
Mark Pinfold commented,
+1, especially if that connector were to extend to lists and not just libraries.
View comment · Posted Jul 09, 2024 · Mark Pinfold
0
Followers
0
Votes
0
Comments
Mark Pinfold commented,
Complete no brainer.
View comment · Posted Mar 27, 2024 · Mark Pinfold
0
Followers
0
Votes
0
Comments
Mark Pinfold commented,
Big no brainer from my perspective. Make it a field type.
View comment · Posted Jan 26, 2024 · Mark Pinfold
0
Followers
3
Votes
0
Comments