Jacob the Moderator

Erin O'Callaghan It seems that something has changed both with the JSON response - it no longer has a “value” property, and also with the Explore/Analytics custom attribute - it now accepts the field name from the UI.

Hi Alan Peterson and Rich Herbert 

I have not tested this, but using liquid markup to parse the subject line text should allow you to extract the two values you want and update the text fields with them.

For a subject line “Onboarding Request ABC|123”, the below webhook payload should extract the “ABC”  value and set it to the field with the ID 19626217318ABC, and for “123” set it on the field with ID 19626217318123.

{
    "ticket": {
        "custom_fields": [
            {
                "id": 19626217318ABC,
                "value": "{% assign parts = ticket.title | split: '|' %}{% assign value1 = parts[0] | split: ' ' | last %}{{ value1 }}"
            },
            {
                "id": 19626217318123,
                "value": "{% assign parts = ticket.title | split: '|' %}{% assign value2 = parts[1] | strip %}{{ value2 }}"
            }
        ]
    }
}

Charles Nadeau This looks like an awesome resource for customizing notification emails! I wish I had this when I last went down that particular rabbit hole! 😁

I want to call out another limitation not mentioned here. There is only a single HTML template, and while you can customize it to support multiple brands, the logic that controls which brand identity to show is only supported for Ticket-related email notifications. If you also have multiple branded Guide / Help Center instances, things like following notifications will not conform to the branding logic. 

I wrote a post about this last year when I became aware of this: 
Multi-brand support for Guide Email notifications.

Hi Santiago, 

If you read my earlier comment, it should guide you in how to prevent notifications from going out. Basically, you want to make sure that the notification trigger is prevented from running under some circumstances -there is no received at is not condition, but you can use a contains none of the following tags condition instead, and have a trigger above your notification trigger set it for the tickets that are received at those addresses you want to exclude. 

The requester field is for conditions where someone from your team is the ticket requester, and will not help with targeting support addresses. 

I hope this helps. 

Hi Joy Daludado 

I'm not sure that exact event is available, but webhooks do have some article-related events that could be investigated as a triggering event: Article events.

👆 This event could be used to start a flow (using a Zendesk webhook), but you would need some kind of middleware (Zapier, MS Power Automate or a ZIS flow for example) to take the Webhook response and modify it into a readable message and send that to Slack.

Hi Salman Shaik 

You can create users one at a time or import large batches of them, I'll leave a few links below that will tell you how.

https://developer.zendesk.com/api-reference/ticketing/users/users/#create-user

https://developer.zendesk.com/documentation/ticketing/using-the-zendesk-api/importing-users-with-the-zendesk-api/

Hope that helps you out!

Hi  Rob Stack 

I'm reviewing the sandbox creation report for rows where “copied” is "no", and I'm seeing a nameless row where “config_type” is “installations” - how do I find out what this is?

I have tried to look up the “source_config_id" in /api/v2/apps and /api/services/zis/registry/integrations but I haven't found a match. Hope you can help me progress here - thanks!

I agree completely! This change offers no value at all and is a major inconvenience. 
It is also concerning that this was made unannounced and for no discernable reason.

Thank you Alina Wright !🙏

Hi @... 

Does this change allow routing triggers from the production instance to be replicated in the sandbox with using these faux support addresses?