Team context and connectors

Teams know a lot that is not on the board: runbooks, architecture decisions, the README of a service, a Confluence space, a Notion page, a SharePoint library. Team context lets kanman answer questions from that knowledge, in the team’s chat in kanman and in Slack and Microsoft Teams. Every answer names its sources.

Turn on team context

Team context is off for every team by default.

1. Open the team, then Settings, Knowledge, or ask kanman “Show me the team context” in the team’s chat.
2. Turn on Let kanman answer from team context.
3. Add sources under Add a source (see below).
4. Once a source shows Ready, try it: Ask kanman under the sources brings up the conversation right beside the page. kanman’s answer lists the sources it used under it.

Owners and admins can change the team context; everyone in the team can see which sources it has. The same page also lists the conventions kanman learned from your reviews.

Source types

Give each source a Name, for example “Deployment runbook”, so answers can cite it clearly.

Who may get answers from a source

For each source, choose Who may get answers from it:

• Everyone in the team: everyone in the team who asks kanman may get answers from it.
• Only people with access in the source: kanman checks, for the person who asks, whether they may see the content in the source itself. For Confluence it checks the page permissions of that person. For repositories it checks the person’s access through their own GitHub or GitLab connection. For SharePoint it checks who may open each file, by the person’s email address. If the person has no access, kanman does not use that content in its answer.

Only Confluence, repository and SharePoint sources can be checked this way. For uploads, web pages and Notion there is nothing kanman can check against, so kanman does not use them with Only people with access in the source; choose Everyone in the team for those.

SharePoint permissions

With Only people with access in the source, kanman notes for every file who may open it in SharePoint each time it reads the source, and answers a person only from files they may open:

• people the file is shared with directly, and members of the Microsoft 365 or security groups it is shared with,
• everyone for files shared with “Anyone with the link”, and everyone in your organization for files shared with “People in your organization”.

Site pages, and files that are open to a person only through a SharePoint site group (for example the site’s Owners, Members or Visitors), are not used for anyone, because Microsoft does not tell apps who belongs to those groups. Share the files with a Microsoft 365 group or with people directly if kanman should use them, or choose Everyone in the team. The app registration needs the Microsoft Graph application permissions Sites.Read.All (or Files.Read.All), User.Read.All and GroupMember.Read.All, with admin consent. kanman matches the person by the email address of their kanman account. Permission changes in SharePoint apply after the next update of the source.

Manage sources

Each source under Sources shows its type, who added it, who may get answers from it, when it was last updated and its status:

Click Update now to read a source again right away, or Remove to take it out of the team context. A removed source is no longer used for answers.

Connections for Confluence, Notion and SharePoint

Confluence, Notion and SharePoint sources read through a connection of the workspace. Owners and admins add it once in Workspace settings > Connections, on the Knowledge card: click Connect a wiki (or Add a wiki), and the form opens in a panel. Every team can then pick the connection when it adds a source. If a source needs a wiki that has no connection yet, the team’s Knowledge page links to Connections. See Connections.

• Confluence: enter the Confluence address (the https address of your site), the Account email and an API token of that account, or click Sign in with Atlassian.
• Notion: create an internal integration in Notion, enter its Integration token, and share the pages kanman should read with that integration in Notion.
• SharePoint: enter the Tenant ID, Application (client) ID and Client secret of an app registration in your organization, or click Grant admin consent. See Set up SharePoint.

Click Check and save. kanman checks the connection before it saves it and tells you if the service rejected the credentials or could not be reached. Tokens are stored encrypted and are never shown again. A connection that stops working is marked Needs attention.

Set up SharePoint (for Microsoft 365 admins)

kanman reads SharePoint as an app, never as a person. Choose one of two ways.

Your own app registration (recommended; you decide exactly which sites kanman may read):

1. In the Microsoft Entra admin center, open App registrations, New registration. Name it, for example, “kanman team context”. Supported account types: Accounts in this organizational directory only. No redirect URI is needed.
2. Note the Application (client) ID and the Directory (tenant) ID on the overview page.
3. Open Certificates & secrets, New client secret, and copy its Value (it is shown once). Note when it expires.
4. Open API permissions, Add a permission, Microsoft Graph, Application permissions:
   • Sites.Selected (recommended): the app can read only the sites you grant it. Grant read access per site, for example with PowerShell (Grant-PnPAzureADAppSitePermission -AppId <application id> -DisplayName "kanman team context" -Site <site address> -Permissions Read) or through Microsoft Graph (POST /sites/<site id>/permissions with the role read).
   • or Sites.Read.All: the app can read every site of your organization.
5. Click Grant admin consent for .
6. In kanman, open Workspace settings > Connections, click Connect a wiki on the Knowledge card, choose SharePoint, enter the Tenant ID, Application (client) ID and Client secret, optionally a SharePoint site to test, and click Check and save.

When the client secret expires, add a new connection with the new secret and pick it for your SharePoint sources.

Admin consent to kanman’s Microsoft app (no app registration of your own): click Connect a wiki on the Knowledge card of Workspace settings > Connections, choose SharePoint and click Grant admin consent. A global administrator or privileged role administrator of your Microsoft 365 organization signs in and accepts the permission to read sites. kanman then reads every site the permission covers. You can remove the consent at any time under Enterprise applications in the Microsoft Entra admin center. If the button says that admin consent is not available yet, use your own app registration.

Connectors: your team’s MCP servers

Connectors let kanman read your team’s own tools, for example Sentry, a status page or your internal docs, through their MCP servers. Owners and admins add them in Team settings > Knowledge, on the Connectors card. kanman reads through a connector, and it writes only through write classes an owner or admin approved (see below). Coding runs never get access to connectors.

1. Click Add connector, enter a Name and the Server URL (an https address).
2. Choose How kanman signs in:
   • Sign in with the server (recommended): the server’s own sign-in opens; after you agree, you come back to the card.
   • Access token: a token the server issued. It is stored encrypted and never shown again.
   • No sign-in: for servers that need none.
   • If your workspace runs everything on its own runners, choose Token on your runner and set the variable the card names (for example KANMAN_CONNECTOR_SENTRY_TOKEN) on your runner. The token never leaves your network.
3. kanman lists the server’s tools. Tick the ones kanman may read and click Approve. Only tools that read can be ticked; tools that could change something are shown, but greyed out with the reason.

kanman remembers exactly which tools the server offered when you approved them. If the server later changes its tools, even only a description, kanman stops reading the connector and the card shows Tools changed with what was added, removed or changed. Review the tools and approve them again to continue. The change is also recorded in the audit log.

Other states: Sign-in needed (the sign-in expired; click Sign in again), Paused (click Resume). Remove deletes the connector and its sign-in.

Let a routine write through a connector

Tools that change something, for example creating an issue or posting to a channel, stay unused until an owner or admin turns one into a write class. kanman never calls such a tool on its own: a routine uses the write class, and every write is proposed to you first.

1. Click Review tools on an active connector. Under Writes you see the server’s tools that change something.
2. Click Make a write class next to a tool. kanman shows the tool’s parameters as the server describes them; you cannot change them.
3. Choose What it does (sends a message, creates a record or changes a record) and which parameter says where it writes, for example the project or the channel.
4. Enter the allowed destinations: tick them when the tool offers fixed choices, or type them one by one. Then click Approve write class.

kanman fills the other parameters from the routine’s fields. A write to a destination outside your list, or a value that looks like a password or token, is refused. The card also shows the tool’s fingerprint: if the server changes the tool, its writes are refused until you click Approve again or Revoke. Revoke removes a write class at once. Members see the write classes but cannot change them.

While writing through connectors is not yet switched on for your team, the card says so. You can prepare write classes already; nothing is sent before.

How answers use team context

• Every answer names its sources, with a link where the source has one.
• When nothing in the team context or on the board fits a question, kanman says so if it was asked directly. When it would speak up unprompted, it stays quiet instead.
• kanman only uses content the asking person may see, as set for each source.

Privacy

• Content is read with the team’s own model key, or with kanman’s model access if the team has none. See What model providers see.

• kanman finds the passages that fit a question by their words. If the team has its own OpenAI key, kanman also searches by meaning, with that key only. kanman never sends your content to a hidden third party for this.

• If your workspace runs everything on its own runners, reading sources and answering questions happen on your runners: every source type works, and kanman only keeps what the runner found. When no runner is online, kanman says so instead of answering. Your runners sign in with their own credentials, so Confluence, Notion and SharePoint sources need no connection in kanman:

  • repositories, issues, pull and merge requests, wikis and discussions: the runner’s code host token,
  • Confluence: CONFLUENCE_URL (your site, unless the source uses a connection), CONFLUENCE_EMAIL and CONFLUENCE_API_TOKEN,
  • Notion: NOTION_TOKEN, an internal integration the pages are shared with,
  • SharePoint: SHAREPOINT_TENANT_ID, SHAREPOINT_CLIENT_ID, SHAREPOINT_CLIENT_SECRET, set up as in Set up SharePoint,
  • uploaded files: the runner fetches the file from kanman for a few minutes and reads it there; text in images is read with the runner’s model access.

  A source whose sign-in the runner lacks shows Failed with the settings to add. See Run the self-hosted runner.

Related pages

• Work with kanman in Slack and Microsoft Teams
• Channel modes and guardrails
• Hosting and data residency