Multiple UIs & roles

[n7get]

In this use case the operator is deployed to a served agency. This idea is to have separate UIs for the originator/consumer of messages from the operator’s UI. This is much in the same way as NBMS.

The UIs could be something like:
Client UI
Operator UI

The operator can create one or more client roles. Example roles could be IC, PIO, etc.

The client would compose an outgoing message using their devices and post it to a pending messages queue. The operator would review the message to make sure it adheres to applicable FCC regs and other laws. If the message can’t be sent the operator can reject the message with a note as to why. Once the message is OK to send the operator will post it to an outbox for sending. Multiple outboxes could be useful here.

The operator would review incoming messages to determine which role(s) the message should be forwarded to. The client would receive an alert on their device that a message is waiting for them and review/print the message.

[tmiw]

How much extra work would that be typically on the operator's part? I wonder if maybe the existing tactical alias functionality could be useful to cut that down (i.e. by eliminating the manual review on the receive end).

[HarveyCreek]

I see a need for a feature like this for one of my served agencies. The clients are dispatchers and 911 support personnel used to encrypted radio or private connections. Most are aware of the FCC regs and other laws, but they do let something slip by, as I imagine would a radio operator, so the more folks reviewing I see the better. The main advantage to a feature like this for my agency, would be allowing the client group to view and react to messages in a way that is disconnected with the operators. They are located in a secure double locked door facility within the EOC, which makes runner operations very difficult as those with access are few in numbers.

[SkyeDog]

It will also benefit everyone involved w/Part 97 and SHARES.