What is Outlook add-in development, and how is it different from a plugin?

Outlook add-in development means building a small web application that Outlook loads inside a sandboxed task pane or triggers on an event like sending mail. The add-in is HTML, CSS, and JavaScript that talks to the mailbox through the Office JavaScript API (Office.js). Nothing is installed on the machine. Outlook reads a manifest, wires up your buttons, and loads your web app in a WebView.

People still say "Outlook plugin" out of habit, and they often mean the old desktop kind: COM or VSTO add-ins written in C# or VB.NET that install code directly on Windows. Those are a different species. They run only on classic Outlook for Windows, they can reach into the file system and other desktop apps, and they break Outlook in ways Microsoft spent years cleaning up after. The modern Outlook add-in trades that deep access for portability and stability.

The practical difference for a buyer is reach. A COM add-in lives on one Windows desktop. A web add-in built on Office.js works in Outlook on Windows (both the new and classic clients), Outlook on the web, Outlook on Mac, and the Outlook mobile apps, from a single deployment. You are not maintaining three versions for three platforms.

That portability is also why "outlook add-ins", "outlook plugins", and "outlook extensions" increasingly all point to the same thing in 2026: a web add-in. The desktop plugin era is closing.

Why did the new Outlook for Windows break my existing add-in?

Because the new Outlook for Windows is a web client at its core, and it does not load COM or VSTO add-ins at all. Those add-ins are Windows desktop code, and the new client has no place to run them. To keep working in new Outlook, a COM or VSTO add-in has to be rebuilt as a web add-in using Office.js.

The new Outlook for Windows is not the old Win32 application with a fresh coat of paint. Under the hood it is the same web codebase as Outlook on the web, wrapped in a desktop shell. That single architectural decision is what makes legacy add-ins disappear. There is no compatibility layer for COM or VSTO. They are not slow or degraded in the new client, they are absent.

The timeline is what catches people out. New Outlook became the default for small and medium business Microsoft 365 subscriptions in January 2025. Enterprise tenants were given more room, but April 2026 was the point at which new Outlook became the default experience for them too, with classic Outlook positioned as the thing you switch back to, not the thing you stay on. Classic Outlook still runs your COM and VSTO add-ins, and it still receives new web add-in features, but Microsoft has been clear that it is on a deprecation path with no new feature investment.

There is a second deadline hiding behind the first. Exchange Web Services, the old API that many Outlook integrations used to read and write mailbox data, stops accepting connections from add-ins on 1 October 2026. So a migration is often two jobs at once: move the UI from VSTO to Office.js, and move the data calls from EWS to Microsoft Graph. Teams that only plan for the first half get surprised by the second.

If you are sitting on a business-critical VSTO add-in right now, the honest read is this: it is working today on classic Outlook, and it will keep working there for a while, but the platform under it is being retired around you. A typical rebuild runs three to nine months depending on how much custom logic and backend integration is involved, which means the comfortable window to start is already narrow.

Web add-in vs VSTO vs COM: which model should you build on in 2026?

Build on the web add-in model (Office.js) unless you have a hard requirement that only desktop code can meet, such as deep local machine access. Web add-ins are the only model that runs in the new Outlook and across Mac, web, and mobile. VSTO and COM are classic-Outlook-only and on the way out.

There is not much of a decision left for most projects, but it helps to see the tradeoffs side by side. The thing VSTO and COM still do better is raw desktop power: they can touch the local file system, drive other Office apps over automation, and run heavy processing in-process. If your workflow genuinely needs that, and it never has to leave a managed Windows fleet, a desktop add-in can still make sense as a stopgap. For everything else, the web model wins on reach and longevity.

How does the manifest work, and what is the unified manifest gotcha?

Every Outlook add-in is described by a manifest. It tells Outlook the add-in's identity, where its web files live, which ribbon buttons to add, what permissions it needs, and which mailbox API requirement sets it depends on. There is no add-in without a valid manifest, and a surprising share of project pain comes from getting it slightly wrong.

There are two manifest formats today. The classic add-in-only manifest is XML, it has been around for years, and it still has the widest platform support: Windows desktop, Mac, web, and mobile. The newer unified manifest is JSON, it shares the Microsoft Teams app schema, and it lets you ship an Outlook add-in, a Teams app, and other Microsoft 365 extensions as one installable unit. It is clearly where Microsoft is heading.

Here is the gotcha. The unified manifest does not yet support every platform. Outlook on Windows picked it up from build 16626 onward, and Excel, Word, and PowerPoint on Windows from version 2501, but OneNote and Project do not support it at all, and full cross-platform coverage is still landing. To get both modern packaging and full reach, teams sometimes ship two manifest versions of the same add-in and use the alternates property to prefer one over the other per platform. Worth knowing too: Visual Studio does not build unified-manifest add-ins, so that path runs through the Yeoman generator or the Microsoft 365 Agents Toolkit, and sideloading needs Office 2304 or later.

A small but real detail that bites people: in the unified manifest, requirement sets and the apps your add-in extends live inside the extensions property, not as their own top-level blocks like in XML. If you require Mailbox 1.10 but a user is on a client that only supports 1.8, that feature node gets stripped before install rather than failing loudly. The manifest below shows the shape of an extensions block declaring a Mailbox requirement.

"extensions": [
  {
    "requirements": {
      "scopes": ["mail"],
      "capabilities": [{ "name": "Mailbox", "minVersion": "1.10" }]
    },
    "ribbons": [ /* buttons and commands go here */ ]
  }
]

What can a custom Outlook add-in actually do?

More than most people expect, and the gap with the old desktop add-ins keeps closing. The common patterns we build look like this.

Read and compose flows. The add-in opens a task pane while the user reads or writes an email, pulls the sender, subject, body, and attachments, and acts on them. This is the backbone of CRM logging, ticket creation, and document classification.

Event-based activation. The add-in runs on a trigger without the user opening it, the most common being on-send. That is how compliance stamping, disclaimer injection, recipient checks, and data-loss prevention prompts work. Done right these are idempotent and fast, because a slow on-send handler is the quickest way to make users hate an add-in.

CRM and line-of-business integration. Turning Outlook into a front end for a CRM is one of the most requested builds we see, whether that is logging an email against a Salesforce or HubSpot record, or surfacing the customer's open deals next to their message. The add-in calls your backend, your backend talks to the CRM, and the mailbox identity ties it together.

Microsoft Graph and SSO. With single sign-on, the add-in can get a token for the signed-in user and call Microsoft Graph for calendar, contacts, files, and mail without a second login. This is the modern replacement for the EWS calls older integrations relied on, and it is the path that survives October 2026.

AI features. The recent wave of work is AI inside the task pane: draft a reply in the user's tone, summarise a long thread, translate between languages such as Arabic and English with proper right-to-left handling, extract action items, or classify intent. The add-in handles the UI and the mailbox context, and a backend brokers the model calls so your keys never touch the client.

How much does Outlook add-in development cost, and how long does it take?

A focused Outlook add-in usually runs from a few thousand dollars for a single-feature task pane to mid-five figures for one with SSO, Microsoft Graph, a backend, and AppSource publishing. Timelines run from two to four weeks for something simple to three to nine months for a full VSTO-to-web migration with deep integrations.

Cost is driven by a handful of decisions, not by the word "Outlook". A read-only task pane that shows information has a small surface area. The price climbs with each of these: single sign-on and Microsoft Graph, a hosted backend and database, third-party integration such as a CRM, on-send or other event handlers that must be reliable, cross-platform support including Mac and mobile, and AppSource certification.

Migrations cost more than greenfield builds, because the hard part is not writing new code, it is faithfully reproducing years of accumulated business logic that nobody fully documented, then proving it still behaves. Mapping EWS calls to Microsoft Graph adds real work, since you are learning a second API surface alongside Office.js. We have written more on that in our guide to migrating a VSTO Outlook add-in to the web.

On timeline, the deadline pressure is doing strange things to availability. As more enterprises hit the April 2026 default, demand for developers who have actually shipped Office.js add-ins and done EWS-to-Graph work has gone up, which pushes both lead times and rates. Starting early is not just lower risk, it is usually cheaper.

Publishing reality: AppSource validation and deployment

There are two ways to get an Outlook add-in to users, and most projects use one or both. Centralized deployment through the Microsoft 365 admin center pushes the add-in straight to your own organisation's mailboxes, with no public listing and no Microsoft review. That is the fast path for an internal tool. AppSource (the Microsoft Marketplace) is the public route, and it is how you reach customers outside your tenant and earn the trust signal of a Microsoft-validated listing.

AppSource is where timelines slip. The review itself runs about three to five business days when everything is clean, but a first submission almost never is, and the round-trips can stretch the whole thing toward four weeks. The reviewers test your add-in on every platform whose APIs you declared, so if your manifest says it works on Mac and it does not, you fail.

The most common reasons a submission bounces are boringly avoidable. Every endpoint must be HTTPS with TLS 1.2 or higher, even in development scenarios. Localhost references are rejected outright, because the reviewer cannot reach your machine. You need three valid, live URLs that do not 404: a support page, a privacy policy, and an end user license agreement, and the privacy policy must name the add-in specifically rather than just describe your website. If you use single sign-on, you must give the reviewers step-by-step instructions plus a fallback flow for when SSO is unavailable. If you ship custom functions, you provide test instructions for at least one of them.

One more pattern worth knowing if you are mid-migration: you can run a COM or VSTO add-in and its web replacement side by side on classic Outlook, and use the equivalent-add-in markup (or a Group Policy setting) to tell Outlook which one to prefer, so users are not hit with duplicate buttons during the cutover. We cover the full submission checklist in our walkthrough on how to publish an Office add-in to AppSource.

What separates a smooth Outlook add-in from a fragile one?

A few things that only show up once an add-in is in real hands. The WebView matters: on Windows the add-in renders in a WebView2 control backed by the Edge runtime, so test there and not just in a desktop browser, because the behaviour and the available APIs are not identical. Authentication popups go through the Office Dialog API rather than a raw window.open, or they silently fail inside the sandbox.

Caching is the bug that wastes the most hours. Office aggressively caches your manifest and your JavaScript, so a change you deployed does not appear and you assume the code is wrong. Clearing the Office cache and using cache-busting on your scripts saves a lot of confusion. On-send handlers need to be fast and idempotent, because they sit directly in the user's send action and any lag or double-fire is immediately visible. And requirement sets are not optional polish: declaring the minimum Mailbox version you actually use is what keeps the add-in from loading broken on an older client.

None of this is exotic, but it is the difference between an add-in that quietly works for three years and one that generates a support ticket a week. It is also the part that generic web developers tend to underestimate, because the Office runtime behaves unlike a normal browser.

Outlook add-in models compared (2026)

Frequently asked questions