[49771] Show/Hide tickets from the Customer Portal

[Aycorn]

What is the current impact of not being able to show/hide specific tickets?

We currently cannot communicate to our clients directly through the DD portal on tickets that are on particular boards. These boards are NOC/SOC/Maintenance boards which are hidden from clients due to the sheer number of alert-style tickets that come through these boards. We don’t want our clients to see them as it creates confusion and they don’t actually need to see 90% of them.

What value would this functionality provide your team?

We would be able to communicate directly with client contacts regarding these tickets through the DD portal - the same way that we do with every other ticket. At the moment, we are needing to communicate on these tickets through email, making things slow and clunky.

What value would this functionality provide your customers?

Similar to above, we are needing to handle these tickets differently from a standard Support ticket. It creates confusion as we are trying to promote the portal and get clients to use it rather than emailing us, however with these tickets we are needing to email. It’s very confusing from a clients perspective.

How would you envision your team managing the hidden flag of each ticket?

By API. We would capture any tickets on this board in a certain status (eg. Waiting on client) and then set the flag automatically to make the ticket visible in the portal. There could also be a checkbox in the GUI for Techs to be able to manually set it.

If there could be a setting for each board to hide or display tickets to customers, that would be great too, then we can set these boards as hidden by default - otherwise we would have to use the API again to set the tickets as hidden by default.

[Nness]

The recommendation for this is to move ticket to a board that contact can see. I don't think we want to introduce such flag of any sort.

[Nness]

If a ticket need conversation, then it means it is worse the effort to move to a proper board/queue

[Nness]

When talking about API to automate the flag, why not automate move the ticket to a board that contact can see? Either use existing board or create a board specifically for this purpose. So any ticket moved to the special board means it was from notification board.

[cstewartpit]

Hi Nness,

We can't use a different board as the ticket alerts come from 3rd party integrated systems (N-Able, Liongard etc). These tickets are reliant on the board and moving the ticket breaks the integration, not to mention issues with SLA's, billing, reporting etc that are all board reliant.

[Nness]

The notification board that is specifically for labtech, N-able and Liongard are our least interest topic in past 10 years of development meeting. At least from DeskDirector development team's opinion, such integration was wrong in first place, where application insights is best fit to consume event and based on the frequency of the event to raise issue ticket, rather than use ticket to log event.

During the meeting, we have not once but all the time, Warwick want us to automatically detect notification board and stop sync tickets from that board.

Thus the decline above was executed without further discuss. Unless the owner of our company change his mind, else our development team will stay as what we have always agree to.

The sync tickets from notification board was one of the biggest burden that we are unable to display tickets that's older than 6 months, due to amount of junk store within our database storage. So, we have to actively clean out tickets that is older than 6 months. Else we will be able to easily keep last 1~3 years of tickets without any issue.

[cstewartpit]

I don't disagree with you - the way that most 3rd party apps integrate with CW is very rigid and hard to work with - but we still have to work with them for the moment and I still have the issue at hand.

What if only tickets with the 'visible' flag were synced to the DD database? What other suggestions do you have apart from creating another board? I feel like there's a gap here that surely other DD partners are facing as well.

[Nness]

You might got my message wrong. It is not whether I agree or disagree with you. What I am saying is from product management point of view, whether to consider any feature it is related to both side of interest. In business which we call as win win situation. In this case, you are the first one raised such issue where we have countless of request asking to show historical tickets that more than 6 months old.

Thus, which one can bring more revenue it is pretty clear. Thus, due to the possibility in the future that we might sacrifice notifications board to allow store more tickets, we don't want to hold more contract on it.

At current stage, I would suggest either continue to use email to communicate with end user or move to a board that have same SLA or communicate with our product owner to raise his attention.

On the other hand, if we compare with proper event system, such as application insight, it only keep last 3 months of events, where the integrator that communicate with the notification board store tons of events as tickets and pollute the ticketing system, I'm not sure why no one raise question with them? They can store event in application insight, or new relic, then based on condition to create ticket. They can also have their own database and their own UI to display events.

Why they don't pay the database cost, but we have to pay for their pollution to decrease our own product feature? And to clean up their mess? That sounds a bit of unfair right? Of course that is my own personal opinions.

[cstewartpit]

I think you might have me confused as I'm not trying to pollute your database. If you only sync tickets with the 'visible' flag to the DD database, then only legitimate tickets would be synced. I wouldn't even care if we removed them from the database after a week of being closed, as this is not about historical tickets, but about communicating with customers on an active ticket.

We cannot create a new board, it creates more problems for us than it's worth, so as it stands we're considering moving to the 'dummy contact' idea for NOC tickets, where in we assign these tickets to a dummy user so most contacts can't see them, and then turn on the whole board in DD.

This method (which you guys suggested) contradicts your last message, as it would actually contribute to the scenario you're describing where it's polluting your database with 90% junk! And it means contacts with 'All Tickets' permissions would still see them which we really don't want.

So I do see having a 'visible flag' as a win win. It fixes a big problem for us, allowing us to use the portal to communicate with our customers no matter what the ticket type, which I'm sure many of your other customers would be in a similar predicament if they use these very popular 3rd party monitoring tools such as N-Able. The win for you guys is providing that additional value without blowing out the DD database with junk tickets.

I feel like not enough thought has been put into this before it was declined, so how do I get in touch with the product owner?

[Nness]

We had development meeting today and owner of the company mentioned another approach, which is to utilize contact group. Similar to the dummy contact approach. The contact group only exist in our system, which you can use API to assign ticket to a specific contact group. The downside is also same, where contact with all tickets will still be able to see them, under all tickets collection. So whether to use dummy contact or use contact group, you can decide.

As for management of user voice, historically was all handled by development team, personally I often speak out clearly regarding whether such request fit with our product vision or not. Rather than leave it idle for several years. I do close or mark as declined if it is clearly out of our scope. As for this one, I didn't close straight away it is due to I still willing to hear what other says. Else I normally close them.

Visible flag is pretty much same as not sync notification board, but probably worse. This is due to different customer have different expectation on such flag. Some utilize it, some not. If we have a configuration on this property, then each time people change the flag, we have to delete all synced tickets then resync again to apply change. Which is huge cost.

To be clear, we are using document database, different to SQL, the indexed result is cached on disk. Thus, if we wipe out large amount of tickets or add large amount of tickets, it will have performance impact on the database, which will cause other customer within same cluster to suffer.

To talk to product owner, you can contact with our support, but he said he will prefer to speak with C level. I have mentioned this case to him today, whether you still want to raise it up through support or not, I think it is your choice.

[cstewartpit]

Hey mate,

I see your point regarding the feature being interpreted differently between customers.

Could we tackle it from a different angle and have a flag/tag on individual tickets rather than at Board level to hide it from the 'All Tickets' permission? The flag could possibly also be on a specific contact, hiding all tickets belonging to that contact from others with 'All Tickets'.

This way I can use the dummy contact or contact group ideas to get the solution that we need without customers with 'All Tickets' seeing everything. And when we need to communicate on a particular ticket, we would set the correct contact, allowing them to see the ticket in the portal. (If ticket level flag we would remove via API once contact is changed).

Doing it this way would remove the feature being misinterpreted by different customers as 'Hide from All Tickets' can really only have one outcome.

Happy to have C level conversation regarding this if need be - A solution to this issue would be a huge win for us and likely many of your other customers!

[Nness]

The answer is pretty much no and it is getting worse and worse. To have flag on contact to avoid his ticket to be shown from other means we need to have joined table between contact and ticket. In SQL probably not that big deal, but in current setup, I also need to consider during individual customer's re-sync, the individual database could consume large amount of resource for long period of time which impact others.

Also when any contact change name or any property, all the tickets belong to that contact will need to re-index, does not matter whether he has that flag ticked or not.

After all, the decision is not whether we can have a flag on ticket or not, it is whether we want to invest and put resource to resolve other product's wrong doing. Such as the event that should be saved in application insight or new relic, but they saved in ticketing system as ticket. We don't want to put any promise to fix other integrator's cause.

Any change to the product is a long term commitment.

[cstewartpit]

Even ticket level ability to hide from All Tickets?

And to clarify - New Relic/Application Insights wouldn't resolve this issue, as even though they would generate less tickets, we still wouldn't want contacts seeing 90% of them - just as the ones we wish to communicate with them on, say to schedule a time to make a change for instance.

Anyway - seems it's not going to happen so I'll leave for now and might ask to set up a conversation with owner in future.