Collin C

Please give a quick overview of your product feature request or feedback and note who in your org is affected by this issue [ex. agents, admins, customers, etc.]. (2-3 sentences)

Editing an agent's groups through their profile can be unnecessarily tedious, especially if you have a large number of groups. This is because the "default group" dropdown is listed after all the group cards. Depending on your processes, making simple changes to an agent's groups can be a frequent annoyance or a rare head-scratcher for admins (or agents with the newly-introduced permission to modify group memberships).

What problem do you see this solving? (1-2 sentences) 

Changing an agent's groups often involves adding a user to a new group, setting that group to be their default group, and removing them from their previous group. Since changing the default group must occur after setting the new group but before removing the old one, this involves at least scrolling to the bottom of the modal to change the default group before scrolling back up to remove their old group. It can be easy to lose your place, and especially frustrating if the new/old groups are close to each other but far from the bottom.

When was the last time you were affected by this lack of functionality, or specific tool? What happened? How often does this problem occur and how does this impact your business? (3-4 sentences)

It's a minor annoyance that I believe would require an appropriately minor effort to fix. I recently had to migrate a set of agents to a new group, which required scrolling up and down the group modal for about 5x as long as I believe is necessary. This happens a few times each month in my current environment, but has been a near-daily task in the past.

Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)

I have considered writing a custom app to make group changes easier, but it's not currently annoying/frequent enough to spend hours fixing.

What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)

I can imagine two changes that would greatly improve this process. The first is some UI element on the group card itself that allows you to set it as the default group directly, which would also help to indicate which group is an agent's default. The second change would be to replace the "you can't remove this group unless you set another as default" message with a prompt that allows you to immediately select a new default group, perhaps surfacing the exact dropdown that you'd otherwise need to scroll to.

Current: Scroll to new group, click it. Scroll to bottom, make default dropdown selection. Scroll back up, remove former group.

Potential: Scroll to new group, click it. Click "make default" button on the same card. Scroll to old group, click to remove. Done.

Or: Scroll to old default group, click it. Select new default group from the dropdown. Done.

This becomes even worse if you're reporting on multiple multi-select fields, because the duplication compounds. Like, every option of field 2 will be listed next to each option of field 1, like:

Ticket ID, Liked Foods, Liked Drinks
1,Pizza,Water
1,Pizza,Tea
1,Sushi,Water
1,Sushi,Tea

It increases multiplicatively, where the number of rows = # of selections for field 1 * selections for field 2 and so on. I have a report where there are 3 multiselect fields and just 2 selections in each field means 8 rows for one ticket, and for many tickets it's more like 16 rows.

I'm trying to see if there's a way to accomplish this with custom attributes, but no luck so far.

Is there a keyword for searching only the initial comment of a ticket? In all other contexts this is called the "description," but in search this seems to include any subsequent comments on the ticket as well. I think this is misleading.

+1, me from 3 years ago. Again had a big issue caused by how Zendesk handles target failures.

I understand that the internal terms could be confusing to end-users, but I'm in favor of some configuration options so admins can use the terms best suited for their business. For example, "solved" may be undesirably definite in some cases, and on-hold is often used to indicate a specific third-party that is known to the end-user, so communicating that to customers via status (e.g. "awaiting warehouse approval")  can help reassure them that the agent isn't just sitting on their "open" ticket.

Feature Request Summary: 

Currently, you can only view a form's conditions from the ⋮ button on the main forms page. It would be better if you could also access these while editing the form's fields/order.

Description/Use Cases: 

You're modifying a form. You want to remove a field, but you get an error that it's used in the conditions. To edit those conditions, you need to go back to the list of all forms, find your form, and use the ⋮ menu to get to the conditions page. You can't navigate back to the form editor from here either, so you need to go back to the list of forms and click it again. You try to remove the field, but it's still in a condition... oops, you only removed it from the agent conditions, not the end user conditions, so now you're making the trip again.

Business impact of limitation or missing feature:

The navigation required is surprising and not intuitive. The additional navigation required is distracting & wastes time. Also, this hurts the discoverability of the conditional fields feature, as I imagine most admins are used to the ⋮ menu containing options to deactivate/clone the item, not as a gateway to a discrete feature config page.

Yes, this is the one thing I miss from hub-and-spoke. You can prevent agents from viewing tickets outside of their current groups, but I haven't ever seen an instance where it made sense to apply that restriction to everyone, considering how absolutely overloaded "group" is.

Hi James, good to know. My use case is related to agent management. For example, if I need to update a property on multiple agents, my workflow is to go down the list, searching the email address with role:agent in order to find their profile. (This is assuming the property can't be updated on a CSV bulk upload, which it usually can't -- alias, signature, and group assignments are most common.)

Currently the in-between state of the Team Members page in the admin center makes any mass agent management pretty tedious, but the properties above can't be updated in the admin center either.

When searching with user-specific terms like "role" or "type:user," the search results should default to the "users" tab instead of "tickets," which would always have 0 results.

An extra click is a minor inconvenience, but it adds up when making several searches related to user management. At least the "type" operator should dictate which tab is shown when results load.

Is there a way to get this calculated attribute to work like a "real" timestamp, for filtering? It seems like it's not possible to have a "past 7 days" type time filter based on this attribute.