Two codebases for the same idea
A company builds a Teams app so staff can log work in chat, then builds a separate Outlook add-in so they can do the same thing from email. Two codebases, two store listings, two sets of bugs, the same feature. For years that duplication was just how it was, because Teams apps and Office add-ins were different worlds. They are not anymore. Through the unified Microsoft 365 manifest you can ship one app that runs in Teams, Outlook, and the Microsoft 365 app from a single codebase and a single package. This guide explains how that works, what a combined app can do, how to merge an existing Teams app and Outlook add-in, and when the single-app approach is actually worth it.
Key Takeaways
Teams and Office extensibility have merged
The unified Microsoft 365 manifest (formerly the Teams app manifest) describes one app that runs across Teams, Outlook, and the Microsoft 365 app.
One codebase, one package, one listing
A single solution can include a Teams tab and an Outlook add-in, submitted once and discoverable in the Teams, Outlook, and Microsoft 365 stores.
Manifest version is the gate
App manifest version 1.13 or later enables cross-Microsoft 365 apps; Outlook add-ins use 1.17 or later. Below 1.13 an app is Teams-only.
Message extensions span both
A message extension can let users search or act on your system from Teams chat and Outlook mail, with link unfurling in both.
You can combine existing apps
Convert an XML add-in to the unified manifest, use the Teams project as the base, and bundle them into one app for Microsoft 365.
Tooling is the Agents Toolkit
The Microsoft 365 Agents Toolkit (formerly Teams Toolkit) builds these. Visual Studio does not support the unified manifest for add-ins.
What does it mean that Teams and Outlook add-ins have converged?
It means a single app, described by the unified Microsoft 365 manifest, can run in Teams, Outlook, and the Microsoft 365 app at once. A Teams tab and an Outlook add-in can live in one package built from one codebase, submitted once, and discoverable across all three stores. Permissions granted in Teams carry across the other hosts.
The unified Microsoft 365 manifest is an expansion of the JSON manifest that Teams apps have used for years. Microsoft extended it so the same package can also describe Office add-ins, Copilot agents, and other extensions, which is why a Teams app at manifest version 1.13 or later can run in Outlook and the Microsoft 365 app without a rewrite.
Concretely, you can bundle a Teams tab with an Outlook add-in into one installable unit. The same web experience can appear as a personal tab in Teams and as a task pane in Outlook. A single submission lands your app in the Teams store and, because it is a Microsoft 365 app, in the Outlook and Microsoft 365 app stores too. For Excel, Word, and PowerPoint add-ins the same unified packaging is available, so a single app can reach right across the suite.
This is a genuine shift from the recent past, when an Outlook add-in and a Teams app were built, packaged, and managed separately. The duplication that forced is what the unified model removes.
What can a single Teams-and-Outlook app actually do?
A few patterns make the convergence worth it rather than just tidy.
Shared experiences across hubs. The same page can be a personal tab in Teams and a task pane in Outlook, so a user logging time, looking up a record, or filing a note gets the same tool wherever they are working. One experience, built once, surfaced in both places.
Message extensions. A message extension lets users search your system or kick off an action from a chat message in Teams and from an email message in Outlook, using buttons and forms. Link unfurling, where a pasted link expands into a rich card, works in both Teams chat and Outlook mail. This is one of the strongest reasons to go unified, because the same extension serves two surfaces.
Consistent event handling. You can respond to analogous events in each host, such as a user joining a Teams conversation and a recipient being added to an Outlook message, with shared logic, and record actions from an Office application into a database you then view in a Teams tab.
The point is reuse. When a workflow genuinely spans chat and email, a unified app lets you serve both without maintaining two products.
How do you build one, and what are the requirements?
The foundations are specific versions. You need the Microsoft Teams JavaScript client library (TeamsJS) version 2.0 or later, and the app manifest at version 1.13 or later for cross-Microsoft 365 reach, with Outlook add-ins requiring 1.17 or later. An app below manifest 1.13 stays Teams-only. Get those versions right and the same package can target Teams, Outlook, and the Microsoft 365 app.
The tooling is the Microsoft 365 Agents Toolkit, the renamed Teams Toolkit, which scaffolds and builds these apps. Worth knowing: Visual Studio does not support the unified manifest for Office add-ins, so the add-in portion is a Node.js project in TypeScript or JavaScript built through the Agents Toolkit rather than Visual Studio. Teams app projects can be Blazor and C# in Visual Studio, but if you are combining with an add-in, you keep the whole thing Node.js based.
There is one platform caveat to plan around. Add-ins that use the unified manifest generally install only on Microsoft 365 version 2307 (build 16626) or later, with two exceptions that extend reach to older and perpetual versions: when an administrator deploys the add-in for all users, and when the user installs it in Outlook on the web, new Outlook for Windows, or another desktop client at version 2307 or later. For the deepest detail on the manifest itself, see our Office add-in manifest guide.
// app manifest for Microsoft 365: one package, both surfaces
{
"manifestVersion": "1.17",
"id": "00000000-0000-0000-0000-000000000000",
"name": { "short": "Worklog", "full": "Worklog for Microsoft 365" },
"staticTabs": [ /* Teams personal tab */ ],
"extensions": [ /* Outlook add-in: ribbons, runtimes, requirements */ ]
}Can I combine my existing Teams app and Outlook add-in?
Yes. Convert your XML add-in to the unified manifest, use the Teams app project as the base, and bundle the two into one app for Microsoft 365. Add an alternates property so older Office versions hide the standalone add-in in favour of the combined app. Treat publishing as an update to the Teams app.
Merging is a defined process rather than a rewrite. If your add-in still uses the XML manifest, convert it to the unified manifest first. Then use the Teams app project as the base, keep shared configuration at the root, and move app-specific source into separate subfolders so the two parts stay organised within one project.
To avoid users seeing both the old standalone add-in and the new combined app, you add an extensions.alternates property configured to hide the original add-in on Office versions that support the combined model. That keeps the transition clean.
Be aware of a real-world wrinkle in distribution. Users who previously had only the standalone Office add-in must acquire the new combined app from the store, and it cannot be picked up through the old All Apps button in the Outlook ribbon. Some users on older Office versions may still see the old add-in even after acquiring the combined app. None of this is a blocker, but it is the kind of detail that needs a communication plan rather than a surprise.
If you are maintaining a Teams app and an Outlook add-in as two products, or you are about to build the second one, the unified model is often a clear saving, and sometimes it is not worth the migration. We will tell you which, based on how much your workflows actually overlap. See how we approach cross-Microsoft 365 builds on our page.Office Add-in development services
Message extension or Outlook add-in: which should you use?
When the target is Outlook, you now have two ways to extend it, and they suit different jobs. An Outlook add-in gives you a full task pane experience tied to reading or composing a specific mail item, with deep access to the message. A message extension gives you a lighter, action-and-search interaction launched from the message surface, and crucially it works the same way in Teams chat.
Reach for an add-in when the experience is rich and Outlook-centric: a CRM logging pane, a compliance check on send, a document tool tied to the email. Reach for a message extension when the interaction is a quick search or action that should feel identical in chat and mail, such as inserting a record card or kicking off a workflow from either surface.
The unified model means you do not have to choose one product over the other. A single app can contain both an Outlook add-in for the deep experience and a message extension for the cross-surface quick actions, which is often the right design when a workflow lives in both email and chat.
What does it cost, and how do you publish?
A unified Microsoft 365 app is priced like the experiences it contains, with savings from sharing one codebase instead of two. Publishing is a single submission using app manifest 1.13 or later, after which the app is discoverable in the Teams, Outlook, and Microsoft 365 stores, and admins manage it centrally from the Integrated Apps portal.
The cost driver is how much your Teams and Outlook experiences genuinely share. When they are the same workflow, one codebase is meaningfully cheaper to build and maintain than two products. When they are different features that happen to live in different hosts, forcing them into one app adds complexity without saving much, and two focused apps can be the better call. That judgement is the main thing worth getting right before you start.
Publishing is streamlined. The submission process for a Microsoft 365 enabled app is the same as for a Teams app, with the only difference being manifest version 1.13 or later. One submission makes the app discoverable across the Teams, Outlook, and Microsoft 365 stores, and if it includes Excel, Word, or PowerPoint add-ins, those stores too. Administrators manage availability centrally through the Integrated Apps portal in the Microsoft 365 admin center, and the app uses the same permissions across hosts. Our AppSource publishing guide covers the broader validation requirements that still apply.
Separate apps vs a unified Microsoft 365 app
| Factor | Separate Teams app + Outlook add-in | Unified Microsoft 365 app |
|---|---|---|
| Codebases to maintain | Two | One |
| Store listings | Two | One (discoverable in all stores) |
| Manifest | Teams JSON + add-in XML | Single unified manifest (1.13+) |
| Shared logic and UI reuse | Duplicated | Reused |
| Best when | Features differ by host | Same workflow across chat and mail |
| Admin management | Separate | Central (Integrated Apps portal) |
Frequently asked questions
Can one app run in both Teams and Outlook?
Yes. Using the unified Microsoft 365 manifest at version 1.13 or later, a single app built from one codebase can run in Teams, Outlook, and the Microsoft 365 app. It can include a Teams tab and an Outlook add-in in one package, submitted once.
Do I need a specific manifest version for this?
Yes. App manifest version 1.13 or later enables an app to run across Microsoft 365, and Outlook add-ins require version 1.17 or later. Apps below 1.13 are limited to Teams. You also need TeamsJS version 2.0 or later.
Can I merge my existing Teams app and Outlook add-in?
Yes. Convert the add-in to the unified manifest if it still uses XML, use the Teams project as the base, and bundle them into one app. Add an alternates property to hide the standalone add-in on supported Office versions, and publish it as an update to the Teams app.
What is the difference between a message extension and an Outlook add-in?
An Outlook add-in is a full task pane tied to a mail item, with deep access. A message extension is a lighter search-and-action interaction that works the same in Teams chat and Outlook mail. A single unified app can include both for different parts of a workflow.
Where is a unified app published and managed?
A single submission, using manifest 1.13 or later, makes the app discoverable in the Teams, Outlook, and Microsoft 365 stores. Administrators manage it centrally through the Integrated Apps portal in the Microsoft 365 admin center, and it uses the same permissions across hosts.
Is it always worth combining into one app?
Not always. When the Teams and Outlook experiences are the same workflow, one codebase saves real money. When they are different features that merely share a company, two focused apps can be simpler. The deciding factor is how much the workflows genuinely overlap.
One workflow, one app, both surfaces
The merge of Teams and Office extensibility is one of the more useful changes in the Microsoft 365 platform, because it removes a duplication that cost teams real time. When a workflow spans chat and email, a single unified app built on the Microsoft 365 manifest lets you serve both from one codebase, one package, and one store listing, managed centrally. The art is in judging whether your experiences overlap enough to justify combining them, and getting the manifest versions and the migration details right. If you are maintaining two products that do one job, or planning to, tell us how they overlap and we will recommend whether to unify. Reach out through our contact page whenever you want to talk it through.