Auto-Client, aka. "Virtual Operator", requires that the central station be licensed for Virtual Operator.
Configuration
Auto-Client service must be installed and running in the Central Station's active config.
Action Patterns and Action Pattern Commands
An Alarm is assigned an Action Pattern with initial command(s) that are AutoClient'able. (details below)
Auto-Client capable Action Pattern Commands
Action Items
CONTACT/NOTIFY
Limitations
CONTACT/NOTIFY to Call Lists are always Auto-Client capable (Auto-Client will pick it up and attempt if it can)
CONTACT/NOTIFY to Contact Point Types having attribute S (SMS Phone), M (Pager), F (Fax), and E (E-mail) require that a Script has been specified (other than None) to be Auto-Client capable.
CONTACT/NOTIFY to a Contact Point Type having attribute R (Retransmission) is Auto-Client capable. (OpenVoice, AutoText, ...)
NOTIFY to an unspecified Contact Point Type requires that a Script has been specified (other than None) to be Auto-Client capable.
Rev Cmd (* Need more information)
CLOSE
INCLUDE
LOG
REPORT
SEND
SUSPEND
DEFER
SET
JUMPTO
WAIT (* Needs Confirmation, Auto-Client/AppServer do a suspend on the fly or something?)
ESCALATE
Limitations
ESCALATE requires that the destination Customer be specified (can't be a try/search)
NOTE: ManDD is missing ACTIONS_D.SEARCH (cont/notify/revcmd) value of 2 (0 using, 1 trying, 2 use alm cust). Also, AppServer excludes 2 from being autoclient capable. Making a Dev item on this issue.
Logic Items
Limitations
Auto-Client capable provided that the next Action Pattern item is a command that is Auto-Client capable. (* Needs more detailed information)
Label / Marker Items
Limitations
Auto-Client capable provided that the next Action Pattern item is a command that is Auto-Client capable. (* Needs more detailed information)
Scenarios that will prevent Auto-Client from picking up/handling an Alarm
Auto-Client (aka. Virtual Operator) is not licensed
Auto-Client service is not installed, properly updated, or not running
Video/Audio involved Alarm
This includes any alarm that is received with a Video or Audio clip as well as any alarm that comes in on an Area or Zone that is associated with Video or Audio Device(s). Note that a Device can also be tied to an area of * and/or zone of *
There is a Manitou Option in Supervisor Workstation to turn this behavior on/off. SWS -> MOptions -> Signal Processing -> Prevent the system from forcing Video and Audio associated alarms to an operator screen (Yes/No).
Comments configured for Show On Open in an Alarm
Unresolved Maintenance Issues
Backdated Signals
Manual Signals (* Need to clarify limitations)
Auto-Client won't interfere with alarms that are currently suspended (doesn't interrupt an active suspend to perform anything)
Audio Session (Two-way and the like) is associated with an Alarm (* Needs more information)
Under the Hood
ACTIONS.FIRSTAUTO and ACTIONS.AUTORUN
When storing an Action Pattern, the AppServer decides if the first command is Auto-Client capable when changes are stored. ACTIONS.FIRSTAUTO will indicate whether the AppServer determined that the first command is Auto-Client capable or not. Note: ACTIONS.AUTORUN indicates "Critical first contact indicator which bypasses the initial information dialogs and notifications until a Contact action has been completed or is In-Progress"
ALARM.NXTACTAUTO
When an alarm is received, the Signal Handler will identify which Action Pattern to use and if that alarm's resulting Action Pattern has ACTIONS.FIRSTAUTO of true, ALARM.NXTACTAUTO will likely be true unless a qualifying scenario eliminates this option (see above).
During the Alarm's lifetime, ALARM.NXTACTAUTO can change depending on the scenario and any other limitations the next Action Pattern Command has.
ACTIONS_D.AUTO
Identifies whether this Action Pattern Command item is attempted automatically upon successful completion of the previous item. This field affects client UI behavior for real Operators and does not affect whether the command is Auto-Client capable or not.
