mfg

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)

As an admin, I am unable to use the status category solved for a custom status without it also being swept up by the default solve>close automation. The default solve>close automation should be editable to use either [status category][solved] or use the condition [status][solved]  BUT NOT [custom solved]

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

We want to track some tickets that are effectively solved and allow them to be written to - ie not read-only. We are using a custom status for these tickets. The default solve>close automation closes tickets in the solve status category, not just with the standard solve status. 

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)

Currently, applies to any use case where resolution time is an important metric. To accomplish our goal, we need to categorize the custom solve in the pending category.

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

To accomplish our goal, we need to categorize the custom solve in the pending category. We could also update the standard [status category: solved] automation to some way out number like closing in 365 days instead of 4, then adding a new automation that closes [status: solved] after 4.

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

In the same way you can edit the time-since-solved, allow the default solve>close automation to be edited from using [status category] as a condition to just [status].

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)

Update custom status configuration process so that either the default form config is for not all forms (similar to which brand a form applies to), or so that can more quickly be removed from forms by admins. Also, a setting to restrict which groups can access the custom statuses would be helpful.

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

Removing custom statuses from forms takes a long time when you have a significant number of forms. When you want to restrict usage of those statuses, you need to review each form individually to remove them.

Agents are able to select statuses that may not apply to them and may cause problems with reporting, views, triggers, and automations - negatively impacting our customers as well.

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)

Whenever adding custom statuses

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

Clicking through each form over and over

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

Set the initial form availability to ‘none’ then add the statuses to applicable forms individually. Also, update the ‘ticket statuses by form’ page to allow you to use CTRL+click to open each form in a new tab.

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)

Add array of objects to the effect of:

"notification errors":[
	{"recipient": [user ID],
	"identity": [user email],
	"notifications": [a1b2c3,d4e5f6,g7h8i9]
	}
]

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

In order to collect delivery errors from the email endpoint, you need to loop through each recipient on each notification. In the case of tickets with multiple followers and CCs, and numerous notifications, this can become an intensive process.

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)

I'm currently trying to pull email errors from thousands of proactive tickets with multiple recipients each. This is a regular proactive tickets campaign and this would streamline each outreach going forward.

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

Looping each ticket, each notification, each recipient to identify bad email addresses.

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

Either include a “notification errors” array on the ticket object, as a query parameter on the email end point, or some other common end point.

I noticed that there is a system-added tag in Explore and in ticket histories ‘system_email_notification_failure’

Does this capture tickets with a failure? In other words, can I use this for accurate reporting? 

Are there tags that provide additional details on the 5xx errors? 

A few questions:

• Does an ‘approver’ need to have a paid seat? 
• Is ‘approver’ a new role?
• How does this differ from a side conversation? 
• Does it use a separate / new API endpoint?

This has been really effective for our primary use case, but I got a recent request to hide a custom field that needs to be editable by the end user via a pre-fill URL.

Is it possible to use something like your original

      document.querySelector('.request_subject').style.display= "none";
 

For the custom field?

      document.querySelector('.custom_field_123').style.display= "none";
 

The label can be hidden, but I haven't been able to hide the text entry portion.

As an admin, I would like to require fields when agents are submitting tickets that match when an end user submits the same ticket. ie. If required for end users to submit a ticket then they should be required for an agent to submit the ticket.

How do I enforce required fields when agents submit tickets?

I recently had an agent test a form and they used their agent email to do so. When testing as an anonymous user all required fields threw errors when they were not selected as expected.  The field requirement is at the field level, there are no conditions to override the requirement.

When they put their email in the email field using an incognito window (they weren't logged in) they were able to submit the form without completing any fields beside the description field. I have been able to replicate the error for both agents and light agents.

To some extent this may be a corner case when it comes to external forms. However, when it comes to internal forms this is a problem especially where there is a legal acknowledgment / attestation involved.

Adding a multiple template feature would be helpful and significantly reduce the complexity of accomplishing this. Alternatively, the complexity of this may be less than it seems. Is it possible to get a recipe for accomplishing this?

Experimenting with the new email error feature via API and curious how far the data goes back. I'm using the api/v2/email_notifications.json?filter[ticket_id]=623 end point.

Since this is a new feature, how far back to email error history go? I assume it goes all the way back for each ticket but would like to verify any constraints on reporting.

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)

Add updating skills as a condition for triggers

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

We need to generate end user use case specific notifications when a ticket's skills are updated. 

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)

We currently make minimal use of skills-based routing due to this issue.

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

Adding skills via a separate trigger based on a different condition.

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

Better support for implementing skills-based routing including but not limited to exposing skills as conditions for triggers