Multi-Server Workflow
Switch safely between environments and understand what TriggerDeck remembers separately for each server.
Switch server context from More
TriggerDeck assumes operators may need more than one server. The More sheet is the fast context switcher for that case. It shows all configured servers, highlights the active one, shows the detected Zabbix version and support status, and keeps server maintenance actions close by:
- switch server
- edit current server
- add another server
- open Settings
Flow shown on screenshot
More sheet server switcher
Open More with multiple configured servers and keep the selected server marker, version/status badges, and action rows in one frame. This screenshot should show the context switch hub where operators intentionally change server scope and confirm compatibility before reading data.
Mix supported Zabbix versions intentionally
TriggerDeck supports Zabbix 6.0 LTS, 7.0 LTS, and 7.4. Zabbix 8.0 is available as experimental support while upstream 8.0 builds continue toward LTS. Additional compatible versions are 6.2, 6.4, and 7.2; support for these versions is restricted and untested.
In a multi-server setup, confirm both the selected server and its detected Zabbix version before comparing counts, dashboard behavior, or available widgets across environments. The More sheet keeps the saved server list, active selection, detected version, and support status together so mixed fleets are easier to reason about before you drill into Problems, Hosts, Items, or Dashboards.
Patch versions follow the status of their minor line, and unlisted minor or major versions should be treated as unsupported.
Show what is remembered per server
The public docs should make it explicit that TriggerDeck does not treat every screen state as global. Depending on the feature, the app can remember:
- selected server
- Problems filters, sorting, and grouping
- Hosts grouping and organization
- selected Items host and filters
- selected dashboard and dashboard reader position
This is important for trust and clarity. When the operator switches servers, a different queue shape or different selected dashboard is expected behavior, not a bug.
Flow shown on screenshot
Per-server working state example
After switching servers, show a visibly different working state such as changed filters, grouping, or selected dashboard. This frame should make clear that view state is remembered per server and that differing queue shapes are expected behavior.
What to emphasize
- Always confirm which server is selected before interpreting counts or details.
- Push identifiers are also server-specific.
- Server switching should feel intentional and low-risk because display names stay visible and the selected server is marked clearly.