EXPLAINER

Microsoft Teams Development

Teams apps are packages of tabs, bots, message extensions and connectors that run inside Microsoft Teams and usually call Microsoft Graph. They are not SPFx web parts, though a tab can host a web app or an SPFx part.

Short answer: A Teams app is a manifest plus one or more capabilities: tabs, bots, message extensions or connectors. Identity is Entra ID; data is usually Graph. SharePoint UI inside Teams is a different tool: SPFx.

What it is

Microsoft Teams development means packaging software that appears inside the Teams client. A tab is a web page hosted in a channel, a chat, or a personal app. A bot converses with users and can post proactive messages. A message extension lets people search your system or act on a message. Connectors and incoming webhooks post into a channel. The package is a manifest (JSON) plus icons, sideloaded in a dev tenant or published through the admin center.

This is not the same as building a SharePoint Framework web part, although a SharePoint page can be shown as a Teams tab and an SPFx part can be exposed to Teams. It is also not "a bot" in the generic chatbot sense until you connect the Bot Framework endpoint and a Microsoft identity.

Why and when it is used

Build a Teams app when the work already happens in a channel: approving a request without leaving the conversation, finding a customer record from the compose box, or pinning a dashboard beside the files. People adopt tools that show up where the conversation is.

Build a normal web app instead when the audience is outside the tenant or the UI does not fit a narrow tab. Use Power Automate when a flow and an adaptive card are enough. Use SPFx when the primary surface is a SharePoint intranet page and Teams is only a secondary view.

How it works

The manifest declares the app id, the scopes (personal, team, group chat) and the capabilities. A tab points at an HTTPS URL you host; Teams loads it in an iframe-like web view and can pass context such as the team and channel ids. Your page should authenticate with Entra ID (Teams SSO) rather than asking for a separate password. A bot exposes a messaging endpoint. Azure Bot Service routes activities to that endpoint. You reply with text or adaptive cards, which are JSON UIs Teams renders.

Data about teams, channels and files comes from Graph (/teams, /channels, /chats). The bot's own conversation is not a substitute for Graph permissions. Installing the app in a team requires permission to add apps, which admins can lock down.

Technologies and dependencies

Typical pieces: the Teams app manifest schema, Teams Toolkit or the Developer Portal to scaffold, a host for the tab (Azure App Service, or any HTTPS host), Entra app registration, Graph permissions, and for bots the Bot Framework SDK plus an Azure Bot registration. Adaptive Cards are the UI language for messages. SPFx enters only if the tab content is a SharePoint web part. Node and TypeScript are the common tab stack; bots can be C# or Node.

How to get started

  1. Use a developer tenant where sideloading is allowed.
  2. Create a tab-only app first. A static page that reads Teams context and shows the channel name proves the manifest, the host and SSO before you add a bot.
  3. Register the Entra app the toolkit creates. Confirm the redirect and the client id match the manifest.
  4. Call Graph GET /me with the SSO token flow Teams documents. If consent fails, fix consent before writing features.
  5. Add one useful action. Then consider a bot only if conversation is actually the interface.
  6. Package the app and upload it in Teams (Manage apps) as a custom app. Install it in a test team. Ask a second user to open it.

Keep the manifest's id stable. Changing it creates a second app and orphans the first install.

Cautions and trade-offs

Tabs are small and embedded. A desktop website crammed into a tab is a bad Teams app. Bots that talk too much get muted. Application permissions for a bot that "needs to read every channel" will fail security review; design around the team where the app is installed.

SSO tokens have an audience you must get right (often an exchange from the Teams token to a Graph token). Do not log them. Webhook URLs for incoming connectors are secrets: anyone who has the URL can post to the channel. Admins can block custom apps entirely, so an enterprise rollout is an admin conversation, not only a manifest. Finally, do not store the system of record only inside chat messages. Write business data to your database or to Dataverse and post a card that links to it.