←
Eviworx
Eviworx

Technical Whitepaper

Eviworx Enterprise ITSM Platform

Version 1.0

Stand: September 2026

Eviworx Software UG (haftungsbeschränkt)

Zusammenfassung

Eviworx ist eine Enterprise-Grade ITSM-Plattform mit 50+ integrierten Modulen, Blockchain-ähnlicher SHA-256 Audit-Chain und Zero-Trust Sicherheitsarchitektur. FIPS-140-2-kompatible Algorithmen (PBKDF2-SHA512, TOTP HMAC-SHA256; keine FIPS-Zertifizierung). Das System ist vollständig On-Premise deploybar via 12 spezialisierten Docker-Containern (inkl. Traefik API-Gateway und Report-Generator) und bietet Multi-Instance-Fähigkeit mit Distributed Locks. Mit Features wie MFA/TOTP, 4-Augen-Prinzip, Entra ID SSO, Microsoft Graph API, ClamAV-Integration und einer Workflow-Engine mit 8 Schritt-Typen adressiert Eviworx die Anforderungen compliance-orientierter Mittelstands- und Enterprise-Kunden. Verfügbar in 5 Sprachen (DE, EN, ES, FR, IT). Hinweis: Eviworx unterstützt mit Architektur und Prozessen bei der Umsetzung von DSGVO- und NIS2-Anforderungen; damit ist keine Zertifizierung und keine rechtsverbindliche Konformitätszusage verbunden.

Inhaltsverzeichnis

  1. 1. Einleitung
  2. 2. System-Architektur
  3. 3. Security & Compliance
  4. 4. Kern-Module
  5. 5. Workflow-Engine
  6. 6. SLA-Management
  7. 7. Cost Management & Contracts/Licenses
  8. 8. Deployment & Skalierung
  9. 9. Integrationen
  10. 10. Use Cases
  11. 11. Technische Spezifikationen
  12. 12. Roadmap

1. Einleitung

1.1 Problemstellung

Moderne IT-Service-Management-Lösungen stehen vor wachsenden Herausforderungen: Compliance-Anforderungen (ISO 27001, NIS2, DSGVO), fehlende Nachvollziehbarkeit von Änderungen, mangelnde Integration zwischen Ticketing, Assets und Workflows sowie hohe Kosten für Cloud-basierte SaaS-Lösungen bei gleichzeitig steigenden Datenschutzbedenken.

Insbesondere im Mittelstand und bei regulierten Branchen besteht Bedarf an On-Premise-Lösungen mit mit Manipulationserkennung verketteten, nachvollziehbaren Audit-Trails, die gleichzeitig modern, skalierbar und wartungsarm sind.

1.2 Lösungsansatz

Eviworx adressiert diese Herausforderungen durch:

  • Blockchain-ähnliche Audit-Chain: SHA-256 Hash-Verkettung macht nachträgliche Manipulationen mathematisch nachweisbar
  • Zero-Trust Security: AV-Worker ohne Dateizugriff, SSRF-Protection, automatische Schwärzung sensibler Felder in Audit-Logs
  • Container-basiertes Deployment: 12 spezialisierte Container (inkl. Traefik API-Gateway) für modulare, skalierbare Architektur
  • 50+ integrierte Module: Von Tickets über Assets bis Workflow-Automation – alles aus einer Hand
  • Multi-Instance Ready: Distributed Locks ermöglichen Active-Active-Deployments

2. System-Architektur

2.1 Container-Übersicht

Eviworx besteht aus 12 spezialisierten Containern, die über Docker Compose orchestriert werden:

Traefik API-Gateway
Reverse-Proxy, TLS-Terminierung, Routing, Rate-Limiting
Frontend
React SPA, statisch ausgeliefert via NGINX
Backend
Node.js API, Prisma ORM, JWT Auth
PostgreSQL
Persistenz, getrennte Datenbank-Rollen, Audit-Trigger
Redis
Caching, Queues (BullMQ), Locks
Email-Worker
Background Email-Processing, BullMQ Consumer
Job-Worker
Scheduled Jobs, Cron, Multi-Instance Support
Workflow-Engine
BPM, 8 Node-Typen, SLA-Monitoring
Notification-Worker
Multi-Channel Dispatch (Email, Teams via Bot Framework, Webex)
Report-Generator
Custom Reports, PDF/XLSX-Generierung, Scheduled Reports
Virus-Scanner
Virus-Scanner Daemon, Automatische Signature-Updates
AV-Worker
Scan-Orchestrator (Zero-Trust, keine File-Access)

12 Container für Production-Deployment (inkl. Traefik API-Gateway und Report-Generator)

2.2 Datenmodell

Das System basiert auf 153 Datenbank-Modellen, organisiert in 50+ Domain-Modulen:

  • Auth & Identity (13 Modelle): User, Agent, Roles, AgentGroups, API-Keys
  • ITSM Core (36 Modelle): Tickets, Incidents, Problems, Changes, Approvals, Lifecycle-Konfiguration
  • Assets (23 Modelle): Asset, Type, Category, Relations, Handover, Inventur
  • Workflows (7 Modelle): Templates, Instances, Steps, Formulare, Timer-Jobs
  • Notifications (14 Modelle): Templates, Adapter-Konfigurationen, Digest-Puffer, Push-Abos
  • Contracts & Licenses (9 Modelle): Publishers, Products, Assignments
  • Audit & Compliance (5 Modelle): Events, Chain-Head, Aufbewahrung, Legal-Hold, Aktivitätsprotokoll
  • Knowledge Base (14 Modelle): Articles, Revisionen, E-Library, Tags
  • CronJobs & Automation (6 Modelle): Jobs, Executions, Worker-Instances, Heartbeats
  • Weitere (26 Modelle): SLA & Business Hours, E-Mail-Postfächer, Anhänge, Reports, Kostenstellen, Einstellungen, Ansichten

3. Security & Compliance

3.1 SHA-256 Audit-Chain

Die Audit-Chain ist das Herzstück der Compliance-Features:

Funktionsweise

  1. Jedes Audit-Event erhält einen SHA-256 Hash über ein kanonisches Ereignis-Objekt: actorId + actorType + occurredAt + domain + category + action + entityType + entityId + changes + metadata + outcome + orgId + sequence + prevHash
  2. Der prevHash verknüpft das Event mit dem vorherigen Event (Blockchain-Prinzip)
  3. Ein DB-Trigger berechnet den Hash während des Inserts (serverseitig erzwungen, nicht über die Anwendung umgehbar); ein zweiter Trigger weist UPDATE und DELETE auf der Kette ab
  4. AuditChainHead speichert lastHash und lastSequence pro Organisation
  5. Manipulation eines historischen Events würde die gesamte Kette brechen
  6. Ein nächtlicher Systemjob prüft die Ketten abschnittsweise durch (Kontinuität, Purge-Anker) und fasst das Ergebnis je Kette zusammen; greift eine Schutzgrenze gegen Endlosläufe, weist der Lauf das ausdrücklich aus. Bei einer Abweichung geht ein kritischer Alarm an die Compliance-Verantwortlichen — die Kette überwacht sich selbst

Automatisches PII-Scrubbing

Der AuditScrubber verarbeitet automatisch:

  • Denylist (immer geschwärzt): password, token, apiKey, secret, jwt, credentials, privateKey, ssn
  • PII-Felder (erkannt/markiert): email, phone, iban, creditCard, passport, nationalId, address, gps
  • Pattern-Erkennung (geschwärzt): Bearer-Tokens, AWS-Keys, Base64-Secrets, Private Keys (-----BEGIN)

Markierung: containsPII: boolean und redactedFields: string[]

Redis-Fallback

Events werden in Memory-Buffer gepuffert (5s Flush-Intervall). Bei DB-Ausfall: Fallback zu Redis (7-Tage TTL). Automatic Recovery beim Service-Start. CRITICAL Events werden sofort geflushed.

3.2 Zero-Trust Virus-Scanning

Scan-Orchestrierung und Dateizugriff sind getrennte Prozesse:

Architektur-Prinzip

  • AV-Worker hat KEINEN Dateizugriff: Sendet nur Pfade an Virus-Scanner via TCP
  • Virus-Scanner liest vom eigenen Volume: Read-Only Mount der Upload-Directory
  • Kein Dateizugriff im Worker: Der Worker-Container hat kein Upload-Volume und kann infizierte Dateien nicht öffnen
  • Backend handhabt Quarantine: Attachment-Status = INFECTED, 7-Tage Retention

Scan-Workflow

  1. Backend API liefert Attachments mit Status PENDING
  2. Optimistic Locking: PENDING → SCANNING (409 bei Conflict)
  3. AV-Worker sendet Pfad an Virus-Scanner: zSCAN /app/uploads/...
  4. Virus-Scanner scannt (2-Minute Timeout), Response: OK oder FOUND
  5. Result-Reporting: CLEAN / INFECTED / ERROR zurück zum Backend
  6. Backend setzt Attachment-Status und handhabt Quarantine

3.3 4-Augen-Prinzip

Multi-Approver-System mit flexiblen Strategien:

ALL (Standard)
Alle Approver müssen genehmigen. Härteste Stufe. Standard für Changes.
ANY
Ein beliebiger Approver kann genehmigen. Schnellere Freigabe.
MAJORITY
Mehr als 50% der Approver müssen zustimmen. Demokratische Entscheidung.
QUORUM
Konfigurierbare Mindestanzahl an Genehmigungen. Flexibel skalierbar.
Approval Groups
Benannte Gruppen mit Mitgliederverwaltung. Fristen pro Genehmigung.
Self-Approval-Schutz
Bei Changes können Antragsteller und zugewiesener Bearbeiter nicht selbst genehmigen. Separation of Duties. Genehmiger müssen das passende Recht halten.

Auto-Approval

Approval-Logik via Conditions:

  • Field-basiert: amount < 1000 → Auto-Approve
  • Permission-basiert: User hat tickets.delete → Auto-Approve
  • Role-basiert: User ist ADMIN → Auto-Approve

3.4 Weitere Security-Features

  • SSRF-Protection: IP-Range Blocking (127.*, 10.*, 172.16-31.*, 192.168.*, 169.254.*), DNS-Validierung, Cloud-Metadata-Blocking (AWS/Azure/GCP)
  • RBAC-Caching: Rechte-Matrix je Rolle in Redis (5min TTL) über der Datenbank. Jede ändernde Anfrage und jede kritische Aktion liest die Rechte frisch aus der Datenbank.
  • Entra ID SSO: OAuth 2.0, Group-to-Role Mapping mit Priority-Konfliktauflösung, Auto-Sync
  • Session Management: 12h Max Duration (Server-side), Token-Blacklist (Redis), HttpOnly Cookies
  • MFA/TOTP: Multi-Faktor-Authentifizierung für alle User. TOTP mit HMAC-SHA256, 6 Stellen, 30-Sekunden-Fenster; das Secret liegt AES-256-GCM-verschlüsselt. Konfigurierbar pro User in den Security-Settings.
  • FIPS-140-2-kompatible Kryptografie: Passwort-Hashing PBKDF2-SHA512 mit 210.000 Iterationen, TOTP HMAC-SHA256, AES-256-GCM. Ein Strict-FIPS-Modus über ein eigenes Docker-Image ist optional zuschaltbar. (FIPS-140-2-kompatible Algorithmen, keine FIPS-Zertifizierung.)
  • DSGVO Data-Breach-Flow: Integrierter Meldeprozess bei Incidents. Evidence-Checklisten. Kategorie-Management für Incident-Typen.
  • Redis Authentication: Passwort-geschützter Redis-Zugang für zusätzliche Absicherung der Cache- und Queue-Layer.

3.1 Datenschutz & Betroffenenrechte (DSGVO)

Das System unterstützt die Umsetzung der DSGVO-Betroffenenrechte technisch — die rechtliche Bewertung bleibt beim Betreiber:

  • • Auskunft & Datenübertragbarkeit (Art. 15/20): maschinenlesbarer JSON-Export aller Daten einer Person — als Self-Service (rate-limitiert) und für Admin/Datenschutzbeauftragte.
  • • Löschung (Art. 17): als Anonymisierung umgesetzt — personenbezogene Daten werden unwiderruflich überschrieben, das Skelett bleibt für die fachliche Vorgangs-Historie. Ein Preflight-Check löst aktive Beteiligungen geordnet auf, statt Prozesse zu zerreißen; eine Lösch-Sperre (Legal Hold) schützt vor verfrühter Löschung bei Aufbewahrungspflichten.
  • • Aufbewahrung & Datensparsamkeit: ein zentraler nächtlicher Job setzt konfigurierbare Aufbewahrungsfristen für Logs, Audit-Events, Telemetrie und Report-Exporte durch; Telemetrie-IPs werden gekürzt gespeichert.
  • • Revisionssichere Protokollierung: verkettete Audit-Historie (SHA-256), in der nachträgliche Änderungen erkennbar werden; personenbezogene Felder werden dabei automatisch redigiert, die Aufbewahrung erfolgt über einen hash-erhaltenden, zweistufigen Purge.
  • • Verschlüsselung at-rest: alle Zugangsdaten (SMTP, Microsoft-365, Entra ID, Messaging-Adapter), Lizenzschlüssel und MFA-Secrets werden mit AES-256-GCM verschlüsselt gespeichert.
  • • Besondere Kategorien (Art. 9): gesundheitsnahe Daten wie Krankmeldungs-Gründe werden ohne Sonderberechtigung maskiert.
  • • Transparenz: öffentlich erreichbare Datenschutzerklärung und Impressum mit live gepflegten Speicherfristen.

Hinweis: Die genannten Funktionen unterstützen den datenschutzkonformen Betrieb; sie stellen keine Rechtsberatung dar und keine Zertifizierung. Die Konfiguration von Fristen, Verantwortlichkeiten und Datenschutzerklärung obliegt dem Betreiber.

4. Kern-Module

50+ Domain-Module decken alle Aspekte eines modernen ITSM ab. Highlights:

ITSM Core
Tickets (inkl. Sub-Tickets), Incidents, Problems, Changes mit Status-Maschinen & Reopen-/Lifecycle-Governance
Asset Management
Clustering, Relations, QR/PDF-Handover, Policies
Workflow Engine
8 Node-Typen, Auto-Approval, SLA, Timer-Events
Contracts & Licenses
Software-Publisher, Compliance-Tracking
CronJobs & Automation
Scheduled Jobs mit UI, 29 Action-Types, 24 eingebaute Vorlagen, Multi-Instance Ready
Knowledge Base
KB-Artikel, E-Library, Tag-System

5. Workflow-Engine

5.1 Node-Typen (8 Stück)

MANUAL_TASK
Manuelle Aufgabe für User. Status: ASSIGNED → wartet auf Completion.
APPROVAL
Genehmigungsschritt. Auto-Approval/Reject möglich.
AUTOMATED_ACTION
Email, Webhook, Ticket-Ops. Sofort COMPLETED.
NOTIFICATION
Versand per E-Mail; weitere Kanäle steuert das zentrale Benachrichtigungs-System. Sofort COMPLETED.
DATA_COLLECTION
Formularerfassung. Wartet auf User-Submit.
TIMER_EVENT
Zeitverzögerung (Fix oder Termin). TimerChecker löst aus.
PARALLEL_GATEWAY
Verzweigt in parallele Stränge; der Schritt selbst ist sofort COMPLETED (kein Join-Knoten).
CONDITIONAL_BRANCH
Bedingte Routing-Logik mit Condition-Evaluator.

5.2 SLA-Monitoring

Ein Hintergrund-Job prüft laufend alle offenen Zielzeiten:

  • Status: OK → WARNING (ab 80 % verbrauchter Zielzeit) → BREACH (Frist überschritten) → CRITICAL (über eine Stunde darüber)
  • Eskalation: frei definierbare Stufen je Richtlinie — ausgelöst nach Prozentwert, bei Verletzung oder nach Zeit seit der Verletzung
  • Aktionen: Benachrichtigen, neu zuweisen, Priorität anheben, Webhook — plus optionale Erinnerung in Intervallen, solange die Verletzung besteht

Prüfintervall: 2 Minuten (über die Cronjob-Verwaltung anpassbar). Business-Hours-Berechnung; abwesende Agenten fallen aus der Zuweisungs-Auswahl.

6. SLA-Management

6.1 Entity-spezifische SLAs

Das System unterstützt SLAs für 3 Entity-Typen: Tickets, Incidents, Problems. Zielzeiten werden je Priorität in einer Richtlinie gepflegt — konfigurierbar, nicht fest im Code. Die mitgelieferten Standard-Richtlinien starten mit:

Tickets
CRITICAL: 10min Response, 1h Resolution. URGENT: 15min/2h. HIGH: 1h/8h. MEDIUM: 4h/24h. LOW: 8h/48h.
Incidents
P1: 15min Response, 1h Resolution. P2: 30min/4h. P3: 2h/24h. P4: 8h/48h.

Response-Ziel: Bei Tickets zählt die erste öffentliche Antwort eines Agenten; bei Incidents und Problems die Übernahme (ITIL-Acknowledge).

6.2 Business Hours Intelligence

  • • Automatische Feiertags-Berücksichtigung: Land + Region (z.B. Bayern)
  • • Timezone-aware: Europe/Berlin, UTC, etc.
  • • Pause/Resume: SLA pausiert bei ON_HOLD (konfigurierbar), solange das Ticket an einer offenen Störung hängt, und am Elternticket, solange ein Sub-Ticket offen ist (je SLA-Richtlinie schaltbar)
  • • Nur Business-Minutes zählen: 4h-SLA Mo 16:00 → Di 11:00 (nicht Mo 20:00!)

6.3 Eskalation (frei konfigurierbar)

Stufen, Auslöser und Aktionen definiert jede Organisation selbst. Ein typisches Muster:

Stufe 1: 80 % verbraucht
Benachrichtigung an Bearbeiter + Gruppenleitung
Stufe 2: Frist überschritten
Neuzuweisung an Eskalationsgruppe oder Person + Manager-Kette
Stufe 3: Zeit nach Verletzung
Priorität anheben (setzt die Zielzeiten neu) oder Webhook

Zusätzlich: wiederkehrende Erinnerung in festem Intervall, solange die Verletzung ungelöst bleibt (mit Obergrenze). Über welchen Kanal zugestellt wird, steuern zentral die Benachrichtigungs-Einstellungen und Nutzer-Präferenzen.

7. Cost Management & Contracts/Licenses

7.1 Automatische Kostenberechnung

Beliebige Billing-Cycles werden automatisch normalisiert:

Beispiele

  • €100 je 2 Wochen (Lizenz mit Wochen-Intervall) → €216,67/Monat → €2.600/Jahr
  • €150 quartalsweise → €50/Monat → €600/Jahr
  • €1000 jährlich → €83,33/Monat → €1.000/Jahr
  • €15/Seat × 50 Seats = €750/Monat bei Seat-basierter Lizenz

7.2 Vertragstypen & Lizenzmodelle

7 Vertragstypen

  • • LICENSE_SUBSCRIPTION
  • • LICENSE_VOLUME
  • • MAINTENANCE
  • • SUPPORT / SLA
  • • LEASE
  • • OTHER

12 Lizenztypen

  • • PERPETUAL, SUBSCRIPTION
  • • VOLUME, OEM, SITE
  • • USER, DEVICE, CONCURRENT
  • • TRIAL, FREEWARE
  • • OPEN_SOURCE, OTHER

7.3 TCO-Forecasting & Compliance

  • • Upcoming Renewals: Renewal-Kalender über einen frei wählbaren Zeitraum (Standard 12 Monate); Ablauf-Erinnerungen an konfigurierbaren Meilensteinen (Standard 30, 7, 3 und 0 Tage)
  • • Seat-Tracking: Purchased vs. Used. Over-Assignment Detection.
  • • Verschlüsselte Keys: AES-256-GCM mit IP-Logging beim Abruf
  • • Bulk-Ops: Massenhafte Link/Unlink, Status-Änderungen, Assignments
  • • Exports: CSV/XLSX/PDF mit vollständigem Audit-Trail

8. Deployment & Skalierung

Docker Compose Deployment

Single-Command Start: docker compose up -d --build

  • Volumes: postgres_data, redis_data, uploads, quarantine, clamav_data, sourcemaps
  • Networks: gemeinsames Compose-Netz; Traefik routet über eine dateibasierte Konfiguration (File-Provider)
  • Health-Checks: alle 12 Container; der Live-Zustand steht im Admin-Center → System → System-Status (/admin/system-status)
  • Structured JSON-Logging: Alle eigenen Container loggen im strukturierten JSON-Format mit traceId, spanId, correlationId, requestId und Service-Identifier. Kompatibel mit Elastic Stack, Datadog, Grafana Loki etc.
  • Restart-Policy: unless-stopped

Multi-Instance Support

Distributed Locks (Redis-basiert) ermöglichen Active-Active-Deployments. Job-Worker, Workflow-Engine und Timer-Checker nutzen Global Locks für Koordination.

9. Integrationen

Verfügbar

  • Traefik API-Gateway: Reverse-Proxy mit TLS-Terminierung, automatischem Routing und Rate-Limiting
  • Entra ID SSO: OAuth 2.0, Group-to-Role Mapping mit Priority-Konfliktauflösung, Auto-Sync
  • Microsoft Teams (Bot Framework): Notification-Adapter über das Bot Framework mit OAuth-2.0-Client-Credentials
  • Webex: Notification-Adapter für Cisco Webex Teams
  • IMAP/SMTP: Multi-Mailbox-Support für Mailbox-Polling und Versand via BullMQ Queue, TLS-Verifikation je Postfach konfigurierbar. Individuelle E-Mail-Signaturen pro Mailbox. Sichtbarkeitssteuerung: Tickets aus bestimmten Mailboxen nur für autorisierte Benutzer, Rollen und Gruppen sichtbar.
  • Microsoft Graph API: Native Email-Integration ohne IMAP/SMTP, für Empfang und Versand. ProcessReply + Dismiss-Support. E-Mail-Signaturen. Multi-Mailbox-Betrieb.
  • Webhooks: Externe HTTP-Requests mit SSRF-Protection (IP-Range Blocking, DNS-Validierung)
  • REST API: API-Keys für programmatischen Zugriff, Template-Permission-Checks

Geplant

  • Slack: Notification-Adapter für Slack-Channels und Direct Messages

10. Use Cases

Use Case 1: Compliance-orientierter Mittelstand

Szenario: Unternehmen mit ISO 27001-Zertifizierung benötigt mit Manipulationserkennung verkettete, nachvollziehbare Nachweise für alle IT-Änderungen.
Lösung: SHA-256 Audit-Chain protokolliert alle Changes, Problems und Incidents. Chain-Verification belegt die Integrität der Kette. PII-Scrubbing unterstützt die Umsetzung der DSGVO-Anforderungen.

Use Case 2: On-Prem-Anforderung (Datenschutz)

Szenario: Gesundheitsdienstleister darf keine sensiblen Daten in Cloud-SaaS speichern.
Lösung: Vollständiges On-Prem-Deployment via Docker Compose. Anwendung und Daten laufen in der eigenen Umgebung; nur ausdrücklich aktivierte Anbindungen (Entra ID, Teams, Webex, Microsoft Graph) sprechen mit Fremddiensten. Der Zero-Trust-Virenscan prüft jeden Upload lokal ohne externe Dienste; infizierte Dateien landen in Quarantäne und sind nicht herunterladbar.

Use Case 3: Automatisierte Workflows (Employee Onboarding)

Szenario: HR-Onboarding mit Approvals, Asset-Handover, Account-Provisionierung.
Lösung: Workflow-Engine mit 8 Node-Typen orchestriert: 1) APPROVAL (Manager genehmigt), 2) AUTOMATED_ACTION (Account anlegen via Webhook), 3) MANUAL_TASK (IT übergibt Laptop), 4) NOTIFICATION (Welcome-Email). SLA-Monitoring trackt Verzögerungen.

11. Technische Spezifikationen

Backend

  • Runtime: Node.js 24
  • Framework: Express.js
  • ORM: Prisma (PostgreSQL)
  • Auth: JWT (HS256) im HttpOnly-Cookie
  • API: RESTful

Frontend

  • Framework: React 19+
  • Build: Vite
  • UI: Tailwind CSS
  • Webserver: NGINX (statische SPA)
  • HTTPS: Let's Encrypt ready

Datenbank

  • DBMS: PostgreSQL 17+
  • Modelle: 153
  • Zugriff: getrennte DB-Rollen (Backend, Job-Worker, Read-Only)
  • Trigger: Audit-Hash-Berechnung

Cache & Queues

  • Cache: Redis 8+
  • Queues: BullMQ
  • Locks: Redis Distributed Locks
  • Pub/Sub: Redis Channels

Security

  • Virus-Scan: Virus-Scanner
  • Hash: SHA-256 (FIPS-140-2-kompatibel, keine Zertifizierung)
  • Passwords: PBKDF2-SHA512 (210.000 Iterationen)
  • MFA: TOTP HMAC-SHA256
  • Encryption: AES-256-GCM
  • SSO: Entra ID OAuth 2.0

Deployment

  • Container: Docker
  • Orchestration: Docker Compose
  • Volumes: 6 Named Volumes
  • Standard-Ports für HTTP/HTTPS, API, Datenbank

12. Roadmap

Kürzlich implementiert

  • ✅ Reopen-/Lifecycle-Governance: Ticket, Incident & Problem — Reopen-Fenster/-Grund/-Limit mit eigener Permission-Achse
  • ✅ Auto-Close & WC-Auto-Resolve: zeitgesteuertes Schließen gelöster Tickets + Auflösen unbeantworteter Waiting-Customer-Tickets
  • ✅ Stale-Reminder & Reopen-Eskalation: Inaktivitäts-Reminder über alle drei Domänen, Eskalation bei zu häufigem Reopen
  • ✅ Lifecycle-/Reopen-Analytics: Reopen-Rate & Trends im eigenen Dashboard
  • ✅ Unified Workplace & NOC-Dashboard: konfigurierbare Widgets & Echtzeit-Monitoring
  • ✅ Attachment-System-Härtung: isoliertes Quarantäne-Volume, präzise Datei-Typ-Erkennung
  • ✅ Notification-Refactor: konsolidierte Preferences, echtes Queue-Retry (Teams/Webex)
  • ✅ DSGVO Data-Breach-Flow · MFA/TOTP · Entra ID SSO

Geplante Features (2026)

  • ⏳ Slack Integration: Notification-Adapter für Slack-Channels und Direct Messages
  • ⏳ Mobile App (iOS/Android): Native Apps für Agents mit Offline-Support und Push-Notifications (React Native)
  • ⏳ Advanced Analytics: ML-basierte Ticket-Klassifikation, Predictive SLA-Breach Detection, Cost Forecasting mit historischen Daten

© 2026 Eviworx Software UG (haftungsbeschränkt) • Schillerstraße 96, 63263 Neu-Isenburg

info@eviworx.com • https://eviworx.com

Impressum · Datenschutz