Skip to content
threada Docs

Microsoft Teams Store

This guide defines the Microsoft Teams Store path after Slack Marketplace and the Zapier public integration scaffold. It is a runtime and launch-control document, not evidence that a Teams Store listing has been approved.

Current Status

Microsoft Teams has a first-class runtime intake path for the v1 Teams app surface: Bot Framework message activities and the createWorkItem message extension can create governed Teams-sourced WorkItems through WEBHOOK_PROVIDER_TEAMS and INTEGRATION_TYPE_MICROSOFT_TEAMS. Runtime automation also supports the microsoft_teams_post_message outbound action for posting a governed notification to a configured Teams incoming webhook or Teams Workflows webhook URL. A private Teams app package scaffold lives at packages/teams-store-app for the bot command and message-extension surface. Studio exposes https://studio.threada.ai/integrations/teams/install to preload the Microsoft Teams runtime integration kind and connector preset for a pack. Do not submit or claim a public Microsoft Teams Store listing until the package is rebuilt with real Microsoft app and bot IDs, validated in Developer Portal, self-tested across Teams clients, and accepted through Partner Center.

The public setup and support guide for reviewer testing and future public users is Microsoft Teams setup and support. Use https://docs.threada.ai/integrations/microsoft-teams-setup/ as the setup and support URL unless the launch owner replaces it with a stronger public help-center URL before submission.

The existing signed Teams relay path remains supported for custom tenant integration work. It should not be described as the public Teams Store app.

Positioning

Threada for Microsoft Teams should let Teams users capture a conversation or request into a governed Threada WorkItem without bypassing Threada’s policy, approval, idempotency, and audit controls.

The enterprise-safe v1 app should stay narrow:

  • Create a governed WorkItem from a Teams conversation, message, command, or message-extension action.
  • Route the WorkItem to an installed tenant/workspace mapping in Threada.
  • Provide setup and support surfaces that tell admins how to connect the Teams tenant to Threada.
  • Show clear success or setup-required feedback inside Teams.

The v1 app must not claim that Teams can execute third-party actions through Threada. Direct external execution remains inside Threada’s governed Work, Studio, MCP, A2A, or first-party runtime paths.

The runtime-supported Teams outbound notification action may be described as a Threada-to-Teams notification capability only when a tenant has configured a Teams webhook URL. Do not describe it as proactive bot messaging, Graph chat writes, or a Teams command that executes arbitrary third-party actions.

Source Of Truth

Do not duplicate request or response schemas in this document. Runtime source truth for Teams app intake is the public BFF runtime webhook handler, the runtime-automation Teams webhook handler, and generated route map. Public WorkItem shape and channel labels are documented in Threada Public API and its generated OpenAPI artifact at /openapi/public-api.openapi.yaml.

The private package scaffold is the source of truth for the current manifest shape, icons, and package validation script. Bot Framework or Microsoft Entra registration, Developer Portal validation output, Partner Center offer metadata, and reviewer setup notes must become the source of truth for the public Store submission once they exist. This document should keep launch gates and boundaries in sync with those artifacts, not replace them.

App Surface

Create WorkItem From Teams

The first reviewable capability creates a Threada WorkItem from Teams context through a bot command and message-extension action. The visible behavior must be easy for Microsoft validators to test end to end.

Inputs should map to the live WorkItem fields for subject, channel, channel ID, thread/source metadata, contact details where allowed, tags, and initial message. Use the existing teams source channel. Preserve Teams provenance in source metadata and channel/thread identifiers rather than inventing new public API channel labels.

Outputs must give the Teams user a clear success or setup-required state and a safe Threada Work URL when one can be generated. Do not return only a generic success message; validators need to see the actual user journey.

Setup And Tenant Mapping

The app must bind an installed Teams tenant or conversation to a Threada tenant, pack, queue, or workspace mapping before claiming production readiness. If a user tries to create a WorkItem before setup is complete, Teams should show a clear setup-required response rather than silently dropping the request.

Reviewer setup notes must include the exact test tenant, users, channels, and Threada workspace or pack mapping needed to exercise the app. Credentials, tokens, cookies, raw payloads, and customer data must stay out of repo evidence and screenshots.

Optional Personal Tab

A personal tab can help with setup status, support, or deep links, but it is not required for the first Store package unless the app needs an in-Teams UI to be reviewable. Do not add a decorative tab just to make the package look larger.

Proactive Messages And Actions

Proactive Teams messages, Graph reads, file access, calendar access, and governed action execution from inside Teams are out of scope for v1 unless the corresponding permissions, runtime path, consent flow, tenant scoping, tests, and review evidence exist. If added later, they must be listed as separate Store scope and validation changes.

The microsoft_teams_post_message action is not part of the Teams app package surface. It is a Threada runtime action that posts a Teams card to a configured webhook endpoint after Threada governance, approval, idempotency, and audit controls have selected the action.

App Package Requirements

Microsoft’s Teams publishing overview says Store distribution requires Microsoft approval, and that publishing a Teams app requires a valid app package containing an app manifest and app icons. The Store publishing guide and submission checklist also call out Partner Center submission, Developer Portal package validation, desktop/web/mobile self-testing, publisher verification, Publisher Attestation, test instructions, setup instructions, and optional demo video support.

Required package work before submission:

  • Teams app manifest and icons from packages/teams-store-app.
  • Bot Framework and Microsoft Entra setup where the chosen app capability needs a bot, identity, or SSO.
  • Tenant installation and uninstall handling.
  • Production callback endpoints and secrets in Secret Manager or approved managed identity storage.
  • Public support, privacy, terms, and setup documentation.
  • Store listing copy, screenshots, test instructions, setup notes, and reviewer account or demo tenant access.
  • Developer Portal validation and custom-app self-test before Partner Center submission.
  • Publisher verification and Publisher Attestation.

Explicit Non-Goals

  • No public Teams Store readiness claim until the first-class Teams app package is runtime-bound, validated with real Microsoft IDs, and accepted through Partner Center.
  • No direct side-effecting external action execution from Teams.
  • No broad Graph permissions, file reads, calendar access, or chat history reads unless the exact v1 capability requires them and the implementation is validated end to end.
  • No customer-data screenshots, raw Teams exports, or private tenant payloads in Store screenshots or review evidence.
  • No positioning as a generic “AI agent executes any Teams action” app. Public copy must stay anchored to WorkItem intake, setup, and governed review.

Review Gates

Implemented:

  • Public API and runtime models include a teams WorkItem source channel.
  • Runtime webhook routing supports first-class Teams app intake at /api/v1/runtime/webhooks/teams/{tenant_id}/{channel_id} plus legacy relay-style custom intake.
  • Runtime Teams app intake validates Microsoft Bot Framework bearer JWTs against the code-owned Bot Framework issuer/JWKS, the Secret Manager configured bot app ID, and the Activity serviceUrl.
  • Runtime Teams app intake supports bot message activities, composeExtension/fetchTask, and composeExtension/submitAction for creating Teams-sourced WorkItems.
  • Runtime automation supports microsoft_teams_post_message for outbound Threada-to-Teams webhook notifications with Teams/Workflows host validation, template rendering, typed public API payloads, and adapter tests.
  • Public API docs and generated OpenAPI are published.
  • Public Teams setup/support documentation is published from docs/integrations/microsoft-teams-setup.md.
  • Private Teams app package scaffold exists at packages/teams-store-app.
  • The package scaffold generates manifest.json, color.png, outline.png, and threada-teams-app.zip from committed source.
  • Package tests cover manifest shape, least-privilege v1 scope, icon dimensions, package zip contents, placeholder ID injection, and submission-readiness blockers.

Missing:

  • Real Microsoft app and bot IDs wired through private environment variables for Developer Portal validation.
  • Bot Framework and Microsoft Entra registration for the bot command and message-extension capability.
  • Production tenant/channel mapping configured with real Secret Manager bot auth JSON for the review tenant.
  • Self-service tenant install, setup-required, and uninstall behavior if the public launch depends on admin-managed mappings instead of reviewer-prepared mappings.
  • Store listing copy, screenshots, test instructions, setup notes, and reviewer access.
  • Developer Portal validation output.
  • Desktop, web, and mobile self-test evidence.
  • Bot Framework metadata consistency evidence for the app name, logo, privacy policy link, and terms link.
  • Publisher verification and Publisher Attestation.
  • Partner Center submission evidence and Microsoft validation report.

Blocked:

  • Public Teams Store submission is blocked until the package is rebuilt with real Microsoft IDs, the production runtime mapping is configured and smoked, Developer Portal validation passes, and reviewer setup is complete.

Launch Checklist

  1. Keep the v1 Teams capability to the committed bot command and message-extension action for creating a WorkItem.
  2. Rebuild the app package with real Microsoft app and bot IDs, least-privilege permissions, Bot Framework, and Microsoft Entra setup as required.
  3. Configure the production Teams channel secret in Secret Manager with the Microsoft bot app ID and optional Microsoft tenant or service URL limits, then bind the Teams tenant/scope to the intended Threada tenant and channel.
  4. Smoke-test WorkItem creation through the bot command and message-extension submit action against the production callback endpoint.
  5. Review the published public setup/support documentation for the exact Teams package being submitted and prepare Store listing copy.
  6. Create sanitized screenshots and optional demo video for the key user flow.
  7. Validate the package in Developer Portal and fix every package error.
  8. Upload as a custom app and self-test across Teams desktop, web, and mobile.
  9. Prepare Partner Center submission, publisher verification, test notes, setup notes, Publisher Attestation, and reviewer account or demo tenant access.
  10. Submit through Partner Center and resolve Microsoft validation issues before claiming Store readiness.

References