Views are a way to organize your tickets by grouping them into lists based on certain criteria. For example, you can create a view for unsolved tickets that are assigned to you, a view for new tickets that need to be triaged, or a view for pending tickets that are awaiting response. Using views can help you determine what tickets need attention from you or your team and plan accordingly.
Many support teams use views to guide the workflow by requiring agents to address tickets in one view first and then others in a specific order. Views can also mirror the support structure you've created. For example, if you provide different levels of service for different customers or manage escalation using a tiered support group structure (Level 1, Level 2), you can create views for each of these scenarios.
This article covers the following topics:
About view types
Zendesk Support includes the following types of views:
- Default views. There are a number of pre-defined views created when you open a Zendesk Support account. You can deactivate or edit most of these views; however, the Suspended tickets and Deleted tickets views cannot be edited or removed from your list of views.
- Shared views. Administrators can create views that are available to all agents or to all agents in a specific group. The first 12 shared views are accessible in the Views list (
) .
- Personal views. Agents can create views that available to themselves only. The first 8 personal views are accessible in the Views list (
).
Adding views
Agents can create views for their own personal use. For agents in custom roles, views permissions depend on their custom role setting. Administrators can create personal views, as well as shared views for use by multiple agents.
Community tip! Graeme shares real-world best practices for setting up and using views in this community tip, Views best practices.
- Click the Admin icon (
) in the sidebar, then select Manage > Views.
- Click Add view.
Alternatively, you can clone a view to create a new view based on an existing view (see Cloning a view). Agents in custom roles might not have the option to add a view, depending on their permissions setting.
- At the top of the page, enter a name for the view.
- Enter a Description for your view.
- Select an availability option to determine Who has access to the view:
- Any agent, available to all agents.
- Agents in specific groups, available only to agents in the groups specified. You can enter one or more groups in this field. If you enter mulitple tags, hit Enter between each tag.
- Only you, available only to you as a personal view.
- Under Tickets must meet all of these conditions to appear in the view, add the conditions to define this collection of tickets (see Building view condition statements below).
You can also add conditions under Tickets can meet any of these conditions to appear in the view.
- Click Preview to test the conditions.
- Set the formatting options:
- Drag the view Columns into the order you want. Click Add column to add up to 10 columns.
Status is always shown in the view before the columns. You don't have to add it manually to the table. Multi-select fields are not supported in table columns.
- Under Group by, select the ticket data field you want to group the tickets in the view, then select Ascending or Descending.
Tip: If you select Request date from the Group by dropdown list, any settings you change in the Order by dropdown list will not be applied.
- Under Order by, select the ticket data field you want to use as the default data to order the tickets in the view, then select Ascending or Descending.
- Drag the view Columns into the order you want. Click Add column to add up to 10 columns.
- When you are finished, click Save.
The view is created.
You can manage your view (edit, deactivate, and so on) on the individual view's page, accessed from the Views management page. See Managing your views.
Building view condition statements
As with the other business rules, you select collections of tickets using conditions, operators, and values.
You must have at least one of the following ticket properties in the Meet all of the following conditions section:
- Status
- Type
- Group
- Assignee
- Requester
Some conditions may not be available, depending on your plan.
Condition | Description |
---|---|
Ticket: Status |
The ticket status values are: New is the initial status of a newly created ticket (not assigned to an agent). Open means that the ticket has been assigned to an agent. Pending is used to indicate that the requester has been asked for information and the ticket is therefore on hold until that information has been received. On-hold means that the support request is awaiting a resolution from a third party—someone who is not a member of your support staff and does not have an agent account in your Zendesk. This status is optional and must be added to your Zendesk (see Adding on-hold ticket status to your Zendesk). Solved indicates that the customer’s issue has been resolved. Tickets remain solved until they are closed. Closed means that the ticket has been locked and cannot be reopened or updated. When selecting a status, you can use the field operators Less Than and Greater Than to specify a range of tickets based on their status. New is the lowest value, with values increasing until you get to Closed status. For example, a condition statement that returns only New, Open, and Pending tickets looks like this: Status is less than Solved. |
Ticket: Form | Select the required ticket form.
For more information on ticket forms, see Creating ticket forms to support multiple request types. |
Ticket: Type |
The ticket type values are: Question Incident is used to indicate that there is more than one occurrence of the same problem. When this occurs, one ticket is set to Problem and the other tickets that are reporting the same problem are set to Incident and linked to the problem ticket. Problem is a support issue that needs to be resolved. Task is used by the support agents to track various tasks. |
Ticket: Priority |
There are four values for priority: Low, Normal, High, and Urgent. As with status, you can use the field operators to select tickets that span different priority settings. For example, this statement returns all tickets that are not urgent: Priority is less than Urgent |
Ticket: Group | The ticket group values are:
Group name is the actual name of the group that is assigned to the ticket. |
Ticket: Assignee |
The assignee values are:
Additional value for views:
|
Ticket: Requester |
The requester values are:
Additional value for views:
|
Ticket: Organization |
The organization values are:
|
Ticket: Tags |
You use this condition to determine if tickets contain a specific tag or tags. You can include or exclude tags in the condition statement by using the operators Contains at least one of the following or Contains none of the following. More than one tag can be added. Press Enter between each tag you add. |
Ticket: Description | The description is the first comment in the ticket. It does not include the text from the subject line of the ticket.
If you are using the Contains at least one of the following or Contains none of the following operators, the results will consider words containing part of the entered search terms. For example, using "none" for this condition will return (or exclude) ticket descriptions containing "nonetheless". The description condition also pulls data contained within the HTML and the original source of a ticket. |
Ticket: Channel |
The ticket channel is where and how the ticket was created. The contents of this list will differ depending on the channels you have active, and any integrations you are using. For more information about the channels you can configure, see About Zendesk Support channels. For a list of the available ticket channels, see How are ticket channels defined across Zendesk? |
Ticket: Received at | This condition checks the email address from which the ticket was received. The ticket can be received from a Zendesk email domain such as sales@mondocam.zendesk.com, or from an external email domain such as support@acmejetengines.com. The external email domain must be set up as described in Forwarding your incoming support email to Zendesk or the condition won't work. |
Ticket: Satisfaction | This condition returns the following customer satisfaction rating values:
|
Hours since... | This condition allows you to select tickets based on the hours that have passed since the ticket was updated in the following ways:
|
Ticket: Custom fields | Custom fields that set tags (drop-down list and checkbox) are available as conditions. You can select the drop-down list values and Yes or No for checkboxes. The following field types aren't available as view conditions: Text, Multi-line, Numeric, Decimal, Credit Card, Regex.
Note: Each custom checkbox field must have an associated tag. Otherwise, when you create or edit a view, it won't appear as an available condition.
|
Ticket sharing: Sent to | Checks whether a ticket was shared to another Zendesk Support account via a specific ticket sharing agreement |
Ticket sharing: Received from | Checks whether a ticket was shared from another Zendesk Support account via a specific ticket sharing agreement |
Cloning a view
You can clone an existing view to create a copy that you can modify and use for some other purpose. You can clone a view from the Views admin page or from the views list.
If using custom roles, agents will need to be permitted to add and edit personal, group, and global views (see Creating custom agent roles). Agents will receive an error message if not given the permission.
To clone a view from the Views admin page
- Click the Admin icon (
) in the sidebar, then select Manage > Views.
- Hover your mouse over the view you want to clone, then click the options menu (
) and select Clone view.
- Modify the title, conditions, formatting, and availability as needed.
- Click Save.
149 Comments
Hi Janine,
The subject line of a ticket is considered a separate field from the Ticket: Description field which is why that information is not included. That being said, you can use Triggers to look for keywords/strings and then apply a certain tag.
Afterwards you can configure your views to show tickets that contain that specific tag. I've attached a couple of example screenshots below:
Trigger:
View:
Hopefully that gets you relatively close to what you're looking :)
Is there a way to add an additional sort? I am using Group By and Sort By, but I could use an additional Sort By value to make the view really useful. A work-around would be fine, I can't figure out any way to have multiple layers of sorting in a view.
Thanks!
Allison
Hi Allison -
There's not a way to apply two Sort By filters, but once you're within the view, you can click on any column to sort further by that column. Would that help for your workflow?
Nicole,
Thanks for getting back to me so quick.
When I click on the column it clears all the previous grouping and ordering that I established in the view setup. So I still can't get that third level of sorting. Am I doing it wrong?
Hey Allison,
We may be talking past one another. :) To make sure I'm clear on what you're trying to do, can you give me an example?
I'm trying to create a view that shows our inbound shares and displays the instance that shared the ticket with us. Is there a way to do this?
Example: We receive shared tickets from X.zendesk.com, Y.zendesk.com and Z.zendesk.com. When the view is used, one of the columns should be whether the ticket came from X, Y, or Z.
When you set up the initial conditions for the view, you can select "Ticket sharing: Received from" as a condition, so the information is definitely there. How do we display that information in the actual view?
Thanks!
Beth
Hi Beth,
I did some testing on my end and it doesn't look like there's a Ticket Sharing column you can add to the view itself unfortunately. That being said, you could use a custom drop-down field as a column within your views. This would require some additional configuration on your end but what you could do is create a Ticket Sharing custom drop-down field and set up some Triggers that automatically set the field value based on the Ticket sharing: Received from condition.
I realize this isn't the easiest solution but it should hopefully get the job done for you.
Let me know if you have any questions regarding the above :)
Hi guys,
Under "Views" > Edit > "Formatting Options" there is a "Latest update" token that displays the date as: Month / Day / Time.
Is it possible to change its time format to "### Days Ago"? Or any way to create a new token for this custom "View"?
Thanks!
Hi
Is it possible to make the view regularly update on the amount of tickets? We are a small upstart company, so we do not have that many tickets coming in. But I would like to have the "all unsolved tickets" open on my second screen, so I can react when tickets are coming in. But at the moment I have to refresh the page for the tickets to arrive in Zendesk.
Hi,
I have a view for my team that enables them to see Recently updated open tickets. However this is limited by a fact that, as far as I can find, it is only possible to add the role of the Updater, but not the name. So, in a scenario where there are Collaborators to the ticket, or multiple agents are contributing to solving the ticket, agents still have to open the ticket to see who the was the person who provided the latest comment.
Is there a possibility to include updater name in a view or any viable workaround?
Hey Janis,
The view can only display the updater role and not the name of the updater unfortunately. That being said, if you hover over the ticket in your view it should show the recent updater as well as their update. Sample screenshot below:
Apologies for not being able to provide another alternative at this time :-/
Hey Brett,
This is a good tip, thanks, we will be using it.
Is it possible to exclude a single group from seeing a View? For example, if we want "recently solved" to be available to all groups except one, is this possible? Or, do we need to clone the view so we have one copy for each group?
How could I create a view that displays only tickets with a task that is due?
How does a "due" task actually influence the tickets? Currently I cannot see any optical effect on tickets that have a due task at all. Are they just two fields that actually do nothing than being filled by the user?
I want to create two views like: "My due tasks" and "Team due tasks" where only due tickets are shown and all other tickets are hidden which have a due date in the future.
Hey Thomas,
If you'd like to create a view to show upcoming tasks you could use conditions similar to the following screenshot:
You can also add the Due Date column to your view for easier tracking. As for showing your due tasks in one view and team view tasks in another view, you can use the Ticket: Assignee > is along with the Ticket: Group > is conditions.
I hope this points you in the right direction!
Hi Brett!
We're trying to build a view that helps us see tickets where:
Customers (requesters) have sent us a response more than 24 hours ago but we have not yet responded (public reply). Any tips on the rules I would build?
This is what I tried but it seems a bit off!
@P Kelly I believe if you just remove the Hours since assignee update that should get you the results your looking for. If your agents are setting the ticket to Pending status when they respond then once the requester replies the status should switch back to open. You could also add the Hours since open condition to your view.
Hope this helps!
Thanks for the prompt response Brett!
Happy to help :)
Good Afternoon,
Is it possible to hide all views from agents? What I'd like to accomplish is hide the views as we have tickets automatically assigned via the "Playlist App" and do not want agents to see views rather just work via automated.
Hi Juan,
Yes! You have to go into each View, scroll to the bottom and select Me Only (or perhaps restrict to a Management group?)
The other thing I would double check is if you have Enterprise, you might want to go into the Role associated with Agents that you'd like to restrict and ensure they don't have more than "Play views only" permission. I'm thinking in case they have a personal view set up already?
Where can I find documentation on all of the undocumented placeholders? It appears that Zendesk has a few that aren't mentioned in the placeholders reference.
For instance, the following is not documented anywhere:
This placeholder outputs "Pending tickets" in any field where placeholders are allowed. What else is there?
I do not find Add View
Indy Jordan You either need to scroll further to the right, or you don't have permission to add views. It's in the upper-right corner next to the AZ sort button.
Hi there!
We have long had our views set up so that email tickets are separate from Voicemail tickets, so agents on Voice can handle callbacks from one view and agents on email can power through emails without voicemail tickets. However, I'm finding an issue with the limitations of how we can achieve what would appear to be a simple separation.
Basically, if we use channel as the restriction that separates - i.e. channel is not Voicemail for the email view, and channel is voicemail for the voicemail view, we find that email threads created from a voicemail ticket, which happens somewhat frequently in our business, end up in the VM view rather than the email view.
I thought of creatively solving this by using Privacy: Has Public Comments instead of channel - if it has public comments, it should end up in the email view, and if channel is VM + it does not have public comments, then it should stay in the VM view. However, this is creating a separate issue where if a customer forwards our support email and another person replies, it creates the internal note flagging issue since they weren't cc'd, thus no public comment happens and those tickets do not make it into a View to be responded to.
The no-public-comment issue is less frequent than email threads from VM tickets, so we went with this option, but in our business we work with teens and parents, so it is still relatively common for the teen to forward the support ticket to a parent, who follows up and ends up stuck in internal notes with no reply. I just found 17 of those such tickets, with upset parents who never heard back from us on their issues.
So, has anyone found a better creative solution? It's like I need more if/then statements on a granular level - like if channel is VM, it needs public comments, while all other channels do not require public comments. Since we cannot control it by subject text, that is also frustrating, as email threads from VMs change the subject from "Voicemail from: ___" to a follow-up subject line, but since that's not an option I am at a loss of the best way to set up these views to be fully effective the way we need them.
Hi Montana,
Could you give me an example of such a ticket which shows in the wrong view?
Also please post screenshots of both view-settings so we can figure that out together.
Cheers,
Hi Andreas Schuster thanks for the response! I've been thinking about this and I realized that the best option may be controlling it with phone groups vs email groups - restricting the VM view to channel VM with Phone groups, but not restricting the email view by channel and instead using a trigger to make a VM with a public reply set to the email group, and using those groups as the filter for the email group. This is just a more challenging solution due to the sheer amount of groups we have across our brands and how incorrectly things will sometimes route or be assigned, but I'm thinking it might be my best option to sort out.
To answer your question for my above scenario:
Due to some privacy concerns with the multiple brands we serve, I can't publicly post screenshots. However, here's two different settings I have for two of my different views that we use to restrict VM vs Email (i have not included unnecessary additional parameters):
For a view that restricts by channel, and where we see email threads started from VM tickets stay in the VM view instead of moving to the email view:
VM View
All Conditions:
Ticket: Channel is Voicemail
Ticket: Group is Phone
Email View
All Conditions:
Ticket: Channel is not Voicemail
Ticket: Channel is not Phone call (Incoming)
This setup prevents emails sent from VM or Phone tickets from going to the Email View since the channel is VM/Phone to begin with.
For a view differentiation that restricts by public comment (since VM and Phone tickets do not inherently have a public comment until the email thread is kicked off):
VM View
Any Conditions:
Ticket: Channel is Voicemail
Ticket: Channel is Phone call (Incoming)
Email View
All Conditions:
Ticket: Privacy has public comments
Ticket: Group is (current user's groups)
This setup allows email tickets that start as a VM/Phone channel to end up in the Email view since they now have public comments, but prevents a ticket that only has internal notes (like non-cc'd responders to a ticket) from arriving in the Email view.
Does this make sense?
Hi Montana,
Even though, I'm not a voicemail expert (never used that feature) i think i could have found a reason.
https://support.zendesk.com/hc/en-us/articles/115015611647-Trigger-conditions-and-actions-referenceThe Ticket channel could maybe still be voicemail, even though it's an e-mail based ticket.
I think it's best to contact Zendesk Customer Service about this one, since they are able to check your account, I can only make assumptions here I'm afraid.
Cheers,
hey Andreas Schuster I appreciate the help! I actually figured out how to make a trigger to put a tag on these specific tickets that were being impacted, and then used the tag for the view. So now I have restricted my email vies with the Any Conditions: Has Public Comment OR has the tag, so it captures public replies on voicemail channel tickets + forwarded threads with no public reply (where the tag will now live).
That would have been my alternative solution as well :)
As soon the filtering gets messed up it's always a good idea to use manually defined tags since Triggers have even more filter options.
I'm glad you found a way.
Cheers,
PS: If you create a custom drop-down field (which is based on those two tags) you can give your agents a way to quickly switch the ticket type, in case you would still have issues with tickets in the wrong view.
Please sign in to leave a comment.