Check text ticket field value

Nice one, Arturo. Thanks to for Andrew J for the original idea, and to you for trying it out and writing it up for us!

Hi Arturo, this is a very good example! Thanks for sharing!

I've follwed your example and tried to apply it to my scenario.

I use a trigger that basically updates the ticket status and also should populated a multi-line field with a default value by using the HTTP target solution. 

For some reason it just doesn't work, the status gets updated correctly but not the text field where the target should come into place.

For the HTTP target I've used API key for authentication.

Something that I've noticed and it seemed strange, when testing the target - at first try it didn't work (it gave me 401 Unauthorized 0- "Couldn't authenticate you"), I have reapplied the token string and it worked.

In test target response I do see that the custom field is set properly, but only if I reapply the token, it always give me first the 401 error message.

Did something like this occured for you too? 

Hi Vio,

I did have problems in the past when I was updating the configuration of my HTTP targets without updating the authentication parameters. Since then, I always re-enter the authentication parameters on HTTP targets that need them after making any changes.    

If after trying that you still have problems, I would recommend you going through and double checking the configuration of your ticket field, dynamic content, target, and trigger. Also, and after omitting any confidential data, feel free to post them here. Maybe somebody can spot a configuration problem.

Hi Arturo, 

Now is working, I'm not clear why it didn't work for the first time.

Have you encounter any issues with the HTTP targets since you start using this workaround? like the target didn't fire or the business rule that uses the HTTP target didn't apply the other actions that existed along with the target?

Zendesk doesn't recommand to use this workaround because it could lead to a race condition error, but in the same time we cannot update text fields (text, multi-line text) via the business rules. 

Thanks!

I'm not seeing how this works? {{dc.anything}} is not listed as a valid placeholder text, nor can I pick anything other than the available placeholders.

I'm attempting to get a custom organization field in this manner, however, it seems completely out of reach:

{"ticket":
    {
        "custom_fields": [{ "id": "27681598", "value": "{{organization.organization_fields.my_field}}" }]
    }
}

There has to be an easier way to nail this. This is way too much work for propagating a simple organization field down to a ticket simply because it's a text field.

Hey Craig,

If you're having issues, could you specify what step of the tutorial is causing you trouble?

Thanks.

I'm pretty sure I'm referring to a ZD limitation of no access to organization fields from within this trigger framework. The only fields allowable are ticket and current_user fields. (Presumably, as only tickets can generate triggers.) There is no hierarchical access to data from the associated requester organization as far as I've been able to obtain.

There are no {{placeholders}} for related organization fields (custom fields at that) for what I'm needing to propagate into a ticket field. (Specifying the field directly results in it being literally copied as the text from the JSON.)

However, I also have dynamic content items, and I don't see that I can access those through placeholders either. I don't understand how that's working for you. That is, How is this accessible from within your trigger?

"custom_fields": [{ "id": 654321, "value": "{{dc.asking_for_noreen}}" }]

I can ONLY access available ZD provided placeholders from their drop down within a trigger.

Update: I do now have the dc.<somefield> working in my trigger (my test condition was not correct). Interesting it is allowable. I'll need to play more to see about what content I can access from there. 

Thanks for an interesting approach though!

Arturo, thank you for sharing this! That's a great tip that helped me a lot.

It is actually possible to use Drop-down fields as well:

1. Instead of "Checkbox" create and use Drop Down field

2. Set Dynamic content as follows (be sure to use Tag from Drop Down Field Options, not a Title since tag is used in API to update a ticket value):

{% case ticket.ticket_field_114096789653 %}
{% when 'Amazon Marketplace' %}tag_1_from_drop_down
{% when 'Azure Marketplace' %}tag_2_from_drop_down
{% when 'Aliyun Marketplace' %}tag_3_from_drop_down
{% else %}
{% endcase %}

3. All other staff is the same.

Great addition, Anton! Thanks for sharing it!

Hi guys and thanks for the excellent article.

I'm trying to get this working with number/decimal fields but it seems this Liquid markup:

{% if ticket.ticket_field_114099389194 < 200.0  %}true{% endif %}

OR

{% if ticket.ticket_field_114099389194 < 200  %}true{% endif %}

Always returns True.

Any ideas what would be the correct Liquid markup syntax for "Less then 200" = "True" ?

Hey Henrik,

After checking with Zendesk, the values currently returned by ticket field placeholders when using Liquid to query them are always in string format. Because of that, operations like greater or less than than don't work as expected with numeric values.

I hope that Zendesk can fix this or allow checking numeric/text ticket field values from conditions soon. 

Thanks for the article, it's been tremendously helpful to us!

I'm trying to take it another step further but not having much luck and hoping someone here can help. I wanted to update an Organization dropdown field (instead of custom ticket field) using Anton's method but I can't get the JSON script right, I've read through the developer API documentation and tried countless variations, even tried using a URL target instead of HTTP but no success. The furthest I've got is to update the Organization with the tag of the dropdown but it doesn't select the actual dropdown value (i'll have to concede to just having this if all else fails).

What I have currently set up:

Dynamic content "{{dc.org_field}}" using the method

{% case ticket.ticket_field_123 %}
{% when 'Amazon Marketplace' %}tag_1_from_org_drop_down
{% when 'Azure Marketplace' %}tag_2_from_org_drop_down
{% when 'Aliyun Marketplace' %}tag_3_from_org_drop_down
{% else %} 
{% endcase %}

Then a trigger calling the HTTP target (https://subdomain.zendesk.com/api/v2/tickets/{{ticket.id}}.json)

with a JSON body with some variation of:

{

"ticket": {

"organization_field": [{ "id": *organization field id*, "value": "{{dc.org_field}}" }]

} }

Both the trigger and the Extension target fire as expected but there are no results. I know I'm getting the syntax wrong.

FYI the URL target to update the tag is along the lines of:

https://subdomain.zendesk.com/api/v2/organizations/{{ticket.organization.id}}.json?organization[tags]={{dc.org_field}}

I've been trying to mix this with Arno Lindroos' suggestion here but it's not working, most likely due to my inexistent liquid skills.

Basically, the goal is to set a checkbox ticket field to TRUE whenever a ticket has an attachment.

What I have behind my dynamic content placeholder:

{% assign attachment_count = 0 %}
{% for comment in ticket.comments %}
{% if comment.attachments.size > 0 %}{% for attachment in comment.attachments %}true
{% endfor %}{% endif %}

Then on my trigger:

{
 "ticket": {
 "custom_fields": [{ "id": 360012786074, "value": "{{dc.attachment}}" }]
 }
}

Any hints?

Hey Pedro,

Definitely heading down the Liquid rabbit-hole here. When you fire this trigger, do you get any entries in the Target Failures section of the API menu? it might help pinpoint what's going wrong.

If you put the raw Liquid into the value field of the trigger, instead of the DC placeholder, do you get the same behaviour? If so, it's likely not the DC causing the issue, but either your Liquid or something with how Zendesk is or isn't processing it with the target.

You could also try using something like https://requestbin.fullcontact.com as your target, to be able to see the output of what you're sending, and make sure that what's being sent is what you're expecting.

Hope that helps some:)

Does someone know how the variables are filled in the http-target URL? For example https://subdomain.zendesk.com/api/v2/tickets/{{ticket.id}}.json seems to work just fine on it's own since ticket.id is filled somehow. But how to deal with the following URL? /api/v2/help_center/{locale}/articles/{id}.json

For editing user fields the users link works just fine with {{ticket.requester.id}} but I want to draw the body of a helpdesk article into an email or a makro. I checked how it works with manually adjusting id and locale but it would have to be somewhat defined.

I can't run API calls directly through liquid, I have read. But somehow I would like to attract content. How can it be done?

{
"user": {
"user_fields": {"preferred_language":"{{ticket.ticket_field_360000267739}}"}
}
}

Is working fine that way where the ticket field is the dropbox that is identical to preferred_language, the dropdownbox in user. However, this only works for single values chosen. If more than one language has been chosen by the user then it fails. Will search now how to add more than one value to the dropdownbox.

I search a way how I can access data through the API. Setting data with the API works relatively good, however I did not find out how I can extract data.

For example, for a test I wanted to use the API to request the body of a helpdesk article and put it into an email from a trigger. However, I have no idea how that could be done. Might be I just oversee something since there surely is a way.

https://xxxxx.zendesk.com/api/v2/help_center/de/articles/360003611679.json  for example can show the json of an article. However, In liquid I can't access the API or use a link that might be more advanced. I doubt dynamic content elements could do way more.

I just can't think of a way to use the above link to extract the body. Might need to edit it with liquid afterwards.

Anyone?

Hello Brett,

Looks like the forum ate my post, so here it is again.

We already use the knowledge capture app. We don't use dc in the helpcenter because it would mean a good bunch of additional work for the content team, thought it might make sense for certain parts of articles.

Changing data in the database through the http target and the api seems to work fine, however accessing this data should be possible as well through http targe, however I do not find a way to bring it to use with zendesk internally.

It's just that I want to know how to access the data so I can receive info from the database. Reading out makro or helpdesk content would be more of a proof of concept while in fact it might get taken to use as well.

Thank you!
Sebastian

Hi Sebastian, 

Who is the audience for the read data?  Is this used to help agents do their job or is it used to help end users know how to follow certain steps? In short, what do you do with the data once you read it?  What benefit do you hope to receive? 

For the former, could an agent search the knowledge base from the Knowledge Capture app for the current solution? 

For the latter, would a link to the content be enough to inform a user on next steps? 

If you are populating ticket fields, could you use a custom Zendesk app to query your article and update the field directly instead of trying to use a trigger to do so? 

If this is for version capture of articles, does the built in versioning work?  

Hello Dan,

It would not be used for the agents, but it might make sense that certain data is fetched via API to fill form fields of a ticket or a user with it. So that the agent can see the custom fields of the ticket and decide on a broader dataset about the problem and the background a user has. This is something that probably should be done in a trigger.

Updating ticket and user fields, also custom ones, works fine already via HTTP target and API, however in all these cases I receive the data through the contact form. I have no case where I receive data through a HTTP target and the API.

The current idea is that I might be able to automate certain steps with an initial first response. We will rebuild our contact form to a topic tree. So we have a very clear view about the topic a user has. The agents then would, in most cases, just send a certain makro, maybe personalizing the answer. But there a lot of points where we already can answer some things automatically because they have just one answer. For example, "How to reset 2FA", "How to change email address" both have clear makros that would be sent out. Now, that we can specify the topic to clear, I could setup a trigger to just trigger that certain point and send out a mail with informations. However, instead having to keep track of another load of content, it might make sense to just request a certain makro's text and send this makro, so when the makro is editet, the mail will also be up to date.

That's just one idea where this might make sense. Yes, it might be possible to put text into a dc element, however editing the makros would be harder then as well.

Practically, I really just search a way to access the api with read access. I mean the HTTP targets has this funtionality. It's only I can't think of a way to use it for this case.

We already use Knowledge Capture.

A link would be a workaround, however it probably wouldn't be accepted because it is a link and requests further action. I think at the end it would mean the content would be in the email in the trigger then again. So duplicate content that the team would have to keep track of.

The Zendesk app sounds interesting, avoided the topic till now, but would it be possible to read data out of the database with it? I would give it a try then.

It's not for version capture of articles. Just the general possibility to read data with the Zendesk API.

Thank you,
Sebastian

Hi Sebastian, 

There are a few things you can check out to help your customers get answers automatically.  I would probably not use Targets for them as they are really meant to push things out of the system versus pulling them in.  

If you are using the Zendesk Web Form, there is a search prompt included when updating the subject field that recommends potential articles that solve that ticket.  Updating articles based on the words your customers use could help surface this content as they create the ticket and potentially allow for the ticket to be deflected. 

You mentioned you already use Knowledge Capture, the data collected in that app can help you utilize Zendesk's Answer Bot feature.  This feature will prompt customers with an email of possible articles that might resolve their problem. In addition, they'll have the option to let you know and train your model on if a specific article met their needs.  In addition, as they search your knowledge base, you can set up Answer Bot to ask them if the current article they are viewing resolves their ticket.  The only catch is that Answer Bot is a paid feature that charges based on the number of solutions it serves up.  This could be great if it's cheaper than having someone do this work.  But if you automate in other ways, it may not be the right solution for you. 

Alternatively, you could use keywords and your ticket fields to help you identify obvious tickets.  If you only have one use case for 2FA, you can setup a trigger that automatically replies back with the tips for how your customers can be successful with 2FA. You could also have multiple triggers that add tags to a ticket to help guide the email you send.  You might only send a specific message too someone if their fields/content includes "iphone" and "2FA", but a more generic response to someone with only the "2FA" tag.  This would be a message that is written out in the trigger or you could include a link directly to the content so that your content is always up to date (as long as you update your articles quickly).  You could consider wording that says "Thanks for your email, while you wait, check out these articles to see if they help you with your issue".  This way you can still follow up with a personalized response if necessary.

The most important part in any solution though is that you'll need an intake that can provide you enough context points to understand how you can automate this.  Make sure your forms are built in a way that you can collect all of the data points you need to solve a request.  If you are using a custom web form, use the Requests API to create tickets instead of email.  This will give you more to work with.

I hope these ideas help some.  I'm sure there are other ways to approach this as well, but these are the areas I'd recommend checking out first.