Montie Steele

Greg Katechis

Thanks for the response! I've gone ahead and used triggers to get the properties set up as a workaround, and i appreciate this explanation for setting the brand. 

another question - and, this seems far-fetched, but this is an odd use-case we're using SDK for. is there any way to set the first comment/description to be private rather than public when creating the ticket through the SDK in this way? 

I should note - we realize that the exact thing we're trying to achieve is far more possible and clear to execute using the gen API to create tickets, we're just currently unable to utilize API resources for the project, but are able to utilize SDK, so i'm trying to hack some of the things i know we can do thru the API with the SDK wherever possible.

We are using the iOS SDK to allow our users to create tickets in zendesk with the click of a button. We do not want them to fill out a webform or use chat - rather, click a button and an automatic ticket with the correct properties should be created in Zendesk Support. 

We're all set up, but we seem to be unable to set the JSON properties brand_id and group_id at ticket creation. We only appear to be able to set subject, tags, description, attachments, custom fields, ticket Form ID

consistent with this article we tried setting using the below code but it is failing: 

var client = ZAFClient.init();
client.set('ticket.group_id', 'groupid');

is it simply not possible to set these types of properties using ZDKRequestProvider and ZDKCreateRequest ? are we missing something? why would it be possible to set custom fields and ticket form but not systemic properties?

Is there any information about how this will work on enterprise accounts with Multi-Brand? Is it smart enough to only suggest macros that align to the brand of the ticket, or is there risk that in turning it on, it will suggest the wrong brands' macros to our agents? 

We have over 100 team members, so while filtering capabilities are nice, we really need to be able to search for a specific agent profile by their name or email. Please add the search bar back to the new page. any account with over 25+ team members i can imagine would greatly benefit from using search in addition to filters. i've hated having to search for an agent's user profile in Support, then click over to the admin center from there. i like that the admin center means i can now finally go directly to the admin center to change settings for my team, rather than starting in support, but the search feature is important to my workflow as an admin! 

Ifra Saqlain, amazing tip! I've just implemented this on my help center for a step-by-step process and it's gorgeous. One question - do you happen to know how i could turn an accordion step into an anchored link that automatically opens to the right step? i.e. we want to send some of our users directly to the correct step in the process, and have it auto-open where we send them once they've clicked the link. do you know if this is possible with this accordion set-up? 

seconding everyone else on this thread - we manage multiple brands and multiple teams in zendesk, so we have a long list of unique gmail inboxes connected in zendesk that we rely on. it's definitely not feasible for us to log in to each individual gmail inbox and set up forwarding for a potential notification that might go to that inbox (though as noted, it seems like that doesn't even happen any longer). 

as also other commenters have noted - how did yall build an admin notification for social integrations, but not for email integrations??? we need to see an admin email get sent any time there's an issue with an integrated email, as it is critical to any business that uses the email connectors. why do all of us have to advocate for such a simple, critical feature and to receive no support from ZD in seeing this feature get built soon?  

hi, i'd love to source a creative solution to a Transfer to Group issue we're having. this issue is taking place between transferring from our subscription team to our gen support team. 

1. customer calls in to subscription team with a gen support question
2. sub team transfers call to the gen support phone group
3. open inbound call ticket stays in the sub team view, which isn't great, as @... has posted about
4. IF an agent picks up, the ticket transfers to the support group and that's great
5. HOWEVER and this is where we are seeing a consistent problem - our gen support queues are super busy. so, what we see happening a lot of the time, is the customer ends up abandoning the call after waiting in queue for a little while, so the ticket never transfers to gen support. it returns to the sub team view as an open ticket, that now has a completed call appended to it. it's impossible to know when the ticket will finally update with the completed call, because it's dependent on when the customer abandons. I'm trying to find a creative solution for taking the burden of these tickets off the sub team? 

To continue to echo everyone's feedback, this is a useless feature that misleads customer expectations rather than sets them. 

Personally, I think wait time is also subject to much greater fluctuations than queue #. It would be great if instead of telling customers the wait time, it actually just told them their queue position, which is a more finite expectation than a nebulous and changing wait time expectation. 

It would be amazing if the Multibrand feature also made it possible to give this message by brand rather than individual number. A customer could call on a low-volume number for a high-volume brand and repeatedly hear a low wait time message when in actuality we have very high wait times for that brand to be services. One commenter also mentioned group which would be great, but since Multibrand is a paid feature it would be ideal if this was one of the benefits of that to set wait time by brand. 

@... - I agree that it's ideal to keep it all on the same ticket, and this is a workaround for that specific limitation, choosing to instead give agents context and creating a new follow-up thread (associated with the original ticket) that contains the notification that was sent. I am not very familiar myself with using http targets and do not know if that would create a similar workaround while keeping it on the same ticket! If you try that, please report back! 

Problem: When you use a trigger or automation to fire a notification, it is only possible to see the notification in Events - the notification is not appended as a comment to the ticket. This creates agent confusion, since they cannot readily see what notification the requester received in the ticket thread. 

Workaround solution: 

If you set the ticket to close upon firing a notification with a trigger or automation, when the requester responds to the ticket, the original notification sent by trigger is appended to the follow-up ticket as an internal note. From there, the ticket can resume in a back-and-forth thread as normal. so, we have every auto-sent notification close the ticket when it sends, so that agents can see what was sent to the requester when they respond. 

Here's an example of what I mean (image censored for business confidentiality purposes) -

1. We have a trigger set up to auto-fire a text notification to certain voicemail tickets. Thie trigger sets the ticket to close upon firing the notification.
2. This notification does not appear as a comment on the original, closed ticket that it is sent upon.
3. When the requester responds, this is the new ticket that enters the queue, that the agent can then work from with the context of the auto-sent notification as an internal note. while this use-case is text, it also works for email: