Microsoft Teams Integration

Home Integrations Microsoft Teams Integration

Overview

Microsoft Teams has become the central communication hub for a large proportion of organisations running Microsoft 365 — the platform where teams collaborate, where meetings happen, and increasingly where operational notifications and workflow interactions are routed. For business applications that need to surface alerts, status updates, approval requests, and operational information to the people responsible for acting on them, Teams integration provides direct delivery into the communication environment where those people already spend their working day.

Teams integration for custom software covers several distinct use cases. Sending notifications and alerts from operational systems into Teams channels or direct messages — the warehouse management system that alerts the operations team when stock falls below threshold, the trading system that notifies the risk manager when a drawdown limit is approached, the CI/CD pipeline that reports deployment status to the engineering channel. Posting structured, actionable cards that allow Teams users to take actions — approve a request, acknowledge an alert, trigger a workflow step — without leaving Teams. Building Teams bots that respond to commands and queries in chat. And integrating Teams with external workflows through incoming and outgoing webhooks.

The Microsoft Teams integration surface has evolved significantly. The legacy incoming webhook connector approach, while still functional, is being replaced by Power Platform connectors and the Workflows app. The Bot Framework provides the capability for interactive bots that go beyond simple notifications. The Microsoft Graph API provides programmatic access to Teams channels, messages, members, and the broader Microsoft 365 data that Teams sits within. Understanding which integration surface is appropriate for each use case — and the Microsoft roadmap for which approaches are being deprecated — is important context for any Teams integration project.

We build Microsoft Teams integrations for organisations that need to connect their custom operational systems, monitoring tools, trading platforms, and business applications to Teams for notification delivery, workflow integration, and operational communication.

What Microsoft Teams Integration Covers

Incoming webhooks — notification delivery. The simplest Teams integration mechanism for sending messages to a Teams channel from external systems.

Incoming webhook configuration: an incoming webhook is configured on a specific Teams channel through the channel's connector settings (or through the Workflows app for the newer approach). The webhook URL generated during configuration is the endpoint that the external system POSTs messages to. The webhook URL contains the authentication information — it should be treated as a secret and stored securely.

Message format: the JSON payload sent to the webhook URL. The legacy connector card format (@type: "MessageCard") for formatted messages with sections, facts, and action buttons. The newer Adaptive Card format for richer, more structured card layouts that Teams renders natively. The plain text message for simple notifications that do not require formatting.

Adaptive Cards: the JSON-defined card format that renders interactive UI elements in Teams — text blocks, image sets, input fields, action buttons, and column layouts. The Adaptive Card schema that defines card structure, with the body array of card elements and the actions array of buttons. The Action.Submit action type for submitting form data back to the application. The Action.OpenUrl action type for buttons that open external URLs.

Rate limits: Teams incoming webhooks are rate-limited to approximately one message per second per webhook. The rate limit management that queues and spaces messages to avoid hitting the limit and having messages silently dropped.

Workflows app — the modern webhook approach. Microsoft's replacement for the legacy connector approach — Workflows built on Power Automate that provide more flexibility and are the forward-supported method for channel notification delivery.

Workflow-based incoming webhook: the Teams Workflows app creates a workflow triggered by an HTTP POST request — equivalent to an incoming webhook but managed through Power Automate rather than the legacy connector infrastructure. The endpoint URL and schema that the workflow expects. The workflow that receives the POST request and posts the formatted message to the specified Teams channel.

Post message flow: the Workflows configuration that receives an external HTTP trigger and posts a formatted message to a Teams channel — the replacement for the legacy connector card that Microsoft is progressively migrating organisations to.

Microsoft Graph API — programmatic Teams access. The Graph API for programmatic interaction with Teams channels, messages, chats, and members beyond simple webhook notification delivery.

Authentication: the Graph API uses Azure AD OAuth 2.0 authentication. The app registration in Azure AD with the required Microsoft Graph API permissions — ChannelMessage.Send for sending channel messages, Chat.ReadWrite for direct message interaction, Team.ReadBasicAll for listing teams and channels, User.Read.All for resolving user identities. Application permissions (without user context, using client credentials flow) for daemon services that send messages without a logged-in user. Delegated permissions for applications acting on behalf of a specific user.

Sending channel messages: the POST /v1.0/teams/{teamId}/channels/{channelId}/messages endpoint for posting messages to a specific Teams channel. The message body with the contentType (html or text) and the content string. The HTML-formatted message that includes rich text, links, and mentions. The @{user} mention syntax that notifies specific users in the channel message.

Adaptive Card in channel message: the POST /v1.0/teams/{teamId}/channels/{channelId}/messages endpoint with the attachments array containing the Adaptive Card content — the Graph API approach for sending rich card messages that the incoming webhook approach also supports.

Reply to message: the POST /v1.0/teams/{teamId}/channels/{channelId}/messages/{messageId}/replies endpoint for posting a reply in a message thread — the threaded conversation that keeps related notifications grouped.

Direct messages via chat: the POST /v1.0/chats/{chatId}/messages endpoint for sending direct messages. The chat creation via POST /v1.0/chats with the members array for one-on-one or group chats. The direct message approach for personal notifications that should not go to a shared channel.

Reading messages: the GET /v1.0/teams/{teamId}/channels/{channelId}/messages endpoint for reading channel messages — the integration that monitors a channel for specific content or that processes user responses to previously sent messages.

Teams and channel listing: the GET /v1.0/teams endpoint for listing all teams accessible to the application. The GET /v1.0/teams/{teamId}/channels endpoint for listing a team's channels — the discovery endpoint for integrations that need to dynamically route messages to the correct channel rather than using a hardcoded channel ID.

Bot Framework integration. The Microsoft Bot Framework for building interactive Teams bots that respond to user commands and queries in chat.

Bot registration: the Azure Bot Service registration that creates the bot identity — the app ID and app password (client secret) used to authenticate incoming messages from Teams and to call the Bot Framework API. The bot endpoint that receives activity payloads from Teams.

Activity handling: the Bot Framework SDK's activity handler pattern — the OnMessageActivityAsync() override that processes incoming messages from Teams users and returns responses. The activity payload that contains the message text, the sender's identity, the conversation context, and the channel data for Teams-specific information.

Proactive messaging: the bot that initiates a message to a user or channel without first receiving a message — the proactive notification that sends an alert to a user when an external event occurs. The conversation reference that must be stored from an initial user interaction to enable subsequent proactive messages.

Adaptive Card responses: the bot that responds to user commands with Adaptive Cards — the interactive card that presents information, input fields, and action buttons. The card submission handling that processes user input from Adaptive Card form fields submitted through the bot.

Task modules: Teams-specific Bot Framework capability — the modal dialog that opens from a bot message, displays custom web content or an Adaptive Card, and returns submitted data to the bot. The task module for complex data collection that exceeds what a simple Adaptive Card form can accommodate.

Teams-specific activities: the onTeamsMembersAddedEvent, onTeamsMembersRemovedEvent, and other Teams-specific activity handlers for the events that Teams generates when channel membership changes — useful for bots that manage per-user workflows based on channel membership.

Outgoing webhooks. Teams outgoing webhooks that call external services when users mention the webhook in a channel message.

Outgoing webhook registration: the outgoing webhook configured in Teams with the name that users @mention to trigger it and the callback URL that Teams POSTs the message to. The HMAC-SHA256 signature in the Authorization header that the external service uses to verify the request originated from Teams.

Use cases: the custom command handler that processes user queries mentioning the bot name in a channel — the @deploybot status command that calls the CI/CD system and returns deployment status. The information retrieval bot that queries external systems in response to user commands.

Notification routing architecture. The server-side notification routing that determines which Teams channel or user receives each notification type.

Channel routing: the notification routing configuration that maps event types and severities to Teams channels — critical alerts to the on-call channel, informational updates to the general ops channel, trading risk alerts to the risk management channel. The routing rules that the notification service applies to each outbound message.

User routing: the notification routing that resolves which Teams user to send a direct message to based on on-call schedules, team ownership rules, or event-specific routing logic. The Graph API user lookup that resolves business user identifiers to Teams user IDs for direct message delivery.

Escalation patterns: the multi-level alert escalation that sends a channel notification first, escalates to a direct message if unacknowledged within a defined window, and escalates further if still unacknowledged — the operational alerting pattern that ensures critical events are not missed.

Adaptive Card design for operational use cases. Card designs that present operational information clearly and enable action without leaving Teams.

Alert cards: the alert card that presents the alert severity, the affected system, the alert description, the time of occurrence, and action buttons — Acknowledge, Investigate, Escalate. The card that gives the recipient the context to decide on the appropriate response and the buttons to record that response.

Approval cards: the approval request card that presents the request details, the requester, the justification, and Approve/Reject buttons with an optional comment field. The approval workflow that routes the submission from the card back to the application to process the decision.

Status update cards: the status card that shows the current state of a process — deployment progress, order processing status, trade execution confirmation — with the visual hierarchy that makes the status immediately readable.

Dashboard cards: the summary card that presents key metrics for a team's area of responsibility — the daily trading P&L summary, the overnight processing status, the system health overview — delivered to the team's channel at a scheduled time.

Integration Patterns

Event-driven notifications. The most common Teams integration pattern — an operational system generates an event and sends a notification to the appropriate Teams channel. The risk management system that sends a drawdown alert when a threshold is crossed. The warehouse system that sends a low stock alert when inventory falls below the reorder point. The monitoring system that sends a service degradation alert when response times exceed SLA.

Approval workflows. Business processes that require human approval delivered through Teams — the leave request that arrives as an Adaptive Card with Approve/Reject buttons, the deployment approval that blocks the pipeline until a team member approves through Teams, the financial transaction above a threshold that requires management sign-off.

Scheduled reporting. The scheduled message that delivers a daily, weekly, or triggered summary to a Teams channel — the morning trading P&L summary, the end-of-day order processing report, the weekly inventory health summary. The scheduled job that queries operational data, formats it as an Adaptive Card, and posts to the relevant channel on schedule.

Interactive queries. The bot that responds to user queries in Teams — the @tradebot positions command that returns the current portfolio positions, the @supportbot ticket status 12345 that returns ticket status from the service desk system. The conversational interface that brings operational data into the Teams chat context.

Technologies Used

  • C# / ASP.NET Core — primary Teams integration implementation, leveraging the Microsoft Bot Framework SDK, the Microsoft Graph SDK for .NET, and the Microsoft.Teams.AI library
  • TypeScript / Node.js — Teams integration for Node.js-based applications using the Bot Framework JavaScript SDK and the Microsoft Graph JavaScript client
  • Python — Teams notification delivery for Python-based operational systems and monitoring tools
  • Microsoft Graph API — programmatic Teams channel and message management
  • Bot Framework SDK — interactive Teams bot development
  • Azure Bot Service — bot registration and channel configuration
  • Azure AD / OAuth 2.0 — Microsoft Graph API authentication
  • Adaptive Cards — structured, interactive card design for Teams messages
  • Incoming webhooks / Workflows app — simple notification delivery to Teams channels
  • REST / HTTP — webhook and Graph API communication
  • SQL (PostgreSQL / MySQL) — notification routing configuration, conversation references, alert state
  • Redis — rate limit management, notification deduplication, bot state
  • Hangfire / scheduled jobs — scheduled report delivery to Teams channels
  • Docker — containerised bot and notification service deployment
  • GitHub Actions — CI/CD pipeline for integration service deployment

Teams as the Operational Communication Layer

For organisations standardised on Microsoft 365, Teams is where operational communication happens — the place where alerts get seen, where approvals get processed, where status updates get discussed. Integrations that deliver operational notifications directly into Teams remove the friction of requiring staff to monitor separate dashboards or check separate notification channels — the alert arrives in the environment they are already monitoring, with the action buttons that let them respond without context switching.

The shift from passive notifications (a message that informs) to active cards (a message that informs and enables action) is the higher-value Teams integration pattern — the Adaptive Card that presents the alert, the context, and the response options, so that the recipient can acknowledge, escalate, or act without leaving Teams.

Operational Alerts and Workflows, Delivered to Teams

Teams integrations built to production standards — correct Graph API authentication with appropriate permission scoping, Adaptive Card designs that present information clearly and enable action, notification routing that delivers the right message to the right channel or user, rate limit management that prevents message loss, and the monitoring that surfaces delivery failures before they cause operational blind spots.