05-24-2011 01:00 PM - edited 03-19-2019 02:59 AM
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
05-24-2011 07:58 PM
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).
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide