Jason Fouchier

Hey @...,

Yes, this is only an issue with side conversations. Regular ticket communication works just fine.

Thanks,

      Jason

Hey Everyone,

      Has anyone come up with a way to deal with bounce back emails as of yet? This is still something we are struggling with.

Thanks, 

      Jason

Hey All,

      First off, I wanted to thank all the people who post the questions, answers, tips, and tricks. The information I gathered from the community was like gold and so helpful along the way.

      So, after a disappointing and frustrating stretch of trying to customize the requests list page, here is my two cents on the issue. 

     All I wanted to do was add the group a ticket was with, who it was assigned to, and make the drop-down menus multiselectable. I was disappointed to learn that none of that was available as an available customization and that what was possible needed the duplication of data to custom fields paired with extra API calls, Javascript and a lot of head scratching. Not being able to do simple things listed above without having to make a patched together workaround is simply frustrating. 

     This is just another disappointing roadblock in the customizability of what could be and should be a great feature to help keep the lines of communication open. It is a touch baffling that you would have such a useful tool in a system that is generally pretty customizable, yet the portal/request list page (which in my opinion should be the most customizable) is devoid of any real/tangible customization. In my particular case, letting the end user see what group and assignee their ticket is with is very important to the direction we are headed as a company in regard to communication with our users. Things like using a templating language to make the code cleaner was a great idea, basing it off a language that is super customizable like handlebars and then stripping away all the customizability is not cool. I understand the statement of "We can't let users run their customized code on our servers", this is a legitimate concern. My argument is that it doesn't have to be one way or the other, you can't tell me that there is not a great compromise in the middle of that void that we can all live with. Now, I know I have just a high-level understanding of all the problems associated with this issue, along with the fact that I am one of the users wanting more options for customization. Not to forget the thousands of hours of meetings discussing the best roadmaps for software and not truly knowing what users are going need or think the need, or how they want to use the product (which may or may not line up with your vision for your own product). I guess I just feel like the compromise would be easier than not having the customizable options. My apologies for the rant, I will step down from my soapbox now 😉. 

Thanks,

     Jason Fouchier

@Yamile, that looks good. I used something similar for some of my custom fields as well. My current issue is that "group" and "assignee" are not available on the requests list page. This leads me to have to make extra triggers to duplicate data dumped into what is essentially a duplicate field just to be able to bring the needed data into the table for my users to be able to view. It's super frustrating that something like "requester" has a helper available but "group" and "assignee" are not.

     Nevermind, the group and assignee are not available datasets on the requests list page. A little more reading and research on my part would have been useful. I do think that it is pretty ridiculous that these are not available to display on the request list page as this can be important to an end user depending on what type of business you are. We are in a business to business scenario and we would like our end users to be able to see the group and assignee of their ticket. This would really help in the flow of our communication to our partners and allow them to have a better understanding of how a ticket journeys through our system. As this page currently sits, it is a massive headache to show our partners the needed information and really stunts this portals growth potential.

Thanks,

     Jason Fouchier

     I have been able to pull my custom fields into the table using this method, the only one I am having issues with is the system field of "group". I either get nothing, or it posts none even if I know that the ticket is in a group. Am I having issues because it is a system field? 

Thanks,

    Jason Fouchier

I see that we can't change the statuses, but is there anyway to remove what we don't want people to see? I have a group of users that need visibility on the open tickets of an organization, but they do not need to see the "awaiting response" status. Is this at all possible?

Awesome, thank you for the fast response Brett. That was what I was looking for, I just wanted to make sure it was going to email the agent and not the end user. Thanks again.

I have a quick question about the "current user" in regards to triggers. If I have a trigger that looks for open tickets containing a certain tag and where the current user is not the requester. If the action is to email the current user, will it email the end user or the last agent to update the ticket? Thanks in advance for any help. See screenshot below -