Connections

kanman works inside the tools your team already uses. Workspace settings > Connections (/<workspace>/settings/connections) shows the systems your workspace connected at the top, under Connected systems. Below, under Add a system, it lists every other system kanman can connect to, grouped by what it does for your team: Code and delivery, Work and planning, Operations, Knowledge, data and files, People and communication, Quality and security and Generic (MCP servers and webhooks).

A system is connected once for the whole workspace. Only then can teams use it: each team chooses in its own settings what it uses, for example which repositories, which Jira project or which ServiceNow groups.

Older links to the former pages Code hosts, Trackers and Chat, and links from the settings search, open the matching system’s page.

Connected systems

Each connected system has a row that shows at a glance:

• Its name, and the connection’s name when you connected a system more than once, for example two Jira sites. Each connection then has a row of its own.
• Connected from kanman’s cloud or Connected through your runner (for systems inside your company network, such as a self-hosted GitLab or ServiceNow behind your VPN).
• Which teams use it.
• One line on what kanman does with it.
• Its health: Healthy, Needs attention, Not tested yet, Fewer rights than before (a later test found the account may do less), Unusually quiet (a system that usually sends alerts or tickets has been silent for much longer than usual) or No recent success.

Add a system

Search first: type a name or simply what you need, such as “tickets”, “alerts”, “CI”, “wiki” or “errors”, and the matching systems appear right away, best match first. Use ↓ to move from the search field into the results, ↑ and ↓ between them, Enter to open one and Escape to go back to the field. The chips below the search narrow the list to one group.

Recommended for you lists systems your team’s repositories already point to, each with a short reason, for example “Uses SENTRY_DSN in acme/api” or “sonar-project.properties in acme/web”. kanman only looks at file names and the names of environment variables, never their values.

Without a search, each group shows its most used systems first; Show all lists the rest of the group. Systems marked Beta work and are being verified with more teams.

If the search finds nothing, choose Ask for “…” to tell us which system you need. We note it and let you know when kanman connects to it.

A system’s own page

Click a row to open the system’s own page, for example /<workspace>/settings/connections/jira. When you connected a system more than once, each connection has its own page with a short code after the name (jira-3fa9c1). You can bookmark or share these links; Back to Connections takes you back to the list.

Every page starts with What kanman can use it for: a short description and a list of what kanman does with the system, for example reading your repositories, opening and merging its own merge requests after review, or reading incidents. Then come the same parts for every system:

• Connection: how to connect it and the connections you already have, with Test connection, which shows the rights kanman has for each kind of use. Credentials are stored under a secret name, never shown again. Systems you sign in to, such as Linear and Google Sheets, offer Sign in instead: save the connection, then choose Authorize and sign in with the system. The connection then shows Authorized as and the account; when the access expires it says so, and Reconnect signs in again. Some systems also let you Sign in instead of entering a token (Google Sheets, Linear, Vercel (this installs kanman’s Vercel integration for the team you choose), Azure DevOps Services with your Microsoft account, and MCP servers that offer their own sign-in): choose Sign in, save, and click Authorize. You agree in the system’s own window and come back to the page, which then shows Authorized as the account you used. kanman renews the sign-in on its own; when that is no longer possible, the page shows Authorization expired and Reconnect. Systems that each team sets up on its own (alert sources, Checkmk, Backstage, webhooks) link to each team’s page instead.
• Mapping: where each team chooses what it uses of this system.
• Reads: what kanman reads on its own once the system is connected. Reading never changes anything in the system.
• Actions: once connected, the workspace’s limit for each action: the most any team may allow kanman. Owners and admins set the limits; teams choose within them. Before a system is connected, the list shows how each action starts.
• Health: per connection, when it last worked, its last problem and the rights the last test found for each kind of use.
• Teams: the teams that use the system. Each name opens that team’s settings for it.

Logos

Some systems are shown with their vendor’s logo where the vendor allows it; all others show a neutral icon. Product names and logos only identify the systems kanman connects to, as the note at the bottom of these pages says. kanman is not affiliated with or endorsed by these companies.

What kanman may do: safe defaults

kanman never surprises you in another system:

• Reading is on as soon as a system is connected.
• Anything that reaches people or customers outside your team (a customer-visible comment, a message, a page) is Off until a team turns it on, and it never runs without asking.
• Low-risk internal writes, such as a work note on an incident, start at Ask first: kanman proposes them in the team room and does them after one tap on Approve.
• Nothing is Automatic until a team chooses it, and only within the limits owners and admins set for the workspace. The one exception keeps things as they were: on GitHub and GitLab, kanman’s own work on the repositories a team connected (pushing its branches, opening and merging its merge requests under your merge rules and review requirements, retrying CI) and what it already did on people’s work (reviewing their merge requests where the team turned that on, keeping linked issues up to date) stay Automatic. In Jira, what kanman already did for a team (creating, updating, moving and commenting on its issues, linking merge requests, answering people on the team who mention it) stays Automatic too. Anything new on people’s work, such as assigning someone to an issue, starts at Ask first, and deleting other people’s branches or changing branch protection is not offered at all. Each team can lower any of these on its Connections page.

A team’s connections

Each team has its own page Team > Connections (/<workspace>/teams/<team>/team/connections). It lists only the systems your workspace connected, each with its health and what kanman does with it. Owners and admins also see a link to connect more systems for the workspace; everyone else sees only what is connected.

Click a system to open it in a panel for this team:

• what kanman can use it for and how the connection is doing;
• what the team maps to it, for example its channels or projects, and what kanman may do there for this team, within the workspace’s limits (the team’s leads, owners and admins change these);
• for owners and admins, a link to the system’s page in the workspace settings.

The same panel opens wherever kanman names a connected system elsewhere, for example in the next steps of an incident review.

Each connection at a glance

Every tool has one row with its state:

• Connected: the connection works. The row names the account or site, for example “Your connection as ada” on GitHub.
• Needs attention: kanman can no longer use the connection, for example because a token expired or access was revoked. Connect it again.
• No state and a Connect (or Link) button: the tool is not connected yet.

When calls to a system keep failing, for example because a token was revoked or the system stops answering, kanman pauses its calls to that connection instead of trying again and again. It tells the teams that use the connection in their chat and marks it Needs attention. Fix the cause and choose Test connection: as soon as the test passes, kanman uses the connection again.

Connecting always opens the provider’s sign-in or a short form in a panel, so a connection is only saved once it is complete. Everything else sits in the row’s ⋯ menu. Disconnect is there too, and asks first: the confirmation says which teams and what stops working. A connection that teams use says so in its row, for example Used by 3 teams: for a code host the teams with a repository on it, for Jira the teams linked to the site, for Slack the teams with a channel, for a wiki the teams that read from it.

Who connects what

Everyone else sees these rows with a short note where the button would be, so you always know whom to ask.

Code

GitHub and GitLab each have their own page under Code and delivery, and connect like every other system. The connection belongs to the workspace: every team uses it for its repositories. Owners and admins click Connect GitHub (or Connect GitLab) on the page:

• GitHub: choose Sign in as the way kanman signs in, save, and click Authorize; GitHub asks you to confirm and sends you back. For GitHub Enterprise Server, enter its Address and a Token or key instead. Below the connections, the kanman GitHub App lists the accounts it is installed on; with the App, runs use short-lived tokens limited to one repository. See Connect GitHub.
• GitLab: choose Sign in for gitlab.com, or enter your GitLab’s Address and an access token as Token or key. For a GitLab that only your company network reaches, choose Your runner (inside your network) under Reached from: kanman’s cloud then never contacts it, and your runner does all work on it with the token. See Connect Jira and GitLab.

Test connection checks the connection (through your runner for one it reaches) and shows what kanman may do with it. A connection that stops working, for example because its token expired, is marked Needs attention: connect a new token with Edit before then. Older links to the former Code card open GitHub.

The repository pickers of the team setup and of Team > Repositories use the workspace’s connection. When there is none yet, owners and admins connect it right there; everyone else is pointed to the code host’s page here.

Trackers

GitHub and GitLab issues come with their code host, so they are not listed again. Jira is a system of the list like any other: Jira Cloud (site address, email and API token) or Jira Data Center (address and personal access token, from kanman’s cloud or through your runner), with a connection test that shows what kanman may use. The team setup connects it in place too. Each team then chooses its Jira project and, under Team > Connections, what kanman may do in Jira. See Connect Jira and GitLab.

Chat

Slack and Microsoft Teams are part of the Team plan. Without a team on Team, the card shows which plan includes them, see Plans and billing.

Slack: click Connect Slack and confirm in Slack. Once connected, the row’s ⋯ menu has Send test message and Disconnect. Which channels a team uses is set on the team’s own Team tab. Teams without a channel of their own post to the workspace’s fallback channel: open Teams without their own channel post to… under the row to choose it. See Answer decisions from Slack.

Microsoft Teams: open Microsoft Teams in the list. On its page, owners and admins choose Create a link code: the code appears with a Copy button and the time it stays valid (30 minutes). Send link and the code to kanman in Microsoft Teams; the connection then shows as connected, and Create a new link code links again. See Work with kanman in Slack and Microsoft Teams.

Knowledge

Confluence, Notion and SharePoint are systems of the list like Jira: open their page to connect them. Teams then pick a connection when they add a source in Team > Knowledge; if a source has no connection yet, the team’s page links to it. Disconnecting deletes the stored access, and the sources teams added from it stop refreshing; what kanman already read stays until the team removes the source. See Connections for Notion and SharePoint.

SharePoint is part of the Team plan. Without it, its page shows which plan includes it.

More systems

Each of these systems has its own entry in the list. Reading is on once connected; anything that reaches people or customers stays Off until a team turns it on.

• Asana: reads tasks, comments and milestones; can comment on tasks or create them.
• monday.com: reads items, their updates and boards; can post updates or create items.
• ClickUp: follows tasks and comments, reads Docs and answers when someone mentions @kanman.
• Airtable: reads bases and tables; can add rows, for example to keep a log up to date.
• Figma: reads frames and comments and notices when a design changes.
• Zapier: receives events from your Zaps and can start a Zap, which reaches thousands of other apps.
• Zendesk and Freshdesk: read tickets to see which customers a problem affects; internal notes that customers never see.
• Intercom: reads conversations, adds internal notes and answers when a teammate mentions @kanman. Replies to customers stay off until a team allows them.
• HubSpot: looks up companies and tickets to see which customers a problem affects; notes on tickets.
• Stripe: payment health, revenue and new disputes. Read only: kanman never moves money.
• Okta, Microsoft Entra ID and Google Workspace Directory: who works where, in which groups and who reports to whom; Entra ID also shows who is away.
• Google Calendar: availability, change windows and public holidays before kanman plans deploys or asks people.
• Gmail: sends notifications and reports from a mailbox of your Google Workspace. kanman never reads mail.
• Google Drive & Docs: searches and reads your Docs and Sheets for context.
• Bitbucket (Cloud and Data Center): repositories, pull requests, comments and pipelines; reacts to reviews and failed builds. Sign in with Bitbucket Cloud, or use an API or access token.
• Jenkins: builds and deploy jobs, failed console output and test reports; can rebuild a flaky job.
• Snyk: issues and vulnerable dependencies of your projects, and new findings.
• LaunchDarkly and PostHog: feature flags and their targeting; PostHog also events, funnels and exceptions. Turning a flag off to stop an incident stays off until a team allows it.
• Dynatrace: reacts to problems and reads logs, services and deployments.
• AWS, Google Cloud and Microsoft Azure: services, deployments, costs, logs and the names of secrets, never their values. Read only.
• Cloudflare: Pages deployments and previews, zones and Workers.
• Kubernetes: the health of your workloads, rollouts and pod logs; can restart a deployment when a team allows it.
• Supabase and PostgreSQL: schema, migrations and read-only queries. PostgreSQL is reached only through your runner, ideally on a replica.
• Mattermost: reads channel threads and answers when someone mentions kanman; also on your own server through your runner.
• Miro: reads boards and their items for design context.
• Salesforce: looks up accounts and cases to see which customers a problem affects.
• Trello and YouTrack: read cards and issues; YouTrack also sprints, comments and articles, in the cloud or on your own server.
• Zoom: reads meetings and their transcripts.
• Argo CD, Octopus Deploy and Red Hat OpenShift: deployments, sync and rollout state, health.
• CircleCI, TeamCity and Harness: pipelines and builds, failed logs and test results; Harness also feature flags.
• Netlify: deploys and preview addresses.
• HCP Terraform / Terraform Enterprise: runs and their plans, and notices finished runs.
• Docker Hub, Harbor, JFrog Artifactory and Sonatype Nexus Repository: images and packages, and their scan findings where the registry has them.
• Better Stack, Honeycomb, Splunk, Icinga and Zabbix: alerts and checks, logs and queries for investigations.
• ilert and incident.io: incidents and who is on call; paging people stays off until a team allows it.
• Firebase Crashlytics: crash groups from your BigQuery export.
• Aikido Security, Aqua Trivy and Checkmarx One: security findings and vulnerable dependencies.
• Azure Key Vault: names of secrets and certificates and when they expire, never their values.
• Microsoft SQL Server, MySQL / MariaDB, MongoDB and Redis: read-only queries on a replica, schema and migration state through your runner; Redis shows health and slow commands, never values.
• Snowflake, Google BigQuery, Databricks and Microsoft Fabric: read-only queries with time and cost limits; Databricks and Fabric also job and pipeline runs.
• dbt Cloud and Apache Airflow / Astronomer: runs, failed models, tasks and their logs; notices failed dbt Cloud runs.
• HashiCorp Vault: names, versions and dates of secrets, never their values.
• Mend, OWASP Dependency-Track, Semgrep and OSV.dev: vulnerable dependencies and security findings.
• npm Registry: package versions, deprecations and downloads.
• BMC Helix ITSM, TOPdesk and Zammad: incidents, changes and tickets; internal notes ask first, replies to customers stay off until a team allows them.
• OpenProject and Redmine: work packages and issues, versions and comments, in the cloud or on your own server.
• Nextcloud: finds and reads files.
• Typeform: forms and their responses, as they come in.
• Metabase, Power BI, Tableau, Amplitude and Google Analytics 4: dashboards, reports and product numbers.
• App Store Connect: builds, TestFlight and reviews; replying to a review stays off until a team allows it.
• BrowserStack (with Percy): test sessions and visual review builds.
• Active Directory / LDAP and Keycloak: people and groups from your directory; LDAP is read through your runner.
• Email (IMAP): reads recent messages of a mailbox through your runner, without marking them read.
• Personio: who is absent and when, so kanman plans around it.
• Microsoft Dynamics 365 and Pipedrive: accounts, cases and deals, to see which customers a problem affects.
• SendGrid: bounces, blocks and delivery numbers; notices spikes of failed deliveries.
• Twilio, Discord and Google Chat: messages and calls; sending to people stays off until a team allows it.
• Google Play Console: releases, tracks and reviews; replying to a review stays off until a team allows it.
• Matomo, Mixpanel and Langfuse: product numbers and traces of your AI features.
• Phrase: translation progress and missing keys.
• Postman: collections, APIs and monitor results.
• TestRail and Xray: test runs and their results.
• Unleash: feature flags and their state per environment; switching a flag stays off until a team allows it.
• DigitalOcean, Hetzner Cloud and Port: servers, apps, deployments, costs and your service catalog.
• Red Hat Ansible Automation Platform / AWX: jobs and job templates; launching one stays off until a team allows it.
• Make, n8n and Microsoft Power Automate: scenarios, workflows and flows that call kanman or that kanman can start.
• Box and Dropbox: find and read files.

Gmail, Google Calendar, Google Drive & Docs, the Google Workspace Directory and Microsoft Entra ID offer Sign in with your Google or Microsoft account; a service account key or an app registration works as well.

Related pages

• Connect GitHub
• Connect Jira and GitLab
• Work with kanman in Slack and Microsoft Teams
• Team context and connectors
• Workspace, members and roles