Danke ihr lieben für euer Feedback. Das hilft. Ich meine wie bereits angedeutet Änderungen, das wen mal ein Event das in mehreren Kalendern eingetragen wurde geändert wird, dann muss man das entsprechend auch in allen Kalendern anpassen und hat damit doppelte Arbeit und auch doppeltes Potenzial etwas zu vergessen...

Daher macht es sicher Sinn, Events wirklich nur einmalig in den jeweiligen Kalendern zu pflegen und lieber verschiedene Kalender durch abonnieren zusammenzuführen.

Bei der Dienstplanung finde ich es aber dann wiederum Kontraproduktiv mit mehreren Kalender zu arbeiten, da manche Teams voneinander wissen sollen bzw. am selben Event dienen. Oder ist es schon zu spät und ich denke falsch? 🤗

@simons Stimmt genau, vielen Dank für den Hinweis!

@BiKi Danke für das Angebot! Ja, das mit der Zeit kenne ich 😊

Mit .NET habe ich mich ehrlich gesagt noch nie auseinandergesetzt (bin eher für plattformübergreifende Lösungen). Da müsste ich mich erst einmal einarbeiten. Gedanklich bin ich bei einer Lösung als Webservice, die man von jedem Rechner aus triggern kann und welche einem zumindest das ZIP ausspuckt.
Ich denke da nochmal genau drüber nach und würde mich ggf. melden.

Ich antworte mir hier nochmal selbst, da die Follow-Ups für mich tatsächlich in hohem Maße an Attraktivität verlieren, wenn ich das Email-Intervall nicht einstellen kann.

Beispiel onboarding: Ich habe eine Gruppe "Erste Schritte", die Gäste beim Weg in die Gemeinde begleiten soll. Es gibt verschiedene "Meilensteine" (zu Willkommen-abend einladen, KG empfehlen, .... irgendwann über Mitgliedschaft sprechen).

Ich nutze die FUs vor allem als Erinnerung, diverse Gespräche zu führen bzw. Termine auszumachen. Dafür ist das mega gut! Aber wie oben geschrieben, brauche ich diese Erinnerung keinesfalls täglich, schon gar nicht 14 Tage vorher.

Stört das sonst niemand? Oder nutzt ihr die Follow-Ups ganz anders oder gar nicht?

Hallo @thommyb,

danke für den Semantik-Hinweis „split and update" - das war die Lösung. Ich bin noch neu bei ChurchTools und brauche noch ein paar Aha-Effekte, um eure Philosophie im Modell ganz zu verstehen.

Die Selbstkritik zur noch nicht vollständigen Doku nehme ich als sehr positiv und ehrlich wahr. Gleichzeitig seid ihr, was die Automatisierungsmöglichkeiten angeht, sehr vorbildlich und weit und habt die richtigen Weichen gestellt. Dass da immer wieder ein paar Swagger-Einträge fehlen (und immer wieder fehlen werden), ist ein Zeichen für Weiterentwicklung, nicht für Stillstand.

Für alle, die das später über die Suche finden, hier der komplette Weg, da der Endpoint aktuell nicht in der OpenAPI-Spec auftaucht:

Endpoint: POST /api/calendars/{calendarId}/appointments/{appointmentId} - also POST auf den Serien-Termin selbst (die Spec kennt auf diesem Pfad nur GET/PUT/DELETE).

Body: die Felder des herausgelösten Einzeltermins plus die Split-Parameter - analog zum dokumentierten Booking-Split (POST /bookings/{bookingId}):

{ ... "title": "…", "startDate": "2026-08-19T18:00:00Z", "endDate": "2026-08-19T19:00:00Z", "allDay": false, "description": "…", "isInternal": false, "repeatId": 0, "appointmentId": 108879, "splitDate": "2026-08-19", "splitUntilEnd": false ... }

Verifiziert (bei uns): Der Server erledigt alles atomar in einem Request - Einzeltermin wird angelegt (Response enthält die neue ID), die Exception landet in der Serie, und ein am Datum hängendes Event wird samt allen eventServices (inklusive besetzter Dienste) auf den neuen Einzeltermin umgehängt. Verhalten damit identisch zu „Nur diesen Termin ändern" in der UI. Genau das, was wir gebraucht haben.

Eine kleine Anmerkung noch: Ein GET auf die Serie unmittelbar nach dem POST kann die neue Exception noch nicht enthalten (kurzer Verzug).

Danke und viele Grüße
Darijo

@alex-muehlbauer Das fände ich auch gut. Es braucht ja nur das Feld Empfänger mit Optionen Benutzer, Leiterrollen, freie Eingabe. So könnte man sich gut über neue Nutzer in einer Gruppe informieren lassen ohne über alle Änderungen zugespamt zu werden.

Auch für uns wäre es relevant einstellen zu können, ob ein neues Mitglied einer Gruppe den ganzen Chatverlauf bekommt oder nicht.

Dieselbe Funktion wünschen wir uns auch!

@Klausosigus @mwolff Das Feature ist bereits "In Arbeit", siehe Roadmap.

Bildschirmfoto 2026-07-18 um 22.14.41.png

@gbahr sagte in Deutliche Kennzeichnung des Simulationsmodus in Historie und Email:

@alex-muehlbauer das würde ich unterstützen!

Ich würde das auch unterstützen. Mach das so manchmal, dass ich im Namen von jemand anders die ich gerade telefoniere, eine E-Mail verschicke. Dennoch fänd ich es ganz hilfreich, wenn der mein Versand des Kennzeichens würde. Auch wenn der Begriff Simulations noch hilfreich ist, ist eine andere Frage bei Outlook zum Beispiel läuft es im im Auftrag von oder so wie sein guter Vorschlag.

@thommyb Herzlichen Dank für die Hilfe!

@hbuerger wenn du die Kalender in deinen Google Account abonnierst dann kommen sie auch in der android app

@CarstenL
Schau mal hier 🙂
https://churchtools.academy/de/help/system-einstellungen/allgemein-system-einstellungen/wie-fuelle-ich-das-widget-links-und-berechtige-nutzer-dafuer/

Wir möchten gerne, dass unsere User alle Infos über ChurchTools bekommen können und nicht noch in anderen Messengern sein müssen, um alles mitzubekommen. Gelegentlich nutzen wir auch Videos für Ankündigungen und Einladungen. Es wäre daher schön, wenn man Videos im Chat und in Beträgen posten könnte.

@jziegeler - Wir haben dasselbe Problem: 8 Bierzeltgarnituren, die wir als Ressourcen verwalten wollen. ChurchTools soll Mengenangaben zu Ressourcen anbieten, und bei der Buchung gibt man dann die Anzahl an, und ChurchTools soll prüfen, dass nicht zu viel angefragt wird.

Unser aktueller Workaround ist es, acht verschiedene Ressourcen anzulegen:

Bierzeltgarnitur 1 Bierzeltgarnitur 2 Bierzeltgarnitur 3 Bierzeltgarnitur 4 Bierzeltgarnitur 5 Bierzeltgarnitur 6 Bierzeltgarnitur 7 Bierzeltgarnitur 8

Das ist nicht schön. Mir wäre es lieber ChurchTools hätte die in diesem Thread angefragte Funktion. Wann wird das kommen?