Event-Erstellung: Ist-Zustand & Anforderungen zur Optimierung

Analyse des aktuellen Prozesses und Anforderungskatalog für eine dynamische, modulare Event-Erstellung

Dieses Dokument ist auch als Word-Datei verfügbar: DOCX herunterladen

Teil 1: Ist-Zustand – Was passiert aktuell bei der Event-Erstellung?

1.1 Übersicht Gesamtprozess

Die Event-Erstellung durchläuft zwei Phasen: eine manuelle Eingabe in der Power App und eine automatische Backend-Verarbeitung durch Power Automate Flows.

Gesamtablauf auf einen Blick

Organizer öffnet die App → Navigiert zu „Create new event“
Wählt einen von 3 Event-Typen (B2Run, JP Morgan, Other Deloitte Event)
Füllt das jeweilige feste Formular aus
Klickt „Submit“ → Datensatz wird in SharePoint-Liste Events gespeichert
SharePoint-Trigger löst den Hauptflow NewEventAdded_SiteProvis aus
Flow erstellt automatisch: Subsite, Teilnehmerliste, Outlook-Termin, Benachrichtigung, Berechtigungen

1.2 Phase 1: Eingabe in der Power App

1.2.1 Event-Typ-Auswahl (EventCreationSelectionScreen)

Der Organizer sieht drei Kacheln mit Logo und Beschreibung:

Kachel	Navigiert zu	Setzt Content Type auf
B2Run	`EventCreationB2EventForm`	B2Run Event
J.P. Morgan Lauf	`EventCreationJPMorgan`	JP Morgan Run
Other Deloitte Events	`EventCreationOtherEventForm`	Other Deloitte Event

Jeder Event-Typ hat ein eigenes, fest codiertes Formular (separate YAML-Datei mit eigener DataCard-Struktur).

1.2.2 Formularfelder im Detail

Die drei Formulare teilen sich einen gemeinsamen Kern, haben aber je nach Typ zusätzliche Felder:

Feld	Typ	Pflicht?	B2Run	JP Morgan	Other
Title	Text	Ja	✓	✓	✓
Organizer	Multi-Person	Ja	✓	✓	✓
Standort	Choice / Text	B2Run: Nein, JP: Ja	✓	✓	✓
Standort Filter	Dropdown	Nein	✓	–	✓
Event time (Start)	DateTime	Ja	✓	✓	✓
Event end time	DateTime	Ja	✓	✓	✓
Last Register Date Time	DateTime	Ja	✓	✓	✓
Last Deregister Event Time	DateTime	Ja	✓	✓	✓
Event description	Mehrzeil. Text	Ja	✓	✓	✓
Max. parcipients	Number	Ja	✓ (berechnet)	✓	✓
Event image	Attachment	Nein	✓	✓	✓
Content type	Dropdown (hidden)	Nein (auto)	✓	✓	✓
Current parcipients	Number	Nein (auto: 0)	✓	✓	✓
Wait list	Number	Nein (auto: 0)	✓	–	✓
Nur B2Run
Max Fun-runner	Number	Ja	✓	–	–
Durchstarter visible	Toggle	Nein	✓	–	–
Max Durchstarter	Number	Bedingt	✓	–	–
Startblock	Multi-Choice	Ja	✓	–	–
T-Shirt Größe visible	Toggle	Nein	✓	–	–
T-Shirtgrößen	Multi-Choice	Bedingt	✓	–	–
Nordic Walker visible	Toggle	Nein	✓	–	–
Age Group visible	Toggle	Nein	✓	–	–
Nur Other Event / OtherEventForm
Audience Mail	Text	Nein	–	–	✓
Allergien visible	Toggle	Nein	–	–	✓
Essenswünsche visible	Toggle	Nein	–	–	✓
Hotelwunsch visible	Toggle	Nein	–	–	✓
Info Hotel / Einzelzimmer / Doppelzimmer / Location Hotel	Diverse	Nein	–	–	✓
Frage Freitextfeld 1–7	Text	Nein	–	–	✓
Info Freitextfeld 1–7	Text	Nein	–	–	✓
Frage Dropdownfeld 1–2	Text	Nein	–	–	✓
Dropdownfeld 1–2	Text	Nein	–	–	✓
Info Dropdownfeld 1–2	Text	Nein	–	–	✓

1.2.3 Validierung & Submit

Alle drei Formulare verwenden die gleiche Logik:

Submit-Button wird erst aktiv, wenn alle Pflichtfelder ausgefüllt sind (DisplayMode-Prüfung auf IsBlank/IsEmpty).

Bei Klick auf Submit:

SubmitForm(Form) – Datensatz wird in SharePoint-Liste Events geschrieben
ResetForm(Form) – Formular wird zurückgesetzt
Navigate(StartScreen) – Weiterleitung zum Startbildschirm
Notify("Das Event wurde erfolgreich angelegt...") – Erfolgsmeldung

1.3 Phase 2: Automatische Backend-Verarbeitung (Power Automate)

1.3.1 Hauptflow: NewEventAdded_SiteProvis

Wird automatisch ausgelöst durch SharePoint-Trigger „When an item is created“ auf der Events-Liste (Prüfintervall: 1 Minute). Besteht aus 25 Actions in 6 Clustern:

Cluster	Was passiert	Technische Details
1. Initialisierung	Event-Status wird auf „Under Construction“ gesetzt, 6 Workflow-Variablen werden initialisiert	SharePoint PatchItem + 5x InitializeVariable (varSiteTitle, varSiteURL, varSubject-Name, varFinalURL, varContentTypeName)
2. URL-Bereinigung	Event-Titel wird von Sonderzeichen bereinigt für gültige SharePoint-URL	Compose erstellt Filter-Array (Leerzeichen, :, #, %, ", *, ?, /, \, \|), Foreach-Loop entfernt jedes Zeichen iterativ
3. Subsite erstellen	Eigene SharePoint-Subsite für das Event wird angelegt	HTTP POST an `/_api/web/webinfos/add` mit Template STS#3 (Team Site). Response wird geparst für ServerRelativeUrl
4. Template anwenden	Teilnehmerliste mit passendem Spalten-Schema wird erstellt	Switch auf Content Type → Child Flow ApplyTemplateB2Run oder ApplyTemplateOtherEvent
5. Outlook-Termin	Kalender-Event in Shared Mailbox wird erstellt (Basis für spätere Teilnehmer-Einladungen)	Child Flow CreateOutlookEventSharedMailbox. Zurückgegebene Outlook-Event-ID wird in Events-Liste gespeichert. URL bekommt `/Lists/Teilnehmerliste` angehängt
6. Benachrichtigung & Berechtigungen	Organizer erhält Bestätigungsmail mit Link. Bei definierter Audience werden Zugriffsrechte gesetzt	Logos laden (Data-URI), Foreach über Organizer → E-Mail aus Shared Mailbox. Condition prüft Audience Mail → Child Flow EventPermission

1.3.2 Child Flow: ApplyTemplateB2Run

Empfängt die Subsite-URL und erstellt die Teilnehmerliste via SharePoint REST API:

POST an /_api/web/lists → erstellt Liste „Teilnehmerliste“ (Template 100)
Einzelne HTTP-Requests erstellen Felder: Teilnehmername, Email, Status (Choice: Registered/Waitlist/Cancelled), Nr, CheckIn
7 Freitextfelder (Freitextfeld1–7) werden immer erstellt
Standard-Ansicht wird abgerufen, Erfolg wird bestätigt

1.3.3 Child Flow: ApplyTemplateOtherEvent

Identische Struktur wie ApplyTemplateB2Run. Erstellt die gleichen Basis- und Freitextfelder. Separater Flow für potenzielle zukünftige Unterscheidung.

1.3.4 Child Flow: CreateOutlookEventSharedMailbox

Empfängt Event-Details (Titel, Beschreibung, Start, Ende, Ort) → erstellt Outlook-Kalendereintrag via Office 365 Connector → gibt Event-ID zurück.

1.3.5 Child Flow: EventPermission

Wird nur aufgerufen wenn Audience Mail gesetzt ist:

Bestehende Freigaben entfernen
Audience-Gruppe erhält Lesezugriff
Organizer erhält Vollzugriff

1.4 Datenmodell

1.4.1 SharePoint-Liste: Events (Master)

Enthält 38+ Spalten, unabhängig davon ob der Event-Typ sie benötigt:

Titel, Status, Teilnehmerliste URL, Event image, Current parcipients, Max. parcipients, Wait list, Outlook EventID, T-Shirtgrößen, Event end time, ID, Last Deregister Event Time, Organzier, Erstellt von, Max Fun-runner, Current Fun-Runner, Max Durchstarter, Inhaltstyp, Standort, Standort Filter, Last Register Date Time, Startblock, T Shirt Größe visible, Allergien visible, Essenswünsche visible, Audience, Frage Freitextfeld 1–2, Dropdownfeld 1–2, Frage Dropdownfeld 1–2, Info Freitextfeld 1–2, Info Dropdownfeld 1–2, Audience Mail, Location Hotel, Event description

1.4.2 SharePoint-Liste: Teilnehmerliste (pro Event-Subsite)

Jedes Event bekommt eine eigene Teilnehmerliste mit immer denselben Spalten:

Spalte	Typ	Immer vorhanden?
Teilnehmername	Text	Ja – immer
Email	Text	Ja – immer
Status	Choice	Ja – immer
Nr.	Number	Ja – immer
CheckIn	Boolean	Ja – immer
Anrede	Text	Ja – immer
Vorname / Nachname	Text	Ja – immer
HotelRequired / RoomType / PreferredRoommate	Diverse	Ja – auch wenn nicht benötigt
Allergies / FoodPreferences	Text	Ja – auch wenn nicht benötigt
TShirtGroesse	Text	Ja – auch wenn nicht benötigt
Freitextfeld1–7	Text	Ja – immer alle 7
Dropdownfeld1	Text	Ja – auch wenn nicht benötigt
LocationHotel	Text	Ja – auch wenn nicht benötigt
JobTitle / CompanyName / Department / Office*	Text	Ja – immer
Abmeldung am	DateTime	Ja – immer

1.5 Anmelde- und Abmeldeprozess auf Basis der Event-Erstellung

Nach der Event-Erstellung (Subsite + Teilnehmerliste + Outlook-Termin) steht das Event für Teilnehmer zur Anmeldung bereit. Der gesamte Anmelde- und Abmeldeprozess basiert auf der bei der Event-Erstellung angelegten Teilnehmerliste und wird durch mehrere Power Automate Flows gesteuert.

1.5.1 Anmeldung (RegisterParticipant)

Wenn ein Teilnehmer sich über die Power App für ein Event anmeldet, wird ein Eintrag in einer Queue-Liste erstellt. Der Flow RegisterParticipant (SharePoint-Trigger, 5 Minuten Intervall) verarbeitet diese Einträge:

Entscheidungslogik

Event-Daten laden: Aktuelle Teilnehmerzahl und Maximalkapazität aus der Events-Liste abrufen
Kapazitätsprüfung: Ist Current parcipients < Max. parcipients?
Platz frei → Status „Registered“: Eintrag in Teilnehmerliste mit Status „Registered“, Bestätigungsmail über Shared Mailbox, Outlook-Kalender-Eintrag via Child Flow RegisterOutlookEventParticipant
Kein Platz → Status „Waitlist“: Eintrag in Teilnehmerliste mit Status „Waitlist“, Wartelisten-Info an Teilnehmer

Wichtig: Die Anmeldedaten werden in die bei der Event-Erstellung fest angelegte Teilnehmerliste geschrieben. Da diese immer alle möglichen Spalten enthält (vgl. Abschnitt 1.4.2), werden auch Felder befüllt, die für das jeweilige Event gar nicht relevant sind – und umgekehrt bleiben nicht benötigte Spalten leer.

1.5.2 Anmeldeformular (Teilnehmer-Seite)

Das Anmeldeformular in der Power App ist aktuell statisch aufgebaut. Die App zeigt abhängig vom Event-Typ und den „visible“-Toggle-Spalten in der Events-Liste bestimmte Felder an:

Basisfelder (immer sichtbar): Anrede, Vorname, Nachname
Bedingte Felder (abhängig von Toggle): T-Shirt-Größe, Allergien, Essenswünsche, Hotelwunsch, Freitextfelder 1–7, Dropdownfelder 1–2

Die Steuerung erfolgt über If(LookUp(Events, ID=varEventID, 'T Shirt Größe visible'), DisplayMode.Edit, DisplayMode.Disabled) – jedes bedingte Feld hat eine eigene Sichtbarkeitslogik.

1.5.3 Abmeldung (DeregisterParticipant)

Bei einer Abmeldung wird der Flow DeregisterParticipant (SharePoint-Trigger, 5 Minuten Intervall) ausgelöst:

Abmeldeprozess mit automatischer Wartelisten-Nachrückung

Schritt	Aktion	Ergebnis
1	Teilnehmer A meldet sich ab	Status → „Cancelled“, Outlook-Termin wird entfernt
2	Warteliste wird geprüft	Teilnehmer B gefunden (ältester Eintrag, FIFO-Prinzip)
3	Teilnehmer B rückt nach	Status → „Registered“
4	Benachrichtigung	Bestätigungsmail + Outlook-Kalendereintrag für B

FIFO-Prinzip: Die Nachrückung erfolgt strikt nach Eingangsreihenfolge – wer sich zuerst auf die Warteliste gesetzt hat, rückt zuerst nach.

1.5.4 Unterstützende Flows

Flow	Trigger	Funktion
CheckRegistrationStatusParticipant	Power App	Prüft den Anmeldestatus eines Nutzers (registered / waitlist / not_registered). Steuert die Anzeige des passenden Buttons in der App (Anmelden / Abmelden / Von Warteliste entfernen).
GetWaitinglistPosition	Power App	Ermittelt die aktuelle Position eines Teilnehmers auf der Warteliste (FIFO-Sortierung nach Erstelldatum). Position 1 = nächster Nachrücker.
GetParticipantEvents	Power App	Listet alle Events auf, für die ein Nutzer angemeldet ist oder auf der Warteliste steht („Meine Events“-Ansicht).
RegisterOutlookEventParticipant	Child Flow	Fügt einen Teilnehmer zum bestehenden Outlook-Kalendereintrag hinzu (Microsoft Graph API). Wird von RegisterParticipant und DeregisterParticipant (Nachrückung) aufgerufen.

1.5.5 Zusammenspiel Event-Erstellung ↔ Anmeldung

Die bei der Event-Erstellung getroffenen Entscheidungen bestimmen direkt das Verhalten der Anmeldeflows:

Teilnehmerlisten-Struktur: Die Spalten der Teilnehmerliste (Abschnitt 1.4.2) definieren, welche Daten der RegisterParticipant-Flow in die Liste schreiben kann. Da alle Spalten immer erstellt werden, muss der Flow keine dynamische Spaltenlogik beherrschen – er schreibt immer in dieselben festen Spalten.
Kapazität: Max. parcipients aus der Events-Liste steuert die Kapazitätsprüfung im RegisterParticipant-Flow.
Sichtbarkeit: Die „visible“-Toggle-Spalten (z.B. T Shirt Größe visible, Allergien visible) steuern, welche Felder das Anmeldeformular dem Teilnehmer anzeigt.
Outlook-Termin: Die bei der Event-Erstellung angelegte Outlook-Event-ID wird vom RegisterOutlookEventParticipant-Flow genutzt, um Teilnehmer zum bestehenden Termin hinzuzufügen.

Teil 2: Identifizierte Probleme

P1: Starre, dreifach duplizierte Formulare

Es existieren 3 separate Formular-Screens (B2Run: ~1.900 Zeilen YAML, Other: ~3.500 Zeilen, JP Morgan: ~1.200 Zeilen) mit großer Überschneidung. Jede Änderung an gemeinsamen Feldern muss in allen drei Formularen nachgezogen werden.

P2: 4-facher Änderungsaufwand bei Feld-Erweiterungen

Wenn ein neues Feld benötigt wird (z.B. „Dietary Requirements“), muss es an 4 Stellen angepasst werden:

Event-Erstellungsformular in der Power App (DataCard hinzufügen)
Event-Erstellungsflow (Template-Flow muss Spalte in Teilnehmerliste erstellen)
Anmeldeformular in der Power App (Teilnehmer müssen das Feld sehen und ausfüllen)
Anmeldeflow (RegisterParticipant muss das Feld in die Teilnehmerliste schreiben)

P3: Überladene Teilnehmerliste

Jedes Event erhält immer alle möglichen Spalten in der Teilnehmerliste – auch wenn es ein kleines Firmenfest ist, das nur Name und E-Mail braucht. Das führt zu unübersichtlichen Listen mit vielen leeren Spalten.

P4: Keine Vorschau der Anmeldeseite

Der Organizer sieht beim Erstellen eines Events nicht, wie die Anmeldeseite für Teilnehmer später aussehen wird. Fehler in der Konfiguration fallen erst auf, wenn Teilnehmer sich anmelden.

P5: Keine nachträgliche Änderung

Einmal erstellte Events können nicht über die App angepasst werden. Wenn z.B. ein zusätzliches Feld gebraucht wird oder sich die Max-Teilnehmerzahl ändert, muss dies manuell in SharePoint geändert werden.

P6: Zwei nahezu identische Template-Flows

ApplyTemplateB2Run und ApplyTemplateOtherEvent haben die gleiche Struktur und erstellen die gleichen Felder. Zwei Flows zu pflegen für faktisch dieselbe Logik erhöht den Wartungsaufwand unnötig.

Teil 3: Anforderungskatalog – Dynamische Event-Erstellung

3.1 Übersicht Ziel-Architektur

Ist-Zustand

3 feste Formulare
2 Template-Flows
Immer alle Spalten in Teilnehmerliste
Keine Vorschau
Keine nachträgliche Änderung
4-facher Änderungsaufwand

Soll-Zustand

1 dynamisches Formular mit Menükarten-Prinzip
1 universeller Template-Flow mit dynamischer Spaltenliste
Teilnehmerliste nur mit benötigten Spalten
Live-Vorschau der Anmeldeseite
Event nachträglich bearbeitbar
1-facher Änderungsaufwand (Feld-Konfiguration steuert alles)

3.2 Detaillierte Anforderungen

Dynamisches Formular mit Menükarten-Prinzip Hoch
Das bisherige System mit 3 festen Formularen wird durch ein einziges, dynamisches Formular ersetzt. Der Organizer sieht zunächst nur die Basisfelder (Titel, Organizer, Datum, Beschreibung, Max. Teilnehmer, Event-Bild). Darunter befindet sich ein Bereich „Weitere Felder hinzufügen“ mit einer Menükarte.

Menükarte: Verfügbare Feld-Module werden als Kacheln/Chips angezeigt. Per Klick auf „+“ wird das Modul dem Formular hinzugefügt. Beispiele für Module:
- T-Shirt-Größe (mit konfigurierbaren Optionen)
- Allergien / Ernährungswünsche
- Hotel-Buchung (Einzel-/Doppelzimmer, Standort)
- Laufstrecke / Startblock (für Lauf-Events)
- Benutzerdefiniertes Freitextfeld (Frage frei eingebbar)
- Benutzerdefiniertes Dropdown (Frage + Optionen frei eingebbar)
- Audience-Beschränkung
Hinzugefügte Module erscheinen im Formular und können per „×“ wieder entfernt werden.
Feld-Konfiguration als Datenmodell Hoch
Die ausgewählten Felder/Module werden als strukturierte Konfiguration gespeichert (z.B. als JSON-String oder in einer separaten SharePoint-Liste EventFieldConfig). Diese Konfiguration ist die Single Source of Truth und steuert:
- Welche Spalten in der Teilnehmerliste erstellt werden (Event-Erstellungsflow)
- Welche Felder im Anmeldeformular angezeigt werden
- Welche Felder der Anmeldeflow in die Teilnehmerliste schreibt
Damit entfällt der 4-fache Änderungsaufwand. Ein neues Feld-Modul muss nur einmal als Vorlage definiert werden.
Dynamische Teilnehmerliste (nur benötigte Spalten) Hoch
Der Template-Flow (neu: ein einziger universeller Flow, ersetzt ApplyTemplateB2Run und ApplyTemplateOtherEvent) liest die Feld-Konfiguration des Events und erstellt die Teilnehmerliste nur mit den Spalten, die tatsächlich konfiguriert wurden.

Immer erstellt (Basis-Spalten): Teilnehmername, Email, Status, Nr, CheckIn, Anrede, Vorname, Nachname

Nur wenn konfiguriert: HotelRequired, RoomType, TShirtGroesse, Allergies, FoodPreferences, Freitextfeld1–n, Dropdownfeld1–n, etc.

Spaltennamen-Synchronisation: Die Spaltennamen in der SharePoint-Teilnehmerliste müssen exakt den vom Organizer vergebenen Bezeichnungen entsprechen. Wenn der Organizer ein Feld z.B. „Reisekosten“ nennt, muss die entsprechende Spalte in der Teilnehmerliste ebenfalls „Reisekosten“ heißen – nicht ein technischer oder abweichender Name.
Live-Vorschau der Anmeldeseite Hoch
Während der Event-Erstellung sieht der Organizer in einem Vorschau-Panel (z.B. rechte Seite oder unterer Bereich), wie das Anmeldeformular für Teilnehmer aussehen wird. Die Vorschau aktualisiert sich in Echtzeit wenn Module hinzugefügt oder entfernt werden.

Dies umfasst:
- Alle sichtbaren Felder in der Reihenfolge wie sie Teilnehmer sehen
- Pflicht-Markierungen
- Dropdown-Optionen (wenn definiert)
- Info-Texte / Hilfetexte zu Feldern
Nachträgliche Bearbeitung von Events Hoch
Organizer können bestehende Events über die App öffnen und bearbeiten:
- Basis-Daten ändern: Titel, Datum, Max. Teilnehmer, Beschreibung etc.
- Felder hinzufügen: Neue Module können auch nachträglich zum Event hinzugefügt werden. Der Flow erstellt dann die fehlende(n) Spalte(n) in der bestehenden Teilnehmerliste.
- Felder entfernen: Nur möglich wenn noch keine Daten in der Spalte vorhanden sind (oder mit Warnung). Alternativ wird die Spalte nur ausgeblendet aber nicht gelöscht.
Hinweis: Bei nachträglichem Hinzufügen von Spalten haben bereits registrierte Teilnehmer dort keinen Wert – dies muss in der App / Ansicht sauber behandelt werden.
Universeller Template-Flow (Zusammenführung) Mittel
Die beiden bestehenden Flows ApplyTemplateB2Run und ApplyTemplateOtherEvent werden zu einem einzigen Flow zusammengeführt. Dieser erhält als Parameter:
- Subsite-URL
- Feld-Konfiguration (welche Spalten erstellt werden sollen, inkl. Typ und ggf. Choice-Optionen)
Der Flow iteriert dynamisch über die Konfiguration und erstellt nur die definierten Spalten.
Dynamisches Anmeldeformular (Teilnehmer-Seite) Hoch
Das Anmeldeformular für Teilnehmer wird ebenfalls dynamisch aus der Feld-Konfiguration des Events generiert. Teilnehmer sehen nur die Felder, die für dieses spezifische Event konfiguriert wurden.

Analog muss der RegisterParticipant-Flow die Konfiguration lesen und nur die relevanten Felder in die Teilnehmerliste schreiben.
Übersichtliches, sauberes UI-Design Mittel — IN ABSTIMMUNG MIT PROJEKTTEAM DEUTSCHLAND
Das neue Formular soll übersichtlich und intuitiv sein:
- Klare Gruppierung: Basis-Informationen oben, optionale Module darunter
- Menükarte mit Kategorien (z.B. „Verpflegung“, „Unterkunft“, „Sport“, „Benutzerdefiniert“)
- Visuelles Feedback beim Hinzufügen/Entfernen von Modulen
- Responsive Design für mobile Nutzung
- Vorschau-Panel klar abgegrenzt (z.B. als Side-Panel oder Tab)
Event-Vorlagen / Schnellstart Nice-to-have — IN ABSTIMMUNG MIT PROJEKTTEAM DEUTSCHLAND
Vordefinierte Vorlagen für häufige Event-Typen (z.B. „Lauf-Event“, „Firmenfest“, „Konferenz“), die beim Start ausgewählt werden können und das Formular mit den typischen Modulen vorbefüllen. Der Organizer kann danach noch Module hinzufügen oder entfernen.
Rückwärtskompatibilität Mittel
Bestehende Events (mit dem alten System erstellt) müssen weiterhin funktionieren. Die Events-Liste und bestehende Teilnehmerlisten dürfen nicht beschädigt werden. Ideal: Ein Migrations-Mechanismus, der bestehende Events nachträglich mit einer Feld-Konfiguration versieht.

Teil 4: Architekturskizze Soll-Zustand

4.1 Ablauf Event-Erstellung (Neu)

Organizer öffnet App → Klickt „Neues Event erstellen“
Optional: Vorlage wählen (B2Run, Firmenfest, Leer, ...) → Formular wird vorbefüllt
Basisfelder ausfüllen (Titel, Organizer, Datum, Max. Teilnehmer, Beschreibung, Bild)
Module aus Menükarte hinzufügen per „+“-Klick:
- z.B. + T-Shirt → Konfiguration: Welche Größen?
- z.B. + Hotel → Konfiguration: Nur Einzelzimmer? Standort?
- z.B. + Freitextfeld → Eingabe: Frage + Info-Text
Vorschau prüfen: Anmeldeseite wird live im Vorschau-Panel angezeigt
Submit: Event + Feld-Konfiguration werden gespeichert
Flow wird ausgelöst:
- Subsite erstellen (wie bisher)
- Universeller Template-Flow liest Feld-Konfiguration → erstellt nur benötigte Spalten
- Outlook-Termin erstellen (wie bisher)
- Benachrichtigung + Berechtigungen (wie bisher)

4.2 Ablauf Teilnehmer-Anmeldung (Neu)

Teilnehmer öffnet Event in der App
App liest Feld-Konfiguration des Events
Anmeldeformular wird dynamisch generiert – nur die konfigurierten Felder
Teilnehmer füllt aus und klickt „Anmelden“
RegisterParticipant-Flow liest Konfiguration und schreibt nur relevante Felder

4.3 Ablauf Event nachträglich bearbeiten (Neu)

Organizer öffnet bestehendes Event in der App
Formular lädt im Edit-Modus mit bestehender Konfiguration
Organizer kann Basis-Daten ändern und Module hinzufügen/entfernen
Bei „Speichern“: Flow prüft Delta (neue Spalten? entfernte Spalten?) und passt Teilnehmerliste an
Outlook-Termin wird bei Bedarf aktualisiert

4.4 Neues Datenmodell (Entwurf)

Komponente	Beschreibung
Events-Liste (angepasst)	Enthält nur noch Basis-Felder + eine Spalte `FieldConfig` (JSON-String oder Verweis auf Config-Liste). Alle event-typ-spezifischen „visible“-Toggle-Spalten entfallen.
FieldConfig (neu)	Speichert pro Event, welche Module/Felder aktiv sind. Mögliche Struktur: `[{"module": "tshirt", "options": ["S","M","L","XL"], "required": true}, {"module": "freitext", "label": "Allergie?", "info": "Bitte angeben"}, ...]`
Teilnehmerliste (dynamisch)	Wird pro Event individuell zusammengestellt. Nur Basis-Spalten + die aus der FieldConfig abgeleiteten Spalten.

Teil 5: Was entfällt / sich vereinfacht

Aktuell	Neu	Änderung
3 Formular-Screens (B2Run, JP Morgan, Other)	1 dynamischer Formular-Screen	Entfällt: 2 Screens + ~4.700 Zeilen YAML
EventCreationSelectionScreen (Event-Typ-Auswahl)	Optionale Vorlagen-Auswahl im neuen Formular	Entfällt als separater Screen
ApplyTemplateB2Run (Child Flow)	1 universeller ApplyTemplateDynamic Flow	2 Flows → 1 Flow
ApplyTemplateOtherEvent (Child Flow)	1 universeller ApplyTemplateDynamic Flow	2 Flows → 1 Flow
Switch-Logik im Hauptflow (Content Type)	Entfällt – universeller Flow wird immer aufgerufen	Vereinfacht
~20 „visible“-Toggle-Spalten in Events-Liste	1 FieldConfig-Spalte (JSON)	Entfällt: ~20 Spalten
Statisches Anmeldeformular	Dynamisches Anmeldeformular aus FieldConfig	Einmalig umbauen, danach wartungsfrei
4-facher Änderungsaufwand bei neuem Feld	1x Modul-Definition anlegen	75% weniger Aufwand

Teil 6: Zusammenfassung der Anforderungen

ID	Anforderung	Priorität	Löst Problem
ANF-01	Dynamisches Formular mit Menükarten-Prinzip	Hoch	P1, P2
ANF-02	Feld-Konfiguration als Single Source of Truth	Hoch	P2, P3
ANF-03	Dynamische Teilnehmerliste (nur benötigte Spalten)	Hoch	P3
ANF-04	Live-Vorschau der Anmeldeseite	Hoch	P4
ANF-05	Nachträgliche Bearbeitung von Events	Hoch	P5
ANF-06	Universeller Template-Flow	Mittel	P6, P2
ANF-07	Dynamisches Anmeldeformular	Hoch	P2, P3
ANF-08	Übersichtliches UI-Design	Mittel	P1
ANF-09	Event-Vorlagen / Schnellstart	Nice-to-have	P1
ANF-10	Rückwärtskompatibilität	Mittel	–