Diese Woche haben wir zwei kleine, aber wirkungsvolle Verbesserungen ausgeliefert, die den Alltag erleichtern: einfachere Navigation zwischen zusammenhängenden Aufgaben und vorhersehbare Zustellung ausgehender E‑Mails, wenn Sie einen eigenen SMTP-Anbieter verwenden. Diese Änderungen beseitigen nichtige Klicks und E‑Mail‑Einstellungen, die zwar konfiguriert aussahen, aber nicht genutzt wurden — so kann Ihr Team mit weniger Unterbrechung triagieren, übergeben und kommunizieren.
Nachfolgend finden Sie die Details zu jeder Verbesserung, warum sie in realen Arbeitsabläufen wichtig ist und was (falls nötig) zu tun ist, um sie zu nutzen.
Open blocked tasks and SOP runs directly from the dashboard
Sie können jetzt auf Aufgaben- und SOP‑Run‑Titel im Blocked Items widget klicken, um die zugehörige Aufgabe oder den Run zu öffnen. Zuvor sahen diese Titel zwar klickbar aus, navigierten aber nicht; jetzt führen sie Sie direkt zum entsprechenden Element.
Warum das wichtig ist: Wenn jemand einen Run oder eine Aufgabe als blockiert markiert, möchten Sie in der Regel schnell prüfen, worin die Blockade besteht und eine Entscheidung treffen. Der Sprung vom Dashboard direkt in die betreffende Aufgabe oder den Run spart Zeit und reduziert Kontextwechsel.
Was Sie sofort davon haben:
Klickbare Aufgaben- und SOP‑Run‑Titel im Blocked Items widget, die das Element direkt öffnen.
Schnellere Triage mit weniger Schritten zwischen dem Entdecken eines blockierten Elements und dem Anzeigen von Details, Kommentaren oder Verantwortlichen.
Klarere Zusammenarbeit, weil Sie Teammitglieder direkt auf das besprochene Element bringen können.
How teams typically use this
Incident Response: ein blockierter Run wird gesehen und sofort geöffnet, um Logs, Owner und Historie einzusehen.
Sprint‑Planung: Aufgaben, die den Fortschritt blockieren, identifizieren und direkt aufrufen, um nächste Schritte zuzuweisen.
Kundenarbeit: bei Bedarf direkt zum problematischen Run springen, um Kontext mit Stakeholdern zu teilen.
Wenn Sie das Blocked Items widget für tägliche Standups oder On‑Call‑Triage nutzen, sollten dadurch bei jedem Auftreten eines blockierten Elements ein paar Klicks eingespart werden.
Click through "Blocked By" and "Blocking" from project and sprint pages
Wenn Sie eine Aufgabe aus Projekt‑ oder Sprint‑Seiten im task drawer ansehen, verhalten sich die Einträge Blocked By und Blocking jetzt wie echte Links und navigieren zur zugehörigen Aufgabe. Zuvor wirkten diese Karten interaktiv, öffneten die referenzierte Aufgabe jedoch nicht aus Sprint‑ oder Projektkontexten.
Warum das wichtig ist: Blocker sind ein relationales Problem — zu wissen, von was eine Aufgabe blockiert wird oder was sie blockiert, ist genauso wichtig wie die Aufgabe selbst. Sofortige Navigation erhält den Untersuchungsfaden ohne manuelle Suche.
Für die Nutzer sichtbare Verbesserungen hier:
Tippen Sie auf eine blockierende oder abhängige Aufgabe im Task‑Drawer und springen Sie direkt dorthin.
Kontext beibehalten beim Prüfen von Aufgaben innerhalb einer Sprint‑ oder Projektansicht.
Manuelle Nachschau verringern, wenn man einer Kette blockierter Aufgaben folgt.
Beispiel: Wenn Aufgabe A anzeigt, dass sie von Aufgabe B blockiert wird, klicken Sie auf diesen Eintrag, um das Drawer von Aufgabe B zu öffnen und Assignee, Notizen oder Run‑Historie zu prüfen — keine zusätzliche Suche erforderlich. Das hilft besonders bei Sprint‑Grooming und beim Lösen teamübergreifender Abhängigkeiten.
Outbound email now follows your SMTP configuration
Wenn Sie SMTP credentials für ausgehende E‑Mails konfigurieren (z. B. durch Setzen Ihres SMTP‑Hosts), verwendet das Backend nach einem erneut bereitstellen nun Ihren SMTP‑Provider. Zuvor wurden E‑Mails in manchen Deployments weiterhin über den Standard‑Pfad gesendet, selbst wenn SMTP konfiguriert war.
Warum das wichtig ist: Viele Teams nutzen ihre eigene SMTP‑Infrastruktur oder einen bevorzugten Transaktionsanbieter für Zustellbarkeit, Compliance oder Branding. Wenn Ihre Einstellungen nicht genutzt wurden, führte das zu Verwirrung und erforderte manuelle Nachverfolgung.
Was Sie tun müssen, um das zu aktivieren
Stellen Sie sicher, dass Ihre SMTP settings (Host, Port, Username, Password, TLS‑Einstellungen usw.) in Ihrer Deployment‑Umgebung konfiguriert sind.
Erneut bereitstellen Sie Ihr OKiDO‑Backend mit den vorhandenen SMTP‑Einstellungen, damit der Service sie übernimmt.
Senden Sie eine Testbenachrichtigung aus OKiDO (z. B. eine Aufgaben‑Zuweisung oder Run‑Benachrichtigung) und bestätigen Sie die Zustellung über Ihren SMTP‑Provider oder Ihr Postfach.
Quick checklist to verify SMTP is active
Überprüfen Sie, dass SMTP‑Host und Zugangsdaten in Ihrer Deployment‑Konfiguration vorhanden sind.
Bereitstellen Sie den Service erneut, damit das Backend die neuen Einstellungen liest.
Verwenden Sie die integrierte Test‑E‑Mail oder lösen Sie eine einfache Benachrichtigung aus, um die Zustellung zu prüfen.
Falls die Zustellung fehlschlägt, prüfen Sie die Logs Ihres Providers auf Authentifizierungs‑ oder Relay‑Fehler und bestätigen Sie Zugangsdaten und Konnektivität.
Wenn Sie zuvor einen SMTP‑Provider konfiguriert haben, aber Nachrichten weiterhin über den Standard‑Zustellpfad liefen, überprüfen Sie Ihre SMTP‑Einstellungen erneut und stellen Sie neu bereit — Ihre ausgehenden E‑Mails sollten dann dem von Ihnen angegebenen SMTP‑Provider folgen.
Making it work for your team
Diese Updates sind an der Oberfläche klein, lösen aber zwei häufige operative Ärgernisse: unsichtbare Links und unklare E‑Mail‑Routings. Beides betrifft Vertrauen — das Vertrauen, dass ein Klick Sie dorthin bringt, wo Sie hinwollen, und das Vertrauen, dass Ihre ausgehenden E‑Mail‑Einstellungen tatsächlich genutzt werden.
Probieren Sie das neue Verhalten in Ihrem Workspace aus. Wenn etwas Unerwartetes auftritt — Links, die immer noch nicht navigieren, oder E‑Mails, die Ihre SMTP‑Einstellungen nicht nutzen — senden Sie eine Nachricht an den Support oder öffnen Sie ein Ticket, und wir untersuchen das. Ihr Feedback hilft uns, die Plattform für Ihre Arbeit verlässlich zu halten.
