Deleting e-mails

[aldets]

Greetings all,

I was wondering if anyone has come up with a solution to delete e-mails with Communication Panel? Currently the only way to delete an e-mail with built-in functionality is with e-mails that an agent creates on their own.

With inbound e-mails from queue it is not possible, with built-in functionality.

Deleting e-mails manually is still quite a big thing for our customers.

What I've managed to do, is to use the Extension Area and create a "Delete" button there. At first it looked promising but it all came crumbling down quite fast. The thing is that after the "Delete" button click I made an API DELETE call to /RI/rti/{taskId}. It deleted it instantly and it went away from the Agents view after a few seconds, but after that no new e-mail's were allocated from that queue for that user any more. A session reload restored allocations. I think it has something to do that the Wrap-Up won't trigger. Forcing it to trigger it myself, is something I don't know how to do (if it's even possible).

Currently second try is to set a variable to <true> and wait a few seconds to make the same DELETE API call after the Agent presses "Mark as Handled". That seems to work, for now. There's obviously some other hickup waiting for me around the corner which hasn't revealed itself.

So, has anyone come up with something cool and is willing to share their inventions? 🙂

Kind regards,

Alder

[Jukka]

Hi Alder, 

Good opening! Currently Sinch design is to consider "mark as handled" as solution for agent to get email out from the queue. The thinking is that it requires agent work to check and get rid of the mail, therefore it should be reported like any other conversation. (Conversation is latest word we use to describe all channels). Another aspect is that we received wish that an agent should be able to "re-open" email that has been already handled. That is already available in cloud and will be in FP19 as well. 

Because of above the decision was to enable "mark as handled", but we are open for feedback and feature request via customer ticket. For this one I expected proper business scenario and explanation why the delete is needed. 'Nice to have' is not enough for a feature request to proceed. 

***

Few words about your workaround experiences as well. The RI resource for deleting email is indeed designed to manage items in queue, not for items that are in process. If you wish to continue on that path, then I would propose that agent's would mark emails that they would delete somehow and based on that tag you would have back-end application to do the delete. The marking could be script, internal memo or custom extension area that would write something into database for example. With the back-end approach you can 1st check that the email is not in process and only after that delete. 

Hopefully my brainstorming did make some sense? 😀

BR,
Jukka

ps. for FP19 content please ping me or ask via support. ETA for FP19 is written to another communicaty posting. 

[aldets]

Hi Jukka,

Thanks for Your explanation. I, personally, totally agree and understand why the "Delete" button is not there anymore. Sadly, for customer service, old habits die hard and they are asking for it 🙂 . I've also made a feature request, but won't be dissapointed, if it won't be taken into work. Nevertheless, coming up with my own hack is difficult, but am slowly getting there.
I've also considered and proposed to use either script or Internal notes. I even proposed to send the e-mails into another dummy queue where a custom script would make regular deletions. Too many clicks and too confusing for them 🙂 .

The "custom extension" part, could You elaborate on that abit more?

What I've currently managed to achieve, is that an Agent accepts the e-mail. In the Extension Area there is an extension with two choices:

• Mark for deletion
• Leave alone

Mark for deletion - changes a variable in the javascript to <true>. Now agents selects "Mark as Handled". The script checks the variable and the tasks status value. If it's right for it, it waits 3.5sec and sends a DELETE request to RTI. The 3.5sec wait is at the moment the safest time to wait. With that the wrap-up also triggers correctly.

Leave alone - just marks the variable as <false> and nothing special happens from there.

What I just found from the API documentation that in the ../RI/rti/tasks/{taskId} there is a "key" called values. And it looks like additional data can be added there.

Kind regards,

Alder

[Jukka]

With the custom I were thinking that:
- the extension area app would write to database list of IDs that should be deleted
- then you would have database routine checking the list and deleting the emails 

But maybe that is a risky as you would 1st need to open access to database and then do deleting via database action, not via restful interface. Would mean more risk to break something. 

Have you seen multi-select feature we have made for picklist in 22q4 release? That could help them to handle mass of junk mails. 

//Jukka

[aldets]

Doing these kind of things directly in the database is something that I actively try to avoid, but it is an idea indeed.

Multiselect I've seen in the cloud release. It has it's benefits but overall won't satisfy the absence of the Delete button. We still have some ideas how to solve it or provide some sort of workaround, but the customer service is consistant that they need it. Well they need to start understanding with new UI's you win some, you loose some 🙂 

Thanks for the ideas.