MSP Field Ops Console

What Is This Console

Purpose, scope, and operating modes

The MSP Field Ops Console is a single-screen operations dashboard purpose-built for MSP service desk technicians. It aggregates the active ticket queue, vendor health, client context, and live audit log into one interface, then provides a structured 7-tab workflow for every ticket — from initial intake through root-cause investigation, remediation, verification, and close.

Intended Audience

Who uses this console and at what role level

Architecture

Data flow, proxy pattern, and state management

1. 1
   DOMContentLoaded → loadDashboard()

   Restores saved theme from localStorage, then calls loadDashboard(). This calls renderAll() immediately for a fast first paint, then starts startAutoRefresh(30000).
2. 2
   startAutoRefresh(30000)

   Clears any existing interval timer, then sets a 30-second interval calling refreshAll(). The timer reference is stored in _refreshTimer to prevent duplicate timers on repeated calls.
3. 3
   refreshAll() → doRefresh()

   The suite-standard wrapper. Delegates to doRefresh() which is the actual DEMO/LIVE branch implementation. In demo mode, falls through to mock data. In live mode, polls all three proxy endpoints.
4. 4
   doRefresh() — three parallel fetches

   Calls fetchWithFallback('/api/tickets?level=N'), fetchWithFallback('/api/alerts'), and fetchWithFallback('/api/client-health'). Maps real responses into TICKETS, CLIENTS arrays. Then calls renderAll().
5. 5
   renderAll() — six render functions

   Calls renderRailStats(), renderTickerFeed(), renderTicketQueue(), renderVendorSidebar(), renderDashWidgets(), renderRightSidebar(). All read only from state arrays — purely presentational.

// READ endpoints (GET)
GET  /api/tickets?level=N        → [{id,p,subj,client,sla,age,assignee,cat,board},…]
GET  /api/alerts                 → {critical,warning,slaBreaches,atRisk,bkpFails,envScore}
GET  /api/client-health          → [{name,score,risk,devices,alerts,backupFails,patchPct,open},…]

// WRITE endpoint (POST) — action fan-out
POST /api/action                 → {ok:bool, result:string, ts:string}

// Action types handled by proxy:
//   create-ticket    → CW Manage POST /service/tickets
//   close-ticket     → CW Manage PATCH /service/tickets/{id} status=Closed
//   add-note         → CW Manage POST /service/tickets/{id}/notes
//   escalate-ticket  → CW Manage PATCH /service/tickets/{id} assignedTo+priority
//   reassign-ticket  → CW Manage PATCH /service/tickets/{id} assignedTo
//   run-diag         → NinjaRMM + S1 + CW Automate + Auvik (multi-vendor read)
//   vendor-diag      → single-vendor read by api field
//   S1 Full Scan     → S1 POST /web/api/v2.1/agents/actions/scan
//   Huntress Scan    → Huntress POST /v1/agents/{id}/scan
//   Restart Service  → CW Automate POST /cwa/api/v1/scripts/run
//   Ninja Push Patch → NinjaRMM POST /v2/device/{id}/maintenance-windows
//   Isolate Endpoint → S1 POST /web/api/v2.1/agents/actions/disconnect (L2+)
//   Reset Password   → Entra ID PATCH /v1.0/users/{id} passwordProfile
//   Verify Backup    → Acronis GET /api/2/resources/{id} lastBackup status
//   Block IP/Domain  → Umbrella POST /admin/v2/destinationlists/{id}/destinations
//   Quarantine Email → Mimecast POST /api/email/hold-summary/create-hold

Audit Summary

12 findings across every button, action, and data-fetching call

Fixes Applied

What changed and why

The existing doRefresh() function already contained the full DEMO/LIVE fetch logic. The suite pattern was added as a thin wrapper layer. loadDashboard() calls renderAll() immediately for instant first paint, then starts the 30-second cycle. refreshAll() delegates to doRefresh() — no logic was duplicated.

function loadDashboard(){
  renderAll();                 // instant first paint from mock data
  startAutoRefresh(30000);    // start 30s cycle
}

function startAutoRefresh(ms){
  if(_refreshTimer) clearInterval(_refreshTimer);
  _refreshTimer = setInterval(function(){ refreshAll(); }, ms||30000);
}

async function refreshAll(){
  // DEMO: falls through to mock in doRefresh
  // LIVE: polls /api/tickets + /api/alerts + /api/client-health
  await doRefresh();
}

The three Quick Action sidebar buttons that were firing toasts without doing anything real now route to their correct functions. "Escalate" → execEscalate() which POSTs through postAction(). "Close Tkt" → prepareCloseTicket() which opens the confirm-close modal with the resolution note template. "Sync APIs" → doRefresh() which actually polls the proxy.

All four functions now call postAction() with a typed action field that the proxy can route to the correct vendor. Each retains its original mock behaviour as the fallback — the animated diagnostic sweep in runDiag(), for example, now runs as the fallback response when the proxy is not live.

A new execReassign() function replaces the toast on the "Assign →" ticket header button. It opens a technician picker modal and calls submitReassign() which POSTs {action:'reassign-ticket', assignee} to the proxy. The proxy maps this to ConnectWise Manage PATCH /v4_6_release/apis/3.0/service/tickets/{id}.

Vendor API Limitations

Genuine constraints that affect what the console can do via API

Header Rail

Top-bar elements — stats, role switcher, controls

Alert Ticker

Scrolling live-event feed below the header rail

A horizontally scrolling CSS-animated ticker (@keyframes tscrl, 55s cycle) showing 10 alert items. In demo mode the items are a static hardcoded array in renderTickerFeed(). Clicking any item shows a toast with the full text. The ticker pauses on hover. Items duplicate themselves to fill the scroll width.

Alert Banner

Full-width critical strip above the work area

A collapsible red banner at the top of the workspace grid area. Only visible when P1 tickets are in the queue (zone.classList.contains('has-alert')). Auto-updates via updateBanner() on every renderRailStats() call. Shows count of P1 tickets and SLA breaches with a truncated summary of active P1 subjects. Dismiss button removes the has-alert class from the zone div, hiding it until the next render cycle detects new P1s.

Left Sidebar

Tech profile, ticket queue, quick actions, vendor console links

Shows the current technician's avatar initials, name, level badge, and CSAT score. Updates dynamically when the role switcher changes. Four hardcoded demo personas: Arnold K. (L1), Maria S. (L2), Dev P. (L3), Lead Eng. (L4). In live mode the proxy can return the authenticated technician's data from ConnectWise Manage GET /v4_6_release/apis/3.0/system/members/{id}.

Rendered by renderTicketQueue(). Shows up to ~8 tickets in a scrollable list. Each row shows priority badge (P1–P4), truncated subject, client name, SLA indicator (✓/!/⚠ with blink animation on breach), and age. Clicking a row calls openTicket(idx) which switches the centre area to ticket view. Active ticket row is highlighted with the .active class.

Rendered by renderVendorSidebar() from the VENDORS array (17 entries). Each row shows status dot, icon, name, category, and latency. Clicking opens the Vendor Detail Pane (openVendorPane(v)) which shows API status, latency bars, and a button to open the vendor's sub-console HTML file in a new tab.

Dashboard View

Default centre area — 3-column widget grid

The default centre view is a 3-column CSS grid of glassmorphism widget cards. Replaced by ticket view when a ticket is opened. Returns when closeTicket() is called.

Ticket View

Activated by clicking any ticket in the queue

openTicket(idx) hides the dashboard grid, shows #ticket-view, and populates all elements from TICKETS[idx]. The ticket header shows ID, priority badge, subject, client, SLA status, and the assignee button. Below it are the 6-step progress indicator and the 7-tab workflow nav.

Right Sidebar

Client context, related cases, vendor health, live audit log

Tab 01 — Intake

Ticket details and intake checklist

Displays the ticket's core fields (ID, priority, client, category, board, assignee, age, SLA) in an info grid. Followed by a 6-item intake checklist. Checklist items toggle .done state on click via toggleChk(el) — purely client-side, not persisted to CW Manage. Hotkey: press 1 while ticket is open.

Tab 02 — Triage

Three-Pass System checklist and diagnostic snapshot

Implements the Three-Pass Triage methodology: Pass 1 (confirm symptom, quick win check), Pass 2 (cross-reference NinjaRMM, SentinelOne, Huntress, Mimecast), Pass 3 (deep-dive for unresolved P1/P2). The diagnostic output terminal shows real-time results from runDiag(). L3/L4-only Advanced Triage section (visible when body has .l3 or .l4 class) provides four direct action buttons now properly wired through execAction(). Hotkey: 2.

Tab 03 — Investigate

Vendor diagnostic cards and investigation notes terminal

Shows four vendor diagnostic cards (NinjaRMM, SentinelOne, CW Automate, Auvik) with live data fields. Each card has a "▶ Run Query" button that now calls runVendorDiag(id, nm), which POSTs {action:'vendor-diag', api:id} to the proxy and refreshes the card rows with the returned data. The investigation notes terminal below is a pre-populated mock showing a multi-vendor query sequence — in live mode this is replaced by real proxy response lines. Hotkey: 3.

Tab 04 — Remediate

Action grid, execution log, change management checklist

The action grid renders from the ACTIONS array, filtered by role. L1 sees 7 actions (non-destructive). L2+ sees all 9 including Isolate Endpoint and Block IP/Domain. Each button calls execAction(nm, api). Hotkey: 4.

Tab 05 — Verify / Doc

Verification checklist, documentation checklist, status terminal

Two checklists: Verification (4 items — client confirmation, 15-minute hold, vendor dashboard health, downstream check) and Documentation (5 items — root cause, resolution steps, KB article, time entries in CW PSA, client communication). Both are client-side toggle only. The status terminal at the bottom is populated in live mode by a final proxy health-check query. Hotkey: 5.

Tab 06 — Close / Escalate

Escalation card and confirm-close modal flow

Two dropdowns: "Escalate To" (L2/L3/L4/Vendor TAC/Security Team) and "Reason". The "⬆ ESCALATE TICKET" button calls execEscalate() which reads the dropdown values and POSTs {action:'escalate-ticket', escalateTo, reason}. Proxy maps to CW Manage PATCH /service/tickets/{id} updating assignedTo and priority fields.

1. 1
   ✓ CLOSE TICKET & SEND CSAT

   Calls prepareCloseTicket(). Computes elapsed time since ticketOpenTime. Builds a resolution note template and injects it into the modal textarea with the current timestamp.
2. 2
   Resolution note modal opens

   Editable textarea with 4000-character limit (CW Manage note length limit). Live character counter with warn/danger colour thresholds at 3800/4000. "↺ Revert to Template" resets to the auto-generated text.
3. 3
   ↵ Submit & Close Ticket

   Calls submitNoteAndClose(). Two sequential postAction() calls: {action:'add-note', text:finalNote} then {action:'close-ticket', status:'Closed', doneFlag:true}. Both must succeed for the ticket to be removed from the local queue.
4. 4
   CSAT — workflow reminder only

   The "CSAT survey sent" toast is informational. ConnectWise Manage REST API has no CSAT endpoint. CSAT delivery is handled server-side by CW Client Portal rules.

Keyboard: Esc closes the modal. Enter (when focus is not in the textarea) submits.

Tab 07 — History

Activity timeline for the open ticket

A vertical timeline rendered from HISTORY_ITEMS. Each item shows a timestamp, dot state (done/active/pending/warn), title, and sub-text. In demo mode these are static demo entries for TKT-10087. In live mode the proxy returns the ticket's full activity history from CW Manage GET /v4_6_release/apis/3.0/service/tickets/{id}/notes combined with S1/Ninja action logs. Hotkey: 7.

Remediation Actions

All 9 actions — vendor API mapping and RBAC visibility

Proxy Architecture

What the backend must implement to make every action live

Vendor Catalogue

All 17 vendors in the VENDORS array — category, API status, link target

RBAC — L1 to L4

CSS-driven visibility system — body.lN class controls element display

Role visibility is entirely CSS-driven. When setRole(N) is called, document.body.className is set to 'lN'. Elements tagged with RBAC classes are shown/hidden by cascade rules defined in the style block.

Refresh Cycle

30-second auto-refresh, manual trigger, and response mapping

Activation Checklist

Ordered steps to go live from demo mode

1. 01
   Deploy backend proxy on Node/Express (or equivalent)

   Implement the four endpoints: GET /api/tickets, GET /api/alerts, GET /api/client-health, POST /api/action. Start with ConnectWise Manage integration — it covers ticket CRUD, notes, and reassignment. All other vendor fan-outs can be added incrementally.
2. 02
   Configure API_BASE, API_KEY, FETCH_ENABLED

   In the config block near the top of the script section: set API_BASE to your proxy URL, set API_KEY to your proxy's shared secret (match in your proxy .env), set FETCH_ENABLED = true.
3. 03
   Register ConnectWise clientId at developer.connectwise.com

   The CW Manage REST API requires a clientId header (UUID) on every request. Register your proxy application at the developer portal to obtain it. Without it, all CW Manage calls return 401.
4. 04
   Implement action router in proxy by action string

   The proxy receives {action:'S1 Full Scan', api:'s1', ticketId, tech}. Route by action string to the correct vendor endpoint. Start with the non-destructive actions (scan, verify backup, diag), then gate destructive ones (isolate, block) behind role verification.
5. 05
   Resolve device/agent identifiers from ticket context

   Several actions need more than a ticket ID — S1 scan needs an agent UUID, CW Automate restart needs a computerId, Acronis verify needs a resource ID. Your proxy must look up these identifiers from NinjaRMM or CW Manage using the client name and device name from the ticket.
6. 06
   Verify in browser — confirm API badge flips to ◉ LIVE

   Load the console, check DevTools → Network for the three GET calls on load. Confirm 200 responses. The badge in the top-right should switch from ◌ MOCK to ◉ LIVE. Rail stats should reflect real ticket and alert counts.
7. 07
   Test ticket close flow end-to-end

   Open a test ticket, navigate to Tab 6, click "✓ CLOSE TICKET & SEND CSAT", review the modal, submit. Verify in CW Manage that the ticket has a resolution note and status of Closed. Verify the ticket disappears from the queue on the next refresh cycle.
8. 08
   Enforce role at proxy level — do not rely on CSS RBAC

   The CSS visibility system is UI-only. Configure your proxy to reject action:'Isolate Endpoint' or action:'Block IP/Domain' when the tech field resolves to an L1 role in your CW Manage system/members data. Log all action attempts with the tech identifier regardless of outcome.

Troubleshooting

Common issues and resolutions