Verbindungen
Die Systeme, die Ihr Workspace verbunden hat, und alle übrigen, mit denen sich kanman verbindet: Code-Hosts, Tracker, Chat, Wikis, ITSM und Monitoring. Die eigene Seite jedes Systems, wofür kanman es nutzen kann, die sicheren Standards, wie Teams es nutzen und wer was verbindet.
kanman arbeitet in den Werkzeugen, die Ihr Team schon nutzt. Workspace-Einstellungen > Verbindungen (/<workspace>/settings/connections) zeigt oben unter Verbundene Systeme die Systeme, die Ihr Workspace verbunden hat. Darunter, unter System hinzufügen, stehen alle übrigen Systeme, mit denen sich kanman verbinden kann, gruppiert danach, was sie für Ihr Team tun: Code und Auslieferung, Arbeit und Planung, Betrieb, Wissen, Daten und Dateien, Menschen und Kommunikation, Qualität und Sicherheit und Allgemein (MCP-Server und Webhooks).
Ein System wird einmal für den ganzen Workspace verbunden. Erst dann können Teams es nutzen: Jedes Team wählt in seinen eigenen Einstellungen, was es nutzt, etwa welche Repositories, welches Jira-Projekt oder welche ServiceNow-Gruppen.
Ältere Links auf die früheren Seiten Code-Hosts, Tracker und Chat sowie Treffer der Einstellungssuche öffnen die Seite des passenden Systems.
Verbundene Systeme
Jedes verbundene System hat eine Zeile, die auf einen Blick zeigt:
- Seinen Namen, und den Namen der Verbindung, wenn Sie ein System mehrfach verbunden haben, etwa zwei Jira-Sites. Jede Verbindung hat dann eine eigene Zeile.
- Aus der kanman-Cloud verbunden oder Über deinen Runner verbunden (für Systeme in Ihrem Firmennetz, etwa ein selbst betriebenes GitLab oder ServiceNow hinter Ihrem VPN).
- Welche Teams es nutzen.
- Eine Zeile dazu, was kanman damit tut.
- Seinen Zustand: In Ordnung, Braucht Aufmerksamkeit, Noch nicht getestet, Weniger Rechte als zuvor (ein späterer Test fand, dass das Konto weniger darf), Ungewöhnlich still (ein System, das sonst Alarme oder Tickets schickt, ist viel länger still als üblich) oder Länger kein Erfolg.
System hinzufügen
Zuerst suchen: Tippen Sie einen Namen oder einfach, was Sie brauchen, etwa „Tickets", „Alarme", „CI", „Wiki" oder „Fehler", und die passenden Systeme erscheinen sofort, die besten Treffer zuerst. Mit ↓ gelangen Sie vom Suchfeld in die Treffer, mit ↑ und ↓ zwischen ihnen, Enter öffnet einen, Escape führt zurück ins Feld. Die Chips unter der Suche grenzen die Liste auf eine Gruppe ein.
Für dich empfohlen listet Systeme, auf die die Repositories Ihrer Teams schon hinweisen, jeweils mit einem kurzen Grund, etwa „Nutzt SENTRY_DSN in acme/api" oder „sonar-project.properties in acme/web". kanman schaut dabei nur auf Dateinamen und die Namen von Umgebungsvariablen, nie auf deren Werte.
Ohne Suche zeigt jede Gruppe zuerst ihre meistgenutzten Systeme; Alle … zeigen listet den Rest der Gruppe. Mit Beta markierte Systeme funktionieren und werden gerade mit weiteren Teams geprüft.
Findet die Suche nichts, wählen Sie „…" anfragen, um uns zu sagen, welches System Sie brauchen. Wir notieren es und sagen Ihnen Bescheid, sobald sich kanman damit verbindet.
Die eigene Seite eines Systems
Klicken Sie auf eine Zeile, um die eigene Seite des Systems zu öffnen, etwa /<workspace>/settings/connections/jira. Haben Sie ein System mehrfach verbunden, hat jede Verbindung ihre eigene Seite mit einem kurzen Code nach dem Namen (jira-3fa9c1). Sie können diese Links als Lesezeichen speichern oder teilen; Zurück zu Verbindungen führt zurück zur Liste.
Jede Seite beginnt mit Wofür kanman es nutzen kann: eine kurze Beschreibung und eine Liste dessen, was kanman mit dem System tut, etwa Ihre Repositories lesen, eigene Merge Requests nach dem Review öffnen und mergen oder Incidents lesen. Danach folgen für jedes System dieselben Teile:
- Verbindung: wie Sie es verbinden und welche Verbindungen es schon gibt, mit Verbindung testen, das zeigt, welche Rechte kanman je Nutzungsart hat. Zugangsdaten werden unter einem Secret-Namen gespeichert und nie wieder angezeigt. Systeme mit Anmeldung, etwa Linear und Google Sheets, bieten stattdessen Anmelden: Speichern Sie die Verbindung, wählen Sie dann Autorisieren und melden Sie sich beim System an. Die Verbindung zeigt danach Autorisiert als und das Konto; läuft der Zugang ab, sagt sie das, und Neu verbinden meldet Sie erneut an. Bei manchen Systemen können Sie sich auch anmelden, statt ein Token einzugeben (Google Sheets, Linear, Vercel (das installiert die Vercel-Integration von kanman für das Team, das Sie wählen), Azure DevOps Services mit Ihrem Microsoft-Konto und MCP-Server mit eigener Anmeldung): Wählen Sie Anmelden, speichern Sie und klicken Sie auf Autorisieren. Sie stimmen im Fenster des Systems zu und kommen auf die Seite zurück, die dann Autorisiert als mit dem genutzten Konto zeigt. kanman erneuert die Anmeldung selbst; geht das nicht mehr, zeigt die Seite Autorisierung abgelaufen und Neu verbinden. Systeme, die jedes Team selbst einrichtet (Alarmquellen, Checkmk, Backstage, Webhooks), verlinken stattdessen auf die Seite jedes Teams.
- Zuordnung: wo jedes Team wählt, was es von diesem System nutzt.
- Lesen: was kanman von sich aus liest, sobald das System verbunden ist. Lesen ändert nie etwas im System.
- Aktionen: sobald verbunden, die Grenze des Workspace für jede Aktion: das Höchste, was ein Team kanman erlauben darf. Eigentümer und Admins setzen die Grenzen; Teams wählen innerhalb davon. Bevor ein System verbunden ist, zeigt die Liste, wie jede Aktion startet.
- Zustand: pro Verbindung, wann sie zuletzt funktioniert hat, ihr letztes Problem und welche Rechte der letzte Test je Nutzungsart gefunden hat.
- Teams: die Teams, die das System nutzen. Jeder Name öffnet die Einstellungen dieses Teams dafür.
Logos
Manche Systeme werden mit dem Logo ihres Herstellers gezeigt, wo der Hersteller das erlaubt; alle anderen zeigen ein neutrales Symbol. Produktnamen und Logos kennzeichnen nur die Systeme, mit denen sich kanman verbindet, wie der Hinweis unten auf diesen Seiten sagt. kanman steht mit diesen Unternehmen nicht in Verbindung und wird von ihnen nicht empfohlen.
Was kanman tun darf: sichere Standards
kanman überrascht Sie in keinem anderen System:
- Lesen ist an, sobald ein System verbunden ist.
- Alles, was Menschen oder Kunden außerhalb Ihres Teams erreicht (ein für Kunden sichtbarer Kommentar, eine Nachricht, ein Alarmruf), ist Aus, bis ein Team es einschaltet, und läuft nie ohne Rückfrage.
- Interne Schreibvorgänge mit geringem Risiko, etwa eine Arbeitsnotiz an einem Incident, starten mit Erst fragen: kanman schlägt sie im Teamraum vor und führt sie nach einem Tipp auf Freigeben aus.
- Nichts läuft Automatisch, bis ein Team es so wählt, und nur innerhalb der Grenzen, die Eigentümer und Admins für den Workspace setzen. Die eine Ausnahme lässt alles, wie es war: Auf GitHub und GitLab bleiben kanmans eigene Arbeit an den Repositories, die ein Team verbunden hat (seine Branches pushen, seine Merge Requests öffnen und nach Ihren Merge-Regeln und Review-Vorgaben mergen, CI wiederholen), und was kanman schon an der Arbeit von Menschen erledigt hat (deren Merge Requests reviewen, wo das Team es eingeschaltet hat, verknüpfte Issues aktuell halten), Automatisch. In Jira bleibt ebenfalls Automatisch, was kanman schon für ein Team erledigt hat (seine Issues anlegen, ändern, verschieben und kommentieren, Merge Requests verknüpfen, Personen im Team antworten, die kanman erwähnen). Alles Neue an der Arbeit von Menschen, etwa jemanden einem Issue zuweisen, startet mit Erst fragen, und Branches anderer löschen oder den Branch-Schutz ändern wird gar nicht angeboten. Jedes Team kann jede dieser Aktionen auf seiner Seite Verbindungen herunterstufen.
Die Verbindungen eines Teams
Jedes Team hat seine eigene Seite Team > Verbindungen (/<workspace>/teams/<team>/team/connections). Sie listet nur die Systeme, die Ihr Workspace verbunden hat, jeweils mit Zustand und dem, was kanman damit tut. Eigentümer und Admins sehen zusätzlich einen Link, um weitere Systeme für den Workspace zu verbinden; alle anderen sehen nur, was verbunden ist.
Klicken Sie auf ein System, um es für dieses Team in einem Panel zu öffnen:
- wofür kanman es nutzen kann und wie es der Verbindung geht;
- was das Team ihm zuordnet, etwa seine Kanäle oder Projekte, und was kanman dort für dieses Team tun darf, innerhalb der Grenzen des Workspace (das ändern die Leads des Teams, Eigentümer und Admins);
- für Eigentümer und Admins ein Link zur Seite des Systems in den Workspace-Einstellungen.
Dasselbe Panel öffnet sich überall, wo kanman ein verbundenes System nennt, etwa in den nächsten Schritten einer Incident-Prüfung.
Jede Verbindung auf einen Blick
Jedes Werkzeug hat eine Zeile mit seinem Zustand:
- Verbunden: Die Verbindung funktioniert. Die Zeile nennt das Konto oder die Site, zum Beispiel „Deine Verbindung als ada“ bei GitHub.
- Braucht Aufmerksamkeit: kanman kann die Verbindung nicht mehr nutzen, etwa weil ein Token abgelaufen ist oder der Zugriff entzogen wurde. Verbinden Sie sie neu.
- Kein Zustand und ein Knopf Verbinden (oder Verknüpfen): Das Werkzeug ist noch nicht verbunden.
Schlagen Aufrufe an ein System wiederholt fehl, etwa weil ein Token widerrufen wurde oder das System nicht mehr antwortet, pausiert kanman seine Aufrufe an diese Verbindung, statt es immer wieder zu versuchen. kanman sagt den Teams, die die Verbindung nutzen, in ihrem Chat Bescheid und markiert sie mit Braucht Aufmerksamkeit. Beheben Sie die Ursache und wählen Sie Verbindung testen: Sobald der Test klappt, nutzt kanman die Verbindung wieder.
Verbinden öffnet immer die Anmeldung des Anbieters oder ein kurzes Formular in einem Fenster, eine Verbindung wird also erst gespeichert, wenn sie vollständig ist. Alles andere steht im Menü ⋯ der Zeile. Dort ist auch Trennen, und es fragt vorher nach: Die Bestätigung nennt, welche Teams betroffen sind und was nicht mehr funktioniert. Eine Verbindung, die Teams nutzen, sagt das in ihrer Zeile, zum Beispiel Von 3 Teams genutzt: bei einem Code-Host die Teams mit einem Repository dort, bei Jira die mit der Site verknüpften Teams, bei Slack die Teams mit einem Kanal, bei einem Wiki die Teams, die daraus lesen.
Wer was verbindet
| Verbindung | Wer sie verbindet |
|---|---|
| GitHub, GitLab | Jede Person verbindet ihr eigenes Konto. Für die Repositories eines Teams nutzt kanman das Konto des Admins, der das Team einrichtet. |
| kanman GitHub App | Inhaber und Admins installieren sie. |
| Jira | Inhaber und Admins. |
| Slack | Wer kanman in Slack installiert; diese Person kann es auch wieder trennen. |
| Microsoft Teams | Inhaber und Admins verknüpfen die Organisation. |
| Confluence, Notion, SharePoint | Inhaber und Admins. |
Alle anderen sehen diese Zeilen mit einem kurzen Hinweis an der Stelle des Knopfs und wissen so, wen sie fragen können.
Code
GitHub und GitLab haben jeweils eine eigene Seite unter Code und Auslieferung und werden wie jedes andere System verbunden. Die Verbindung gehört dem Workspace: Jedes Team nutzt sie für seine Repositories. Inhaber und Admins klicken auf der Seite auf GitHub verbinden (oder GitLab verbinden):
- GitHub: Wählen Sie als Anmeldung Anmelden, speichern Sie und klicken Sie auf Autorisieren; GitHub fragt nach Ihrer Bestätigung und leitet Sie zurück. Für GitHub Enterprise Server geben Sie stattdessen seine Adresse und ein Token oder Schlüssel ein. Unter den Verbindungen zeigt die kanman GitHub App die Konten, auf denen sie installiert ist; mit der App nutzen Runs kurzlebige Tokens, die auf ein Repository beschränkt sind. Siehe GitHub verbinden.
- GitLab: Wählen Sie Anmelden für gitlab.com, oder geben Sie die Adresse Ihres GitLab und ein Zugriffstoken als Token oder Schlüssel ein. Für ein GitLab, das nur Ihr Firmennetz erreicht, wählen Sie unter Erreicht aus Dein Runner (in deinem Netz): Die kanman Cloud nimmt dann nie Kontakt zu ihm auf, und Ihr Runner erledigt alle Arbeit damit. Siehe Jira und GitLab verbinden.
Verbindung testen prüft die Verbindung (über Ihren Runner, wenn er sie erreicht) und zeigt, was kanman damit tun darf. Eine Verbindung, die nicht mehr funktioniert, etwa weil ihr Token abgelaufen ist, ist mit Braucht Aufmerksamkeit markiert: Tragen Sie vorher mit Bearbeiten ein neues Token ein. Ältere Links auf die frühere Karte Code öffnen GitHub.
Die Repository-Auswahl der Team-Einrichtung und unter Team > Repositories nutzt die Verbindung des Workspaces. Gibt es noch keine, verbinden Inhaber und Admins sie direkt dort; alle anderen werden auf die Seite des Code-Hosts hier verwiesen.
Tracker
GitHub- und GitLab-Issues kommen mit ihrem Code-Host und stehen deshalb nicht noch einmal hier. Jira ist ein System der Liste wie jedes andere: Jira Cloud (Adresse der Site, E-Mail und API-Token) oder Jira Data Center (Adresse und persönliches Zugriffstoken, aus der kanman Cloud oder über Ihren Runner), mit einem Verbindungstest, der zeigt, was kanman nutzen darf. Auch die Team-Einrichtung verbindet es an Ort und Stelle. Jedes Team wählt dann sein Jira-Projekt und unter Team > Verbindungen, was kanman in Jira tun darf. Siehe Jira und GitLab verbinden.
Chat
Slack und Microsoft Teams gehören zum Team-Tarif. Ohne ein Team mit Team-Tarif zeigt die Karte, welcher Tarif sie enthält, siehe Tarife und Abrechnung.
Slack: Klicken Sie auf Slack verbinden und bestätigen Sie in Slack. Ist Slack verbunden, enthält das Menü ⋯ der Zeile Testnachricht senden und Trennen. Welche Kanäle ein Team nutzt, legen Sie im Reiter Team des Teams fest. Teams ohne eigenen Kanal posten in den Ausweichkanal des Workspaces: Öffnen Sie unter der Zeile Teams ohne eigenen Kanal posten in …, um ihn zu wählen. Siehe Entscheidungen in Slack beantworten.
Microsoft Teams: Öffnen Sie Microsoft Teams in der Liste. Auf seiner Seite wählen Inhaber und Admins Verknüpfungscode erstellen: Der Code erscheint mit einem Knopf Kopieren und der Zeit, bis zu der er gilt (30 Minuten). Senden Sie link und den Code in Microsoft Teams an kanman; die Verbindung zeigt dann, dass sie verbunden ist, und Neuen Verknüpfungscode erstellen verknüpft erneut. Siehe Mit kanman in Slack und Microsoft Teams arbeiten.
Wissen
Confluence, Notion und SharePoint sind wie Jira Systeme der Liste: Öffnen Sie ihre Seite, um sie zu verbinden. Teams wählen dann eine Verbindung, wenn sie unter Team > Wissen eine Quelle hinzufügen; hat eine Quelle noch keine Verbindung, verlinkt die Seite des Teams dorthin. Trennen löscht den gespeicherten Zugang, und die Quellen, die Teams daraus hinzugefügt haben, werden nicht mehr aktualisiert; was kanman schon gelesen hat, bleibt, bis das Team die Quelle entfernt. Siehe Verbindungen für Notion und SharePoint.
SharePoint gehört zum Team-Tarif. Ohne ihn zeigt seine Seite, welcher Tarif es enthält.
Weitere Systeme
Jedes dieser Systeme hat einen eigenen Eintrag in der Liste. Lesen ist an, sobald es verbunden ist; alles, was Menschen oder Kunden erreicht, bleibt Aus, bis ein Team es einschaltet.
- Asana: liest Aufgaben, Kommentare und Meilensteine; kann Aufgaben kommentieren oder anlegen.
- monday.com: liest Items, ihre Updates und Boards; kann Updates posten oder Items anlegen.
- ClickUp: verfolgt Aufgaben und Kommentare, liest Docs und antwortet, wenn jemand @kanman erwähnt.
- Airtable: liest Bases und Tabellen; kann Zeilen hinzufügen, etwa um ein Protokoll aktuell zu halten.
- Figma: liest Frames und Kommentare und bemerkt, wenn sich ein Design ändert.
- Zapier: empfängt Ereignisse aus Ihren Zaps und kann einen Zap starten, der Tausende weiterer Apps erreicht.
- Zendesk und Freshdesk: lesen Tickets, um zu sehen, welche Kunden ein Problem trifft; interne Notizen, die Kunden nie sehen.
- Intercom: liest Unterhaltungen, fügt interne Notizen hinzu und antwortet, wenn jemand aus dem Team @kanman erwähnt. Antworten an Kunden bleiben aus, bis ein Team sie erlaubt.
- HubSpot: schlägt Firmen und Tickets nach, um zu sehen, welche Kunden ein Problem trifft; Notizen an Tickets.
- Stripe: Zahlungsgesundheit, Umsatz und neue Disputes. Nur lesend: kanman bewegt nie Geld.
- Okta, Microsoft Entra ID und Google Workspace Directory: wer wo arbeitet, in welchen Gruppen und wer wem berichtet; Entra ID zeigt auch, wer abwesend ist.
- Google Kalender: Verfügbarkeiten, Änderungsfenster und Feiertage, bevor kanman Deploys plant oder Menschen fragt.
- Gmail: verschickt Benachrichtigungen und Berichte aus einem Postfach Ihres Google Workspace. kanman liest nie Mails.
- Google Drive & Docs: durchsucht und liest Ihre Docs und Sheets nach Kontext.
- Bitbucket (Cloud und Data Center): Repositories, Pull Requests, Kommentare und Pipelines; reagiert auf Reviews und fehlgeschlagene Builds. Anmelden mit Bitbucket Cloud oder mit einem API- oder Zugriffstoken.
- Jenkins: Builds und Deploy-Jobs, fehlgeschlagene Konsolenausgaben und Testberichte; kann einen wackeligen Job neu bauen.
- Snyk: Issues und verwundbare Abhängigkeiten Ihrer Projekte sowie neue Funde.
- LaunchDarkly und PostHog: Feature-Flags und ihr Targeting; PostHog auch Events, Funnels und Exceptions. Ein Flag abzuschalten, um einen Incident zu stoppen, bleibt aus, bis ein Team es erlaubt.
- Dynatrace: reagiert auf Probleme und liest Logs, Services und Deployments.
- AWS, Google Cloud und Microsoft Azure: Services, Deployments, Kosten, Logs und die Namen von Secrets, nie ihre Werte. Nur lesend.
- Cloudflare: Deployments und Previews von Pages, Zonen und Workers.
- Kubernetes: die Gesundheit Ihrer Workloads, Rollouts und Pod-Logs; kann ein Deployment neu starten, wenn ein Team es erlaubt.
- Supabase und PostgreSQL: Schema, Migrationen und Abfragen nur zum Lesen. PostgreSQL wird nur über Ihren Runner erreicht, am besten auf einem Replikat.
- Mattermost: liest Kanal-Threads und antwortet, wenn jemand kanman erwähnt; auch auf Ihrem eigenen Server über Ihren Runner.
- Miro: liest Boards und ihre Elemente als Design-Kontext.
- Salesforce: schlägt Accounts und Cases nach, um zu sehen, welche Kunden ein Problem trifft.
- Trello und YouTrack: lesen Karten und Issues; YouTrack auch Sprints, Kommentare und Artikel, in der Cloud oder auf Ihrem eigenen Server.
- Zoom: liest Meetings und ihre Transkripte.
- Argo CD, Octopus Deploy und Red Hat OpenShift: Deployments, Sync- und Rollout-Stand, Gesundheit.
- CircleCI, TeamCity und Harness: Pipelines und Builds, fehlgeschlagene Logs und Testergebnisse; Harness auch Feature-Flags.
- Netlify: Deploys und Preview-Adressen.
- HCP Terraform / Terraform Enterprise: Runs und ihre Pläne; bemerkt abgeschlossene Runs.
- Docker Hub, Harbor, JFrog Artifactory und Sonatype Nexus Repository: Images und Pakete sowie ihre Scan-Funde, wo die Registry sie hat.
- Better Stack, Honeycomb, Splunk, Icinga und Zabbix: Alarme und Checks, Logs und Abfragen für Untersuchungen.
- ilert und incident.io: Incidents und wer Rufbereitschaft hat; Menschen zu alarmieren bleibt aus, bis ein Team es erlaubt.
- Firebase Crashlytics: Absturzgruppen aus Ihrem BigQuery-Export.
- Aikido Security, Aqua Trivy und Checkmarx One: Sicherheitsfunde und verwundbare Abhängigkeiten.
- Azure Key Vault: Namen von Secrets und Zertifikaten und wann sie ablaufen, nie ihre Werte.
- Microsoft SQL Server, MySQL / MariaDB, MongoDB und Redis: Nur-Lese-Abfragen auf einem Replikat, Schema und Migrationsstand über Ihren Runner; Redis zeigt Zustand und langsame Befehle, nie Werte.
- Snowflake, Google BigQuery, Databricks und Microsoft Fabric: Nur-Lese-Abfragen mit Zeit- und Kostengrenzen; Databricks und Fabric auch Job- und Pipeline-Runs.
- dbt Cloud und Apache Airflow / Astronomer: Runs, fehlgeschlagene Modelle, Tasks und ihre Logs; bemerkt fehlgeschlagene dbt-Cloud-Runs.
- HashiCorp Vault: Namen, Versionen und Daten von Secrets, nie ihre Werte.
- Mend, OWASP Dependency-Track, Semgrep und OSV.dev: verwundbare Abhängigkeiten und Sicherheitsfunde.
- npm Registry: Paketversionen, Abkündigungen und Downloads.
- BMC Helix ITSM, TOPdesk und Zammad: Incidents, Changes und Tickets; interne Notizen fragen erst nach, Antworten an Kunden bleiben aus, bis ein Team sie erlaubt.
- OpenProject und Redmine: Arbeitspakete und Issues, Versionen und Kommentare, in der Cloud oder auf Ihrem eigenen Server.
- Nextcloud: findet und liest Dateien.
- Typeform: Formulare und ihre Antworten, sobald sie eingehen.
- Metabase, Power BI, Tableau, Amplitude und Google Analytics 4: Dashboards, Berichte und Produktzahlen.
- App Store Connect: Builds, TestFlight und Bewertungen; auf eine Bewertung zu antworten bleibt aus, bis ein Team es erlaubt.
- BrowserStack (mit Percy): Testsitzungen und Builds für den visuellen Review.
- Active Directory / LDAP und Keycloak: Personen und Gruppen aus Ihrem Verzeichnis; LDAP wird über Ihren Runner gelesen.
- E-Mail (IMAP): liest die neuesten Nachrichten eines Postfachs über Ihren Runner, ohne sie als gelesen zu markieren.
- Personio: wer wann abwesend ist, damit kanman darum herum plant.
- Microsoft Dynamics 365 und Pipedrive: Accounts, Cases und Deals, um zu sehen, welche Kunden ein Problem trifft.
- SendGrid: Bounces, Sperren und Zustellzahlen; bemerkt Häufungen fehlgeschlagener Zustellungen.
- Twilio, Discord und Google Chat: Nachrichten und Anrufe; an Menschen zu senden bleibt aus, bis ein Team es erlaubt.
- Google Play Console: Releases, Tracks und Bewertungen; auf eine Bewertung zu antworten bleibt aus, bis ein Team es erlaubt.
- Matomo, Mixpanel und Langfuse: Produktzahlen und Traces Ihrer KI-Funktionen.
- Phrase: Übersetzungsstand und fehlende Schlüssel.
- Postman: Collections, APIs und Monitor-Ergebnisse.
- TestRail und Xray: Testläufe und ihre Ergebnisse.
- Unleash: Feature-Flags und ihr Zustand je Umgebung; ein Flag umzuschalten bleibt aus, bis ein Team es erlaubt.
- DigitalOcean, Hetzner Cloud und Port: Server, Apps, Deployments, Kosten und Ihr Service-Katalog.
- Red Hat Ansible Automation Platform / AWX: Jobs und Job-Templates; eines zu starten bleibt aus, bis ein Team es erlaubt.
- Make, n8n und Microsoft Power Automate: Szenarien, Workflows und Flows, die kanman aufrufen oder die kanman starten kann.
- Box und Dropbox: finden und lesen Dateien.
Gmail, Google Kalender, Google Drive & Docs, das Google-Workspace-Verzeichnis und Microsoft Entra ID bieten Anmelden mit Ihrem Google- oder Microsoft-Konto; der Schlüssel eines Dienstkontos oder eine App-Registrierung funktioniert ebenso.
Verwandte Seiten
Zuletzt aktualisiert: January 1, 0001
kanman öffnen