Craig Robichaud

Feature Request Summary: 

Stop flushing closed tickets after 28 days. 

Description/Use Cases & Business impact of limitation or missing feature: 

We do not have a lot of volume, and of what we do have, we are constantly shifting how we look at it, and what insights we need to gleam therein. This is hard to do when access to the ticket is removed less than a month after it's closed, and I am unable to further modify the fields, or even see the ticket in any View to export it.

We are in a highly regulated industry, and your platform is supposed to be HIPPA compliant, so maybe someone can tell me how your other HIPPA compliant customers access their old data, say, for an audit? Do I need to keep my own system of record OUTSIDE of the one we pay you for?

I have an army of tickets "On Hold" because I am not done with them-- Oh, I am done with them in a support sense, but not in an infrastructure sense, and I still want to be able to modify these tickets until I am happy. Being able to access and modify MY OWN DATA sounds a lot like "core functionality" to me.

By never solving or closing tickets, we miss out on SLA automation, solved ticket status reporting and triggers, makes reporting more difficult, etc... This is not really critical at our current size, but we can't scale like this, and will be forced to adopt a new solution down the road.

Other necessary information or resources: 

For your reference, below is a complete list of the other platforms that do allow long term access to ticket data:

• ALL OF THEM; every last platform I have ever worked with ever-- all the way from NetSuite down to Freshdesk-- has allowed me to access, modify, and export all of MY tickets.

I am getting so frustrated with this "hardcoded" limitation. Is it some sort of loadbearing code? Why can this not be changed? I like a light weight instance as much as the next person, and I never had any speed issues with Freshdesk, and I had access to all tickets from the dawn of time. Sounds more like this was always intended to be better for ZENDESK's instance, and not really the end users'.

And only 28 days? That is just not an appropriate ticket lifecycle. Especially for our needs, as we have regulatory obligations that require us to have access to this data, and be able to modify it as well to make corrections-- We are trying to use ZD as a system of record, something I was told you could be. Am I wrong to have this expectation? I know ZD is supposed to be HIPPA compliant at the subscription level my company pays for, so how do other HIPPA regulated companies you work with deal with this issue?

Right now, I have backups in place using triggers to email pertinent info from tickets so that we have at least some long term record, but that's janky and, honestly, shouldn't be necessary. I haven't even closed an actual ticket for either of our brands since before Christmas, because I am worried about losing access to the data; I just set everything to "On Hold" and then lose out on automation possibilities, as well as other reporting based around "Solved" dates.

I keep everything technically open now because not having a pool of tickets to work with, I also find it hard to see the impact of the changes I'm making to our workflows. We're in a transitional/growth stage, so there are a lot of those changes, and sometimes I make mistakes, and need to go back and adjust things, perhaps even on old closed tickets. Honestly, before I stopped closing tickets, I had my head torn off because I had to tell the boss I couldn't provide new insights on old data because ZD didn't think we needed access to that.

We're sort of stuck with ZD for right now because of various integrations, but we absolutely cannot scale without better access to our tickets, and if the company line on this for 3yrs has been that it's hardcoded and removing it will tear the fabric of space and time, then I don't see any other option but to look at other solutions--

And I don't want any feedback or advice from anyone about using reporting to get this info. That's a crappy cop-out answer. I'll be looking into the reporting stuff more for sure, but I don't think viewing, changing, and exporting tickets older than 28 days is a massive feature request. More like standard functionality.

Good point, @.... Right now, we do most customer comms through ZD because we want everything documented on one platform, linked to the ticket interaction, etc. but recently, when I can find a the unique email address for a specific ticket, I will send the email from Outlook and just add that address to the CC; the email goes to the ticket and so does the customer's reply.

If there was an easy way for us to capture the email address that is unique to our tickets, that would solve all of my personal frustrations with trying to do emails from a place that should just be for ticket notes-- Anyone know if that information is readily available in some ticket properties section somewhere?

Great work here, @...! I just wish it wouldn't take such a herculean effort just to have what every other platform considers basic functionality.