Daniel Oakley

@Gary Donoghue I'm a newcomer to this issue/thread (only joined it around three years ago) but yeah even back then there were a number of different... seemingly fairly fundamental 'features' and requests like this one that felt strange and like obvious missing functionality. I can't speak for ZD of course but yeah when I've run into issues like this in the past in terms of products it's normally either the developers being *too* shielded from users or the user advocates (CS team, QA, etc) not having enough say in the direction of the project and in bringing up pain points to those making the decisions.

Luckily a cooouple (like one?) of the big issues we were having trouble with seems to have a solution in testing for some tiers. We've since moved to a different solution but while we were using ZD one of our in-house devs spent time creating userscripts to hackily try and fix up some of these interface issues for our agents -- preloaded the scripts onto the relevant browsers and etc. Wish I still had 'em to share. That helped us out a bit, though yeah it was a dodgy solution. Best of luck!

If nothing else, could we please have a checkbox to prevent displaying the Home icon in the left-hand navbar? Maybe one to also redirect `/agent/` to `/agent/filters` as well?

Even if the full re-architecting of the dashboard and major extending and app stuff isn't on the roadmap or being looked at, something like those two checkboxes would be much appeciated in my case at least.

Presumably some sort of functionality related to this has been added by now, or at least we can pick one default view for agents to see on the dashboard? Apparently not.

Sorry for my terse tone but this is irritating. Not being able to customise the default view in Zendesk is annoying after this many years.

We have a large number of agents, and they should be able to click on the home icon in the top-left and be taken to a home screen accurately representing the tickets that they should be looking at and working on. Right now, that isn't the case, they're taken to some random list (as far as our structure goes in any case, it is basically random for the agents) of tickets rather than what they really need to know and really need to look at.

Sure, we can add a bookmark and tell agents to use that to login, and tell them to ignore that very obvious, intuitive 'home' icon. But we shouldn't have to.

---

On a side note, what I would really prefer for the Dashboard page is to be able to stack multiple views in it. For instance, we have one view where we list VIP tickets, and one view where we list regular tickets. I would like to put the VIP tickets up the top, followed by the regular tickets underneath it, and be able to control flows in that sort of a way.

---

But if nothing else, let us change the home button and where agents are taken to by default to the Views page. Hack it in dodgily with a checkbox in settings, and then later on do the rethinking of the Dashboard page proper so it can be usable by everyone in this thread.

This is a necessary feature. It is required. This feature is needed to construct a decent knowledge base. This is something that is making me (and us) reconsider using Zendesk for our new enterprise support desk deployment.

Solve this issue with a proper rewrite of the knowledge base backend, solve this with a quick hack by writing it so that if multiple sections are selected the system automagically creates multiple articles with a flag saying "Keep this article synced with article ID 123423" on them, and the changes to any articles in the group get synced to the other articles in the group, anything, the functionality just needs to be there. Hell, if you do that second one or some other hacky solution, you can even convert it to use the proper fixed method later once the thing gets rewritten to support it! Happy faces all around!

I know code is hard, but this is a basic feature of knowledge base systems, and is required and necessary to build a decent help center using your service.

This and the multiple levels issue are two things where I'm honestly quite shocked that they still persist after this length of time. They may require reworking the backend, they may even require some fairly extensive reworking, but they are both necessary for any decent knowledge base system out there today. Please escalate the priority on this issue to let us help our customers in navigating our knowledge bases.