cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2926
Views
0
Helpful
1
Replies

Unity Connection 7.0 - Shared Mailbox

us10610
Level 4
Level 4

Users are complaining that when 2 people access a single mailbox to retrieve call-in prescriptions that the messages are not deleted immediately. The first person listens and deletes the message but it is still being played for the 2nd person who is unknowningly filling the perscription a 2nd time. They swear that the system didn't operate in this manner in Unity 4.5 but since we've recently upgraded to Connection 7.1.5 it has become a problem.

Is anybody aware of how this is supposed to operate and if there are any settings to munipulate the default actions. Otherwise, perhaps somebody may have a suggestion of a better way to handle the collection of prescriptions where multiple people can retrieve them simultaneously.

Thanks in advance.

Greg

1 Reply 1

lindborg
Cisco Employee
Cisco Employee

To be clear, neither Unity or Connection is designed to explicitly support multiple login mailboxes - mailboxes in both products are designed for a single user signing into a single mailbox (hence the lack of support for "guest" access into a single mailbox for instance).  As such any differences in behavior here are not relevant since the scenario is not supported.

That said, Connection supports dispatch messaging which is designed to provide support for this type of thing.  Short version: You can setup multiple users in a distribution list meant to handle dispatch requests (i.e. inbound messages need to be handled by one and only one person) - message marked for dispatch delivery get removed from everyone else's mailbox as soon as someone accepts the message over the phone.  This ensures that only one person gets the message and handles it.  It's designed just for things like this (or scenarios where support folks need to handle callbacks etc...) - the down side there is that users must be on the same Connection cluster (the dispatch flag is not replicated around the network).

This is a bit more scalable and supportable than having multiple folks logging into a secondary box with the same credentials and expecting the read/deleted status to be reflected on the subsequent call in the same box at the same time (these values are not forced to be updated until the caller exits in Connection).