Recent searches
No recent searches

Konstantin
Joined Apr 15, 2021
·
Last activity Aug 04, 2023
Former Certified Zendesk Support Administrator; Still active with the community.
Following
0
Follower
1
Total activity
93
Votes
3
Subscriptions
35
ACTIVITY OVERVIEW
BADGES
ARTICLES
POSTS
COMMUNITY COMMENTS
ARTICLE COMMENTS
ACTIVITY OVERVIEW
Latest activity by Konstantin
Konstantin commented,
Instead of using the "Ticket Status" and "Updated Via" options, try using the "Ticket" option, as this allows for the "is updated" parameters. So your Conditions would look like:
Assignee | is | {agent's name}
Ticket | is | Updated
You may also want to add the "Current User is not Agent" option, to ensure that only your customers/end-users are the only ones triggering this rule...unless you want other Agents' updates to trigger this policy, then you would want it to say "Current User is not Assignee".
I hope this helps.
~Konstantin
View comment · Posted Aug 04, 2023 · Konstantin
0
Followers
1
Vote
0
Comments
Konstantin commented,
Chad Susa (Gravity CX - Zendesk Partner),
That placeholder works for all Custom Fields, no matter what type of Field they are. The main take-away about placeholders, if you use this for Drop-Down Fields, you will get their Tag identifier versus their "label"; For the "label" (i.e. user-friendly value), you will want to use ticket.ticket_field_option_title_. One other note when using the "label" placeholder option, if you have nested (i.e. drop-out) values in your Field options, you will see the value displayed as such:
Example
Field is called "Support", with the following options:
- Access::Can't Login
- Access::Portal Unavailable
- Device::Not Powering On
- Device::Replacement
- ...etc
This is how you would see your placeholder values, when they are populated. Just in case, placeholders can be used in:
- Automation policies
- Trigger policies
- Macros
- Inbound and Outbound API Calls (via Webhooks)
I hope this information helps. If there is something more specific, please provide your Use Case and I will try to help answer your question/s the best I can.
~Konstantin
View comment · Posted Jul 19, 2023 · Konstantin
0
Followers
0
Votes
0
Comments
Konstantin created a post,
Tags are extremely powerful in Zendesk, and are used for all sorts of things, from API calls to Explore report generation. However, you can find your Tags section within tickets sometimes getting too lengthy. Here are some ways to make your tags work for you, while limiting the amount of characters needed for them.
Ticket Fields
For your ticket Field options, it is best to limit your tags to roughly 3-5 characters per Field/Sub-Field (i.e. using the double colon to create drop-out options). For example, you have a Field (Support Issues) with the following options:
- Device Issue
- Network Issue
- Portal Issue
You would want to create your Tags as such:
- sup-iss_dev_iss
- sup-iss_ntwk_iss
- sup-iss_port_iss
Doing this not allows you to properly identify the Field and the associated option, but also helps with keeping the number of tags that are applied to a ticket. The other item that assists with limiting tags on tickets, is using Conditional Fields on your Forms, as this will limit what Fields are visible on a ticket, thus limiting the Tags listed.
Macros
When utilizing Macros to add Tags to tickets (whether for reporting or to assist with ticket Automation), it is best to utilize the same formatting structure used for Field Tags, but using the "mcr" in place of the Field name/value. For example, you need a Macro to add the Tag "jump_sensor", your Tag in the Macro should be set to:
- Macro Name: Set "jump_sensor" Tag
- Action: Add Tag "mcr_jump_sensor" (without quotes)
This will help you to identify that this came from a Macro versus being applied via a ticket Field or Automation/Trigger policy.
Automation and Trigger Policies
For these, use the same format as Macros, but swap out "mcr" for the following:
- Automation policies: "auto_" (without quotes)
- Trigger policies: "trg_" (without quotes)
Again, just some helpful ways to make Tags work for you, while limiting the amount of space they take up within your tickets.
~Konstantin
Posted Jul 17, 2023 · Konstantin
1
Follower
5
Votes
2
Comments
Konstantin created a post,
Brands are normally thought of as a way to allow companies to offer customers ways to reach specific support teams; However, Brands can also be used to support your employees.
See Setting up multiple brands for details on configuring Brands.
For example, if you are looking to have employees submit tickets to specific internal teams, but you don't want them going through the process of manually generating tickets from the Agent view, you can setup a new Brand (with Help Center enabled). From there, you setup any necessary Fields, Forms, and Triggers (i.e. ticket routing rules), and ensure you have the "Agents can manage requests from Help Center" option enabled.
Example Use Case
You have your IT team (they support employees only) and your Customer Support team in the same instance, and want employees to submit tickets via the Help Center (Guide) portal.
Start by creating a new Brand that will be for your IT tickets to be submitted through. Once you create the Brand, you will need to enable the Help Center (Guide) portal, as this will allow individuals to submit tickets.
Once you have your Brand setup and the Help Center available, you will want to create your ticket Fields and Form/s that IT will need to support all employees. For your Form/s, ensure it is only visible to this new Brand, while ensuring the other Form/s are only associated with your Customer Support Brand. Also ensure your IT Form/s are set to be visible in the portal, otherwise no one will be able to access them.
Once all that has been completed, you will then need to enable the "Agents can manage requests in Help Center" option; This allows everyone (employees listed as Agents and those listed as End User, not just those listed as End User) to be able to access the Submit a Request button. Now just capture the URL to the new Help Center portal, that way your employees know where to go to submit their requests.
NOTE: If you need to limit ticket visibility, you can set all Roles to only allow Agents access to their assigned Groups, or you can set your IT Group to Private, so only those set as Requester or CC on the ticket will have access.
If for some reason you have strict compliance policies you have to follow, then I recommend having a second instance setup for your internal teams that need to be fully segregated from all other Zendesk users.
~Konstantin
Posted Jul 17, 2023 · Konstantin
1
Follower
5
Votes
3
Comments
Konstantin commented,
See comments in the "Why can you not CC a support address or use in side conversations?" article.
Basically, you will need to add your email addresses as End Users within your Organization. To clarify, you will need to add your company (if it doesn't already exist) as an Organization, then add the emails as users of the Organization. From there, manually verify the email addresses and you should no longer see those go into the Suspended Tickets queue.
~Konstantin
View comment · Posted Jul 17, 2023 · Konstantin
0
Followers
0
Votes
0
Comments
Konstantin commented,
To go along with what Ahmed Zaid said, you will also need to select the checkbox next to the "Enable agents to manage requests from help center" option, otherwise only those set as End Users will be able to access the Guide portal side.
As a note, my company started off with this method, but then moved to having two instances, as we required some teams to have access to multiple teams' tickets (without being assigned to those Groups), while some teams needed to remain localized to just their Groups. Since some of the localized teams (like Procurement, HR, and Finance) couldn't have other teams seeing/accessing their tickets (Compliance/Security requirements), we moved them to their own instance and turned that Help Center portal into the "Employee Support" portal.
~Konstantin
View comment · Posted Jul 17, 2023 · Konstantin
0
Followers
0
Votes
0
Comments
Konstantin commented,
For my company, we labeled our Trigger categories as such:
- 01 - Ticket Routing
- 02 - Ticket Actions
- 03 - Ticket Notifications
This was due to what we considered a priority. For us, the priority was ensuring tickets were routed to their proper teams. From there, ticket updates (i.e. automatic actions) were next on our list, with ticket notifications being least (necessary and valid, but not as high a priority).
Basically, it comes down to what you need to be top priority, and creating a grouping structure that helps you best organize them. This functionality was definitely a huge "step up" from the previous behavior, of just a large list.
~Konstantin
View comment · Posted Jul 17, 2023 · Konstantin
0
Followers
0
Votes
0
Comments
Konstantin commented,
@...,
Thanks for the quick response on this, and for providing some insight into some Roadmap work in progress; I look forward to seeing what comes out.
~Konstantin
View comment · Posted Jul 17, 2023 · Konstantin
0
Followers
1
Vote
0
Comments
Konstantin created a post,
This feature request is for adding the ability to have sub-grouping for Triggers.
USE CASE
Today, I am currently using the grouping for my Zendesk Triggers as such:
- 01 - Ticket Routing
- 02 - Ticket Actions
- 03 - Ticket Notifications
Since our teams are growing, it would be nice to add sub-grouping to allow for better sorting and identification of Triggers; The format would look like:
- 01 - Ticket Routing
* Support
* Provisioning
* etc... - 02 - Ticket Actions
* Support
* Provisioning
* etc... - 03 - Ticket Notifications
* Support
* Provisioning
* etc...
~Konstantin
Posted Jul 06, 2023 · Konstantin
1
Follower
2
Votes
2
Comments
Konstantin commented,
I am also interested in the Jira sidebar app being able to connect to multiple Jira instance.
USE CASE
My company was bought by another company; The parent company and several of the children companies all have Jira. With our Support team needing to communicate with teams across various Jira instances, it would be nice if they could use the sidebar app to accomplish this. If not through a single sidebar app, then possibly have the ability to install multiple instances of the sidebar app to connect to the various instances, and have a way to label each sidebar app with the instance it is connected to.
~Konstantin
View comment · Posted Jul 06, 2023 · Konstantin
0
Followers
0
Votes
0
Comments