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’s Mind tab, then Memory (next to the board filter) and Sources, 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. What kanman learned, such as your conventions, is in the team’s memory and skills.

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 Cloud it checks the page permissions of that person (Confluence Data Center cannot be asked by email: choose Everyone in the team there). 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.

Confluence

Confluence is one of the systems on Workspace settings > Connections (see Connections). Owners and admins connect it once:

• Confluence Cloud: the address of your site, for example https://acme.atlassian.net, the email of the account kanman reads with and an API token of that account.
• Confluence Data Center: the address people open, for example https://wiki.acme.de, and a personal access token. For a Confluence that only your company network reaches, kanman reaches it through your self-hosted runner; kanman’s cloud then never contacts it.

Every team can then pick the connection when it adds a Confluence source. Besides the team context, kanman can search Confluence and read a page when it plans or answers a question, and it links the pages it used.

What kanman may do in Confluence. On the team’s page Team > Connections, the Confluence entry lists Create pages and Update pages, for example a runbook or release notes. Both start Off. A team head can set them to Ask first (kanman asks in the team’s chat and writes after one tap on Yes, do it) or Automatic. Every page kanman writes is recorded in the team’s activity with its link, and Confluence keeps the earlier versions of a page.

Connections for Notion and SharePoint

Notion and SharePoint sources read through a connection of the workspace. Owners and admins add it once in Workspace settings > Connections: search for Notion or SharePoint and open its page. Every team can then pick the connection when it adds a source. If a source needs a connection that does not exist yet, the team’s Sources view links to it. See Connections.

• Notion: create an internal integration in Notion, enter its token, and share the pages kanman should read with that integration in Notion.
• SharePoint: choose Sign in and click Authorize to give admin consent to kanman’s Microsoft app, or use an app registration of your own. See Set up SharePoint.

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.

SharePoint connections are part of the Team plan, like the other context connectors.

Set up SharePoint (for Microsoft 365 admins)

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

Admin consent to kanman’s Microsoft app (no app registration of your own): on the SharePoint page in Workspace settings > Connections, choose Sign in, save, and click Authorize. A global administrator or privileged role administrator of your Microsoft 365 organization signs in and accepts the permission to read sites. You come back to the page, which then shows your organization under Authorized as. 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.

Your own app registration (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 the SharePoint page in Workspace settings > Connections and choose User and password. Enter the directory (tenant) ID and the application (client) ID separated by a slash under Tenant ID / application ID, and the client secret under Client secret, then save and click Test connection.

When the client secret expires, enter the new one on the connection.

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. An MCP server is connected once for the workspace; each team then adds it and approves its own tools. 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. Connect the server: in Workspace settings > Connections, open MCP server under Generic, enter a Name and the server’s https address, and choose how kanman signs in:

   • Token or key: a token the server issued, stored encrypted under a secret name and never shown again.
   • No sign-in: for servers that need none.
   • Variable on the runner: for servers inside your network. Set the variable you name on your runner; the token never leaves your network. Use a name that starts with KANMAN_CONNECTOR_ and ends with _TOKEN (for example KANMAN_CONNECTOR_SENTRY_TOKEN), so coding tools on the runner never see it.

   Click Test connection: kanman lists the server’s tools to check that it answers.

2. In Team > Connections, open the line Tools I may use, click Add connector, choose the MCP server and, if you like, a name of your team’s.

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 server refused kanman’s sign-in; check the MCP server under Connections, then click Refresh tools), Paused (click Resume). Remove takes the connector away from the team; the MCP server stays connected for the workspace. If the server’s address changes under Connections, each team approves its tools again.

Let a habit 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 habit 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 habit’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 Notion and SharePoint sources need no connection in kanman (Confluence sources use their Confluence connection, which your runner reaches):

  • repositories, issues, pull and merge requests, wikis and discussions: the runner’s code host 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