Connections
The systems kanman reads and acts in, and what it may do in each.
A connection is a system kanman reads and acts in: your code host, tracker, chat, alerting, service management, wikis and more. A system is connected once for the workspace; each team then chooses what it uses and what kanman may do there:
| Mode | What kanman does |
|---|---|
| Off | Nothing. |
| Ask first | Proposes the action in the team’s chat and does it after one tap on Approve. |
| Automatic | Does it on its own, within the limits your owners and admins set. |
Reading starts as soon as a system is connected. Anything that reaches people outside your team stays off until a team turns it on, and a habit can only narrow what a connection allows, never widen it.
Start with your code host and tracker, then your chat. Every other system is in the Connections catalogue.
In this section
How connections work
Connect a system once for the workspace, then each team chooses what it uses and what kanman may do there: Off, Ask first or Automatic. The safe defaults, a team's connections, health and who connects what.
Connect GitHub
Connect GitHub so kanman can read stories from GitHub Issues, open pull requests and follow your CI.
Connect Jira and GitLab
Use Jira as the tracker and GitLab for the code, including boards with German column names.
Work with kanman in Slack and Microsoft Teams
Connect Slack or Microsoft Teams, choose the places each team talks to kanman, and ask questions, request changes and answer decisions from chat.
Channel modes and guardrails
Decide per channel how much kanman listens, who may turn chat into stories, and when kanman stays quiet.
Connect Microsoft Teams with your own bot
For IT admins: register a single-tenant bot in your own Microsoft tenant and connect it to kanman, then upload the Teams app in the Teams admin center.
Team context and connectors
Give kanman your team's documents, repositories, Confluence, Notion and SharePoint pages so it answers questions with sources, and only from what the asking person may see.
Your own connections: read your processes before the team's connection is approved
Connect a system with your own account, for example your company's Jira and Confluence, so kanman can read your checklists and runbooks for you and suggest habits, while the team's connection is still pending.
Put kanman on call: services and signal sources
Add the services your team runs, connect alerting, paging, error tracking and log systems once for the workspace, map them to your services, and choose what kanman may do when something degrades.
Review ServiceNow incidents: ServiceNow
Connect ServiceNow so kanman reviews every new incident for your team's services: likely causes with evidence, a failing test that reproduces a code cause, and only the actions your team allows in ServiceNow.
Monitoring signals: Prometheus, Grafana and InfluxDB
Let kanman read your metrics and alerts, learn each service's normal, analyse what deviates and act only outside production: findings, fix stories, merge requests and a message to the person on call.
Know the state of your systems: Backstage and Checkmk
Connect your Backstage catalog and Checkmk so kanman knows who owns which system, opens incidents from problems and answers "how is payment-api doing?".
Use kanman from Claude Code or Codex
Connect Claude Code or Codex to kanman with one command and a browser sign-in. Work with stories, answer kanman's questions and ask kanman from your terminal, for every team of your workspace.