Mitgelieferte Automatisierungen

Tale liefert acht Automatisierungen mit, und jede Organisation startet mit allen: drei, die ein Postfach in die gemeinsame Inbox holen, drei, die zusammenfassen, was dort ankam, und zwei für GitHub — eine bewertet offene Issues, eine prüft offene Pull Requests. Jede kommt als Version 1 an, mit bereits gebundenem Zeitplan und dem Badge Nicht live; es läuft also nichts, bis ein Inhaber, Admin oder Entwickler den nötigen Connector verbindet und die Automatisierung live schaltet. Diese Seite benennt, was jedes Paket tut, wie oft es läuft und was es braucht; die Mechanik des Live-Schaltens steht in Der Workflow-Editor.

Wie die Pakete ankommen

Die Pakete werden beim Anlegen der Organisation gesät, nicht aus einem Katalog installiert. Das Säen achtet darauf, was schon da ist: Ein Paket, von dem die Organisation bereits irgendeine Version hält, bleibt unangetastet — nur der mitgelieferte Name und die Beschreibung werden aufgefrischt —, und ein Paket, das du gelöscht hast, bleibt gelöscht; ein späteres Deploy holt es nie zurück. Öffne ein Paket wie jede Automatisierung, um sein Dokument auf dem Canvas zu lesen, seine Ausführungsprotokolle zu verfolgen, seinen Trigger zu ändern oder es zu bearbeiten — eine Änderung wird eine neue Version, die du live schaltest, wenn du bereit bist.

Ein Postfach in die Inbox holen

Gmail-E-Mails synchronisieren, Outlook-E-Mails synchronisieren und E-Mails über SMTP/IMAP synchronisieren sind dieselbe Automatisierung dreimal, je einmal pro Postfach-Art. Jede holt alle fünf Minuten neue Nachrichten in Konversationen und deklariert die Ansicht Inbox: Sobald eine davon live ist, erscheint Inbox in der Navigation, und das Verfassen-Formular bietet das verbundene Postfach an — bis dahin verweist die Inbox-Seite auf Automatisierungen. Jede braucht zuerst ihren verbundenen Mail-Connector.

Zusammenfassen, was ankam

Gmail-Posteingang sichten, Outlook-Posteingang sichten und IMAP-Posteingang sichten lesen alle sechs Stunden die neuesten Nachrichten jedes verbundenen Postfachs ihrer Art und schreiben eine Zusammenfassung: kurz, was eingegangen ist, und welche Nachrichten heute offensichtlich eine Antwort brauchen. Die Zusammenfassung ist der Output des Laufs — öffne den Lauf in den Ausführungsprotokollen, um sie zu lesen. Ins Postfach wird nichts zurückgeschrieben, und keine Konversation wechselt ihren Status.

Issues bewerten und Pull Requests auf GitHub prüfen

GitHub-Issues sichten listet einmal täglich um 07:00 UTC die offenen Issues eines Repositorys, bewertet jedes danach, ob es umsetzbar und wie dringend es ist, und liefert eine sortierte Auswahl mit einem Satz Begründung pro Issue. Es liest nur: Nach GitHub wird nichts geschrieben, und auf keinem Board entsteht eine Aufgabe — die Auswahl ist ein Bericht, auf den ein Mensch reagiert. GitHub-Pull-Requests prüfen liest alle dreißig Minuten den Diff jedes offenen Pull Requests, prüft ihn und hinterlässt die Ergebnisse als Review-Kommentar am Pull Request. Genehmigt und gemergt wird nie — das bleibt beim Menschen. Beide brauchen den verbundenen GitHub-Connector.

Wo das hingehört

Acht Pakete, zwei Familien: Mail in die Inbox geholt und zusammengefasst, GitHub bewertet und geprüft — jedes eine normale Automatisierung, die du wie deine eigenen live schaltest, bearbeitest und versionierst. Automatisierungen in deine Organisation bringen behandelt das Bauen auf dem Canvas und das Hochladen eigener Pakete; Der Workflow-Editor das Live-Schalten einer Version; Projekt-Backlog erklärt den Board-Status für vorgeschlagene Arbeit — und warum nichts Mitgeliefertes ihn von selbst füllt.