Integrations & providers

Most software platforms talk about "connectors" the way diet pages talk about superfoods: a word that does everything and nothing. What Disco Parrot connects to falls into four shapes, and naming them properly is the part of this page that matters most. Work items sync both ways with Azure DevOps and GitHub. Code lives in a repository provider. Files come in from a document provider. Notifications go out through a channel. The credential model is different in each, the audit story is different in each, and treating them as one bucket would hide all of that.

The four categories

An integration is a two-way link between your Disco Parrot records and an external work-tracking system. Field mappings, concept mappings, a credential that writes back as you. Today there are two: Azure DevOps and GitHub.

A repository provider is where your code lives. The platform reads it into a sandbox, the agent works against the clone, and a pull request lands back at the provider with your identity on it. Today there are two: GitHub and GitHub Enterprise Managed User on github.com.

A document provider is a place to import files into the workspace document library. The credential is per-user OAuth, the data path is one direction (in), and the documents get indexed and become attachable. Today there are two: Google Drive and OneDrive.

A notification channel is a place to deliver notifications. It is delivery only; nothing reads back. Three channels are configurable: the in-app inbox, email, and Microsoft Teams.

The lines between these categories are not academic. They drive the setup flow you see, the credentials that get stored, the permissions that gate them, and the part of the audit log they land in. The rest of this page walks through each one.

Work-tracking integrations

Azure DevOps

Azure DevOps is the closest thing the work-item world has to a Disco Parrot equivalent: the same nesting (Feature, Backlog Item, Task), the same shape of fields, the same expectation that you describe work and then ship against it. The integration treats it as a peer, not as a downstream system you flatten into.

Setup is a single screen. You paste a personal access token, point at the organization and the project, and the platform validates the token, stores it under your account, and provisions the Azure DevOps MCP configuration the agent uses to reach work items. From that moment forward, the agent has both the human-facing concept (an initiative, a plan, a test case) and the matching ADO work item, with the platform keeping them in step.

The defaults match the most common Azure DevOps shape:

Fields between the two sides are mapped per concept, and the available field set on the Azure DevOps side is pulled live from the project rather than hardcoded. A team that has customized its work item process keeps that customization; the integration sees the same set of fields they do.

On the Disco Parrot side, the link shows up in the initiative's Spec-tab sidebar under External system links: the integration name, the ADO work-item ID (clickable through to Azure DevOps), the linked test cases, and a last-synced timestamp. A PM reading the initiative sees the same record from both sides; the engineer working from the ADO board sees the link back to the spec.

The credential lives at the user level on purpose. Your access to Azure DevOps is yours, not the workspace's. When someone leaves, their ability to write back into the work-item tracker leaves with them, and the next person sets up the integration with their own token. This is the right shape for a system where attribution matters.

The full how-to, connecting your token, the mapping editor with live field discovery, and reading the link from the Disco Parrot side, lives on the Azure DevOps integration page.

GitHub

GitHub does double duty in Disco Parrot. It is the place the code lives, which makes it a repository provider, and it is a work-tracking surface in its own right (issues, pull requests, check runs), which makes it an integration too. Both halves use the same credential layer underneath, so configuring one configures the other.

The credential model handles three shapes because real teams use all of them.

A personal access token is the simplest setup: paste a token, you are connected. Both classic tokens (the ghp_ ones) and fine-grained tokens (the github_pat_ ones) work for general repository access. The one thing worth knowing up front is that classic tokens cannot drive the GitHub Copilot runtime. If you want the Copilot path, use a fine-grained token or one of the App-based credentials below.

A GitHub App installation scopes a single credential at the tenant level, with permissions managed centrally by an org admin. Most enterprises start here because it removes the per-user token sprawl.

App OAuth is the App with a layer on top. The user authorizes the App, and their writes (commits, pull requests) carry their identity on GitHub for attribution. The App installation still defines what those writes can reach. You get the audit trail in GitHub reading the way it should (your name on your commits), with the org keeping control of what is actually accessible. This is the default we recommend for teams above a handful of engineers.

Those three, PAT, App installation, and App OAuth, are the methods the chooser actually offers.

The setup flow follows the same shape as Azure DevOps: validate the credential, store it at the right scope, provision the matching MCP configuration. When the Copilot runtime is enabled, it plugs into whichever GitHub connection you already have rather than a second one. The how-to for wiring that up, and the one credential rule that decides whether Copilot can run, lives on the GitHub code integration page.

Repository providers: GitHub and GitHub Enterprise

A repository provider is what the code lives in. Two are real today: GitHub on github.com and GitHub Enterprise. This section is the concept; the how-to of setting one up lives under repository providers, and pointing a repository at one is covered in connect a repository.

The GitHub provider supports the same three auth methods the integration does: personal access token, App, and App OAuth. The provider can be tenant-scoped (a single org's App acts for everyone) or per-user with a token. An identity picker lets a user choose which credential to use when they have more than one configured, so an engineer with both a personal PAT and access through the tenant App can route correctly.

The GitHub Enterprise provider is GitHub Enterprise Managed User on github.com, not self-hosted GHES. It requires an enterpriseSlug (normalized to lowercase, accepting letters, digits, and hyphens) because the EMU sign-in flow routes through the enterprise's identity provider. The platform redirects to github.com/enterprises/{slug}/sso, GitHub's EMU gateway authenticates the user through your configured SAML or OIDC identity provider, and the user lands back to complete the OAuth flow. The platform does not handle the SAML or OIDC exchange itself; GitHub does. Repository discovery on EMU is manual clone-URL entry, since the API surfaces required to enumerate repositories the way the public API allows are not reliably available in the EMU model. Once a repository is added, the agent works against it just like any other GitHub repository.

Document providers

The document library is the place files live in Disco Parrot once they have been pulled in from somewhere else. Google Drive and OneDrive are the two providers wired today, and the flow is the same on both: you authorize the provider over OAuth (with PKCE, per-user session), search for what you want, pick the files, and they land in your library. The full how-to lives on the document providers page.

Google's own editor documents, the Docs, Sheets, and Slides ones, come in as PDF, so they sit in the library as portable files the agent can read rather than as links that quietly rot. OneDrive files arrive in their native format. A document that leans on live behavior (comment threads, custom interactivity, embedded widgets) lands as its rendered PDF, while text, tables, and the usual images come through cleanly.

Imports deduplicate by content hash within the workspace. The same file imported twice into one workspace lands once; the same file imported into two workspaces lands twice (each workspace keeps its own library). From there a document can be attached to an initiative, a plan, or a bug, and the platform propagates the attachment up the hierarchy: a doc attached to a plan also shows on the plan's initiative, a doc attached to a bug also shows on the bug's plan. The point is that you attach a piece of context once, at the level it is relevant, and it shows up at the levels that need it.

Notification channels

Three channels are configurable today: the in-app inbox (on by default, the one you cannot turn off), email (off by default), and Microsoft Teams (off by default). Teams takes an incoming webhook URL that each user stores against their own account. Your personal Teams channel is yours; nobody else gets to subscribe to it through your credential, and you can change where notifications go without touching anyone else's setup.

If your eyes went to "Slack" before they hit the list above, that is the part worth noting. Slack is on the MCP side, available to agents as a tool, not a notification destination today. The clean line: notifications go to in-app, email, and Teams; tool-calling reaches Slack and other systems by a different path described under Approved actions.

Workspace preferences and the kill switch

Notifications have three tiers of settings. The platform ships defaults (every category on, in-app only). The workspace can override those defaults across everyone, turning categories on or off and changing which channels are in play. And each user can adjust their own preferences on top, within whatever the workspace allows.

The middle tier is the lever an enterprise reaches for first. An admin who decides Activity notifications should not go to Teams across the workspace can turn that off at the workspace level, and no user can opt themselves back in. The same admin can leave Assignments and Status open for everyone to personalize. Email and Teams delivery are gated by commercial-plan entitlements, so smaller plans get the in-app inbox by default and add the other channels at the right tier.

Why the MCP catalog is a separate page

You will see another surface in Disco Parrot, the MCP catalog, that lists names you might expect to see here: Slack, Linear, Jira, HubSpot, and many others. Those entries are real, the agent can call into those systems through them, and they are not integrations in the sense this page uses the word. There is no two-way sync between a Linear ticket and a Disco Parrot plan; there is an MCP server the agent can ask to read or create a ticket. The difference matters.

That is also why MCP tools live under Approved actions: the per-tool allowlist is the right place to talk about them. The how-to for browsing the catalog, connecting a server, and setting its tool allowlist is MCP tools. Integrations are about records moving across; tools are about a call the agent can make. Both are useful. Both have their own page.

Identity picker

If you have more than one credential against the same system, the identity picker appears at the moment a choice would actually matter. Most of the time the platform picks the right one for you, and you do not see the picker at all. When the right one is not obvious (you can reach a repository both as your personal account and through the tenant App, and you are about to open a pull request), the picker steps in: here are the identities you have, here is what each one is good for, pick one. The picker is reachable whenever you want to switch which identity a provider is bound to, so changing the identity behind your work is always one step away.

The picker is what makes the per-user credential model usable in practice. An engineer can route reads through the App and route writes through their personal identity; a workspace can default everyone to the App and let the few cases that need a different credential resolve themselves at the moment of the action. The agent inherits whichever identity gets picked.

Identity is not access

One design choice runs through every category on this page: who you are in Disco Parrot is a different thing from what you can reach in a downstream system. You sign in with Microsoft Entra or Google, verified through OAuth. That is your identity. GitHub is not how you log in. Azure DevOps is not how you log in. Drive is not how you log in. Those are credentials you bring, when you need to reach something they can reach.

The split sounds academic until something happens. A contractor's GitHub access gets revoked at the end of an engagement. Their Disco Parrot workspace identity is untouched; their projects, their plans, their history stay with them. They hand off the work, or they come back later and reattach a credential, and the workspace does not have a hole where their identity used to be. A workspace gets to manage its tenant-level GitHub App without tying it to any one person. An engineer with two GitHub accounts can route one through reads and the other through writes without juggling sessions.

There is also a quieter consequence, the one that matters when a security review starts asking questions. The agent's reach is bounded twice, not once. What an agent can do is bounded by the credential it gets handed; that credential is bounded by what the App or PAT itself can reach; and the audit trail records the call against the person who set the credential up. The agent is never more powerful than its credential, which is never more powerful than the person who configured it.

What is not here

A few names show up in adjacent surfaces but are not integrations in the categories on this page. Calling them out, because the question comes up.

• GitLab and Bitbucket are not repository providers today. The product is structured to accept additional providers; only GitHub and GitHub Enterprise are actually wired.
• Jira and Linear are not work-tracking integrations. They are MCP catalog tools, a different category.
• Slack is not a notification channel today. It is an MCP catalog tool too.
• GitHub is not a sign-in provider. Sign-in is Microsoft Entra and Google. Tenant SSO, SAML, and SCIM are commercial-plan line items, not features on every workspace.

That list is short because we would rather name what is real than gesture at a longer wishlist. The full roster, by category, is what's supported today.

Permissions

Setting up an integration or a repository provider is admin work. The required scopes (integrations.manage, repo-providers.manage) sit in the same admin bundles as other platform configuration. Per-user authentication on top of an integration belongs to the user from their own settings: an admin wires the workspace-level integration once, and each person on the team connects their own ADO account without an admin in the middle.

Document providers have no workspace-level wiring at all. There is nothing for an admin to set up; each person connects their own Drive or OneDrive when they need it, governed by doc-providers.read to connect and browse and doc-providers.import to bring a file in. The document providers page covers the connection in full.

The wiring step is recorded as a configuration change on the audit log; the per-user auth is recorded as an authorization event. The two events answer different questions, and the audit trail keeps them apart.

The bigger picture

Most platforms talk about "integrations" the way restaurants talk about "fresh." It is a word that sounds like it means something specific and rarely does. This page is built around the categories that actually exist, named the way they actually behave: a two-way work-item sync is one thing, a repository the agent works against is a second thing, a place to import a file from is a third, and a place to deliver a notification is a fourth. When a customer asks what Disco Parrot is connected to, you can answer the question.