🧠 Architecture Diagram


πŸ–ΌοΈ SymphonyDesk System Diagrams

This page provides a visual, high-level overview of how SymphonyDesk’s core components interact. The diagrams are intentionally simple, clean, and readable β€” perfect for both technical and non-technical audiences.


πŸ“¦ 1. High-Level Architecture

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚                    SymphonyDesk Cloud                     β”‚
β”‚                    (FastAPI Control Plane)                β”‚
β”‚                                                           β”‚
β”‚   β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”   β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”   β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”‚
β”‚   β”‚ /run API      β”‚   β”‚ /jobs API        β”‚   β”‚ Dashboardβ”‚ β”‚
β”‚   β”‚ (Clients)     β”‚   β”‚ (Runners)        β”‚   β”‚ (UI)     β”‚ β”‚
β”‚   β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”˜   β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”˜   └─────┬─── β”˜ β”‚
β”‚          β”‚                        β”‚                   β”‚   β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”˜
           β”‚                        β”‚                   β”‚
           β”‚                        β”‚                   β”‚
           β–Ό                        β–Ό                   β–Ό
   Client Integrations      SymphonyRunner          Web UI Users
   (Service Desk, M365,     (On-Prem / Hybrid)      (Admins, Analysts)
    external systems)

What this shows:
SymphonyDesk’s cloud API sits at the center, with three major external actors:

  • Client systems submit automation requests
  • Runners poll for and execute jobs
  • Users interact through the web dashboard

Everything routes through the cloud control plane.


βš™οΈ 2. Job Flow Diagram

This diagram shows the full lifecycle of a job from creation β†’ execution β†’ completion.

Client / UI
   β”‚
   β”‚ 1. Submit Job (/run or /jobs)
   β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚  SymphonyDesk API  β”‚
β”‚  Queue Job         β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
        β”‚
        β”‚ 2. Runner polls for next job
        β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚    SymphonyRunner      β”‚
β”‚ (PowerShell 7 Engine)  β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
        β”‚
        β”‚ 3. Executes runbook (pwsh.exe)
        β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚   Runbook Execution    β”‚
β”‚   (Scripts + Params)   β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
        β”‚
        β”‚ 4. Return logs/results (/jobs/complete)
        β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚  SymphonyDesk API  β”‚
β”‚  Store Results     β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
        β”‚
        β”‚ 5. UI fetches job history/status
        β–Ό
     Dashboard

πŸ“‘ 3. Runner Sync & Update Diagram

This diagram shows how each on-prem SymphonyRunner keeps itself updated with the latest runbooks.

               SymphonyDesk Cloud
             β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
             β”‚  /runbooks/manifest β”‚
             β”‚  version, checksum  β”‚
             β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                         β”‚
                         β”‚ (Every ~30s)
                         β–Ό
             β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
             β”‚   SymphonyRunner          β”‚
             β”‚   (Runbook Sync Engine)   β”‚
             β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                         β”‚
             β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
             β”‚   Compare Local        β”‚
             β”‚   version/checksum     β”‚
             β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                         β”‚
                Needs Update?
                         β”‚
             β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
             β”‚  Download updated      β”‚
             β”‚  runbook (.ps1)        β”‚
             β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                         β”‚
             β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
             β”‚ Save file β†’ Create/Update .meta.json β”‚
             β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Outcome:
All customers always run the correct, centrally-managed, most recent version of every automation script.


πŸ–₯️ 4. UI & Authentication Diagram

Showing how user identity flows through the dashboard:

User Browser
    β”‚
    β”‚ Login (email + password)
    β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚  SymphonyDesk Auth API  β”‚
β”‚  (JWT Access Tokens)    β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
            β”‚
            β–Ό
   JWT Access Token
            β”‚
            β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚   Dashboard /jobs /stats    β”‚
β”‚   Every request validated   β”‚
β”‚   with user.customer        β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

This enforces:

  • Strict tenant isolation
  • No cross-customer visibility
  • Expiring, revocable tokens
  • RBAC-ready architecture

πŸ” 5. Security Model Diagram

This diagram illustrates the strict key separation:

                SymphonyDesk Cloud
            β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
            β”‚    API Key Roles        β”‚
            β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
            β”‚ CLIENT_API_KEYS β†’ /run  β”‚
            β”‚ Runner Key       β†’ /jobsβ”‚
            β”‚ User JWT         β†’ /UI  β”‚
            β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

         (Three separate authentication paths)
                 β”‚       β”‚        β”‚
       β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜       β”‚        └──────────┐
       β–Ό                 β–Ό                   β–Ό

   Client Systems   SymphonyRunner      Dashboard Users
   (Triggers jobs)  (Executes them)     (Views results)

Key takeaway:
No key is ever reused across subsystems.
This prevents compromise spread and enforces strong segmentation.


🏒 6. Multi-Tenant Data Isolation Diagram

Demonstrates how customer data is partitioned.

                 SymphonyDesk Storage
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚                                                      β”‚
β”‚  /jobs/                                              β”‚
β”‚     Contoso/ (job1.json, job2.json...)               β”‚
β”‚     Fabrikam/ (jobA.json, jobB.json...)              β”‚
β”‚                                                      β”‚
β”‚  /runner_status/                                     β”‚
β”‚     Contoso/ (Runner1.json, Runner2.json)            β”‚
β”‚     Fabrikam/ (RunnerX.json)                         β”‚
β”‚                                                      β”‚
β”‚  CLIENT_API_KEYS β†’ Always tied to a specific tenant  β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Outcome:
Each customer operates as an isolated tenant; no cross-customer visibility or job access is possible.


πŸš€ 7. End-to-End Architecture Summary Diagram

For full context, this is the combined system view:

                 β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
                 β”‚         SymphonyDesk Cloud API            β”‚
                 β”‚  (FastAPI / Jobs / Runbooks / Auth)       β”‚
                 β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                                 β”‚
                                 β”‚ HTTPS
                                 β”‚
      β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
      β”‚                          β”‚                          β”‚
      β–Ό                          β–Ό                          β–Ό
 β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”        β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”      β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
 β”‚Client Systems β”‚        β”‚ SymphonyRunner    β”‚      β”‚   Web Dashboard    β”‚
 β”‚ /run          │──────▢ β”‚  Poll / Execute   │─────▢│ Jobs, Stats, Logs  β”‚
 β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜        β”‚  Sync Runbooks    β”‚      β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                          β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜