Skip to content

Latest commit

 

History

History
529 lines (422 loc) · 16.7 KB

File metadata and controls

529 lines (422 loc) · 16.7 KB

PRD-001: Management Dashboard

Document Information

Field Value
PRD ID PRD-001
Title Croom Management Dashboard
Author Engineering Team
Created 2025-12-15
Status Draft
Priority P0 - Critical
Target Phase Phase 1

1. Overview

1.1 Problem Statement

Currently, Croom devices are managed individually via SSH, requiring technical expertise and significant time investment. There is no centralized way to:

  • Monitor device health and status
  • Deploy configuration changes across multiple devices
  • Troubleshoot issues remotely
  • Track meeting usage and analytics
  • Manage credentials securely

This limits scalability and makes enterprise deployment impractical.

1.2 Solution

Build a web-based management dashboard that provides centralized control and visibility over all Croom devices in an organization.

1.3 Success Metrics

  • Reduce device setup time by 75%
  • Reduce troubleshooting time by 80%
  • Support management of 100+ devices from single interface
  • Achieve 99.9% dashboard availability

2. User Personas

2.1 IT Administrator

Role: Manages all Croom devices in organization Goals:

  • Monitor all devices from single dashboard
  • Quickly identify and resolve issues
  • Deploy updates and configuration changes
  • Generate reports for management

Pain Points:

  • Currently must SSH into each device individually
  • No visibility into device health until users report problems
  • Manual tracking of device inventory

2.2 Facilities Manager

Role: Manages meeting room resources Goals:

  • Understand room utilization
  • Ensure rooms are ready for meetings
  • Schedule maintenance windows

Pain Points:

  • No visibility into which rooms have issues
  • Cannot see if devices are online before meetings

2.3 Help Desk Technician

Role: First-line support for meeting room issues Goals:

  • Quickly diagnose reported problems
  • Perform basic troubleshooting remotely
  • Escalate complex issues with relevant data

Pain Points:

  • Must physically visit rooms to troubleshoot
  • No historical data to understand patterns

3. Features & Requirements

3.1 Device Management (P0)

3.1.1 Device Registration

User Story: As an IT admin, I want to register new devices so I can manage them centrally.

Requirements:

  • Automatic device discovery on network
  • Manual device registration via IP/hostname
  • QR code-based registration from device
  • Device metadata (name, location, room, building)
  • Custom device tagging and grouping

Acceptance Criteria:

  • Device appears in dashboard within 60 seconds of registration
  • All device metadata is editable after registration
  • Devices can be organized into hierarchical groups

3.1.2 Device Inventory

User Story: As an IT admin, I want to see all devices in my organization with their status.

Requirements:

  • List view of all devices with sortable columns
  • Map view showing device locations
  • Filtering by status, location, tags, platform
  • Search by device name, IP, or serial number
  • Export inventory to CSV/Excel

Acceptance Criteria:

  • Dashboard loads device list within 3 seconds
  • Real-time status updates without page refresh
  • Support for 1000+ devices without performance degradation

3.1.3 Device Status Monitoring

User Story: As an IT admin, I want real-time visibility into device health.

Requirements:

  • Online/Offline status with last seen timestamp
  • Current meeting status (idle, in meeting, error)
  • System metrics (CPU, memory, temperature, disk)
  • Network connectivity status and quality
  • Audio/video device status
  • Software version information

Acceptance Criteria:

  • Status updates within 30 seconds of change
  • Historical status data retained for 30 days
  • Visual indicators (green/yellow/red) for health

3.2 Configuration Management (P0)

3.2.1 Device Configuration

User Story: As an IT admin, I want to configure devices remotely.

Requirements:

  • View current device configuration
  • Edit configuration parameters
  • Configuration templates for common setups
  • Bulk configuration changes
  • Configuration validation before apply
  • Rollback capability

Configurable Parameters:

  • Meeting platform preference
  • Calendar/account credentials (encrypted)
  • Audio/video device selection
  • Display settings
  • Network configuration
  • Auto-update settings
  • Timezone and locale

Acceptance Criteria:

  • Configuration changes apply within 60 seconds
  • Failed configurations automatically roll back
  • Audit log of all configuration changes

3.2.2 Credential Management

User Story: As an IT admin, I want to securely manage meeting account credentials.

Requirements:

  • Encrypted credential storage (AES-256)
  • Credential rotation support
  • Credential sharing across devices
  • Integration with secret managers (HashiCorp Vault)
  • Credential usage audit logging

Acceptance Criteria:

  • Credentials never exposed in plaintext
  • Credential changes propagate within 5 minutes
  • Support for multiple credential types (Google, Microsoft, Zoom)

3.3 Monitoring & Alerts (P1)

3.3.1 Real-time Monitoring

User Story: As an IT admin, I want to see real-time device metrics.

Requirements:

  • Dashboard with key metrics overview
  • Individual device detail view
  • Real-time graphs for system metrics
  • Meeting quality indicators
  • Network performance metrics

Acceptance Criteria:

  • Metrics update every 30 seconds
  • 7-day historical data visible in graphs
  • Performance impact on devices < 5% CPU

3.3.2 Alerting System

User Story: As an IT admin, I want to be notified of problems immediately.

Requirements:

  • Configurable alert rules
  • Alert channels (email, Slack, webhook, SMS)
  • Alert severity levels (info, warning, critical)
  • Alert grouping and deduplication
  • Alert acknowledgment and snooze

Default Alert Rules:

  • Device offline > 5 minutes
  • High CPU/memory usage > 90%
  • High temperature > 70°C
  • Failed meeting join attempts
  • Low disk space < 10%

Acceptance Criteria:

  • Alerts delivered within 60 seconds of trigger
  • No duplicate alerts for same issue
  • Alert history retained for 90 days

3.4 Remote Operations (P1)

3.4.1 Remote Actions

User Story: As an IT admin, I want to perform actions on devices remotely.

Requirements:

  • Restart device
  • Restart browser/meeting client
  • Update software
  • Clear cache and data
  • Factory reset
  • Run diagnostics

Acceptance Criteria:

  • Actions execute within 30 seconds
  • Action results visible in dashboard
  • Confirmation required for destructive actions

3.4.2 Remote Troubleshooting

User Story: As a help desk technician, I want to troubleshoot devices without physical access.

Requirements:

  • View device logs
  • Screenshot/screen sharing
  • Remote shell access (with audit logging)
  • Network diagnostics (ping, traceroute, DNS)
  • Audio/video test tools

Acceptance Criteria:

  • Logs available within 30 seconds
  • Remote shell sessions fully logged
  • Screenshots capture current display

3.5 Analytics & Reporting (P2)

3.5.1 Usage Analytics

User Story: As a facilities manager, I want to understand room utilization.

Requirements:

  • Meeting count and duration statistics
  • Room utilization percentages
  • Peak usage times
  • Platform usage breakdown
  • Participant count trends

Acceptance Criteria:

  • Analytics available for custom date ranges
  • Data exportable to CSV
  • Dashboard widgets for key metrics

3.5.2 Report Generation

User Story: As an IT admin, I want to generate reports for management.

Requirements:

  • Pre-built report templates
  • Custom report builder
  • Scheduled report delivery
  • PDF and Excel export
  • Report sharing and collaboration

Report Types:

  • Device health summary
  • Incident report
  • Utilization report
  • Cost savings analysis

Acceptance Criteria:

  • Reports generate within 60 seconds
  • Historical data available for 1 year
  • Reports accurate to within 1%

3.6 User Management (P1)

3.6.1 Authentication

User Story: As an IT admin, I want secure access to the dashboard.

Requirements:

  • Local user accounts with password policy
  • LDAP/Active Directory integration
  • SAML SSO support
  • Multi-factor authentication (MFA)
  • Session management

Acceptance Criteria:

  • Support industry-standard auth protocols
  • MFA reduces unauthorized access by 99%
  • Sessions expire after inactivity

3.6.2 Authorization

User Story: As an IT admin, I want to control what users can do.

Requirements:

  • Role-based access control (RBAC)
  • Custom role creation
  • Permission granularity (read, write, admin)
  • Device/location-based access

Default Roles:

  • Super Admin: Full access
  • IT Admin: Device management, no user management
  • Operator: View only, basic troubleshooting
  • Viewer: Read-only access

Acceptance Criteria:

  • Role changes effective immediately
  • Audit log of permission changes
  • No privilege escalation vulnerabilities

4. Technical Architecture

4.1 System Components

┌─────────────────────────────────────────────────────────────────┐
│                         Load Balancer                            │
│                     (nginx / cloud LB)                          │
└─────────────────────────────────────────────────────────────────┘
                               │
              ┌────────────────┼────────────────┐
              │                │                │
              ▼                ▼                ▼
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│   Web Frontend   │ │   API Server     │ │   WebSocket      │
│   (React SPA)    │ │   (Node.js/      │ │   Server         │
│                  │ │    FastAPI)      │ │   (Socket.IO)    │
└──────────────────┘ └──────────────────┘ └──────────────────┘
                               │
              ┌────────────────┼────────────────┐
              │                │                │
              ▼                ▼                ▼
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│   PostgreSQL     │ │   Redis          │ │   TimescaleDB    │
│   (Config, Users)│ │   (Cache, Queue) │ │   (Metrics)      │
└──────────────────┘ └──────────────────┘ └──────────────────┘
                               │
                               ▼
              ┌────────────────────────────────┐
              │   Message Queue (MQTT/Redis)   │
              └────────────────────────────────┘
                               │
         ┌─────────────────────┼─────────────────────┐
         │                     │                     │
         ▼                     ▼                     ▼
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│   Croom Agent   │ │   Croom Agent   │ │   Croom Agent   │
│   (Device 1)     │ │   (Device 2)     │ │   (Device N)     │
└──────────────────┘ └──────────────────┘ └──────────────────┘

4.2 Device Agent

A lightweight agent running on each Croom device:

Responsibilities:

  • Report device status and metrics
  • Receive and execute commands
  • Stream logs to server
  • Handle configuration updates
  • Manage local credentials

Technical Requirements:

  • Language: Python 3 or Go
  • Memory footprint: < 50MB
  • CPU usage: < 5% idle, < 20% active
  • Startup time: < 10 seconds
  • Offline operation: Queue commands for retry

4.3 API Design

RESTful API Endpoints:

# Devices
GET    /api/v1/devices              - List devices
POST   /api/v1/devices              - Register device
GET    /api/v1/devices/{id}         - Get device details
PUT    /api/v1/devices/{id}         - Update device
DELETE /api/v1/devices/{id}         - Remove device
POST   /api/v1/devices/{id}/actions - Execute action

# Configuration
GET    /api/v1/devices/{id}/config  - Get configuration
PUT    /api/v1/devices/{id}/config  - Update configuration
GET    /api/v1/config-templates     - List templates
POST   /api/v1/config-templates     - Create template

# Metrics
GET    /api/v1/devices/{id}/metrics - Get device metrics
GET    /api/v1/metrics/aggregate    - Aggregated metrics

# Alerts
GET    /api/v1/alerts               - List alerts
PUT    /api/v1/alerts/{id}          - Update alert
GET    /api/v1/alert-rules          - List rules
POST   /api/v1/alert-rules          - Create rule

# Users
GET    /api/v1/users                - List users
POST   /api/v1/users                - Create user
PUT    /api/v1/users/{id}           - Update user
DELETE /api/v1/users/{id}           - Delete user

4.4 Security Considerations

  • All API calls authenticated via JWT
  • TLS 1.3 for all communications
  • Device authentication via certificates
  • Credential encryption at rest (AES-256-GCM)
  • Input validation and sanitization
  • Rate limiting to prevent abuse
  • Audit logging for compliance

5. User Interface

5.1 Dashboard Home

  • Device count summary (total, online, offline, in-meeting)
  • Recent alerts panel
  • Quick actions shortcuts
  • Usage statistics widgets

5.2 Device List

  • Sortable/filterable table
  • Status indicators
  • Quick action buttons
  • Bulk selection for operations

5.3 Device Detail

  • Real-time status and metrics
  • Configuration panel
  • Action buttons
  • Log viewer
  • Meeting history

5.4 Settings

  • User management
  • Alert configuration
  • Integration settings
  • System configuration

6. Non-Functional Requirements

6.1 Performance

  • Dashboard page load: < 3 seconds
  • API response time: < 500ms (p95)
  • Support 1000+ concurrent devices
  • Support 100+ concurrent dashboard users

6.2 Availability

  • 99.9% uptime SLA
  • Graceful degradation when components fail
  • No single point of failure

6.3 Scalability

  • Horizontal scaling of API servers
  • Database read replicas
  • Metrics data sharding

6.4 Security

  • SOC 2 Type II compliance path
  • GDPR considerations
  • Regular security audits
  • Penetration testing

7. Implementation Plan

Phase 1: MVP (4 weeks)

  • Basic device registration and listing
  • Real-time status monitoring
  • Simple configuration management
  • Basic alerting (email)

Phase 2: Core Features (4 weeks)

  • Remote actions
  • Log viewing
  • Advanced alerting
  • User management with RBAC

Phase 3: Analytics (2 weeks)

  • Usage analytics
  • Report generation
  • Dashboard customization

Phase 4: Enterprise (2 weeks)

  • LDAP/SSO integration
  • Advanced security features
  • Multi-tenant support

8. Open Questions

  1. Should we support on-premise deployment only, or cloud-hosted option too?
  2. What is the expected device count for initial deployment?
  3. Are there specific compliance requirements (HIPAA, etc.)?
  4. What alerting integrations are must-have vs nice-to-have?

9. Appendix

9.1 Competitive Analysis

Feature Cisco Control Hub Croom Dashboard
Device Management Yes Yes
Real-time Monitoring Yes Yes
AI Insights Yes Phase 3
Multi-vendor Support Cisco only Any Pi device
Pricing $15/device/month Open source

9.2 References