This chapter covers Microsoft 365 add-ins and app integrations, which are essential for extending the functionality of core Microsoft 365 apps like Outlook, Word, Excel, PowerPoint, and Teams. Understanding how add-ins work, the types of add-ins, deployment methods, and security considerations is crucial for the MS-900 exam, as this topic appears in approximately 10-15% of questions under Objective 2.4 (Describe productivity solutions of Microsoft 365). You will learn the mechanics of add-in runtime, manifest structure, and the differences between COM add-ins, VSTO add-ins, and web add-ins, as well as integration scenarios with Teams, SharePoint, and Power Platform.
Jump to a section
Imagine a professional kitchen with a standard set of appliances: a stove, oven, refrigerator, and dishwasher. These are the core Microsoft 365 apps—Word, Excel, Outlook, Teams. Now, the kitchen also has a standard power outlet and counter space. Add-ins are like small, specialized kitchen gadgets—a sous-vide circulator, a spiralizer, or a precision coffee scale. Each gadget plugs into the standard outlet (the host app's extensibility framework) and sits on the counter (the app's UI surface). The gadget does one thing well: the sous-vide circulator precisely controls water temperature, the spiralizer creates vegetable noodles. Similarly, a Microsoft 365 add-in performs a specific task—like pulling CRM data into Outlook or generating charts in Excel. The gadget cannot function without the power outlet and counter space, just as an add-in cannot run without the host app and its API. Some gadgets, like a blender, come with their own container and can operate independently, analogous to a standalone app. But most are designed to extend the capabilities of the core appliances. Just as a chef chooses gadgets based on the menu, an organization deploys add-ins to meet specific workflow needs. And like gadgets that might not work if they draw too much power or don't fit the counter, add-ins have limitations: they must comply with the host app's security model, performance constraints, and UI guidelines. The add-in manifest is like the gadget's instruction manual—it declares what the gadget does, what it needs (power, water), and how to interface with it. Microsoft's AppSource is like a kitchenware catalog where chefs browse and select approved gadgets. IT administrators can curate which gadgets are available in their kitchen, ensuring only safe, compatible ones are used.
What Are Microsoft 365 Add-ins?
Microsoft 365 add-ins are lightweight, extensible applications that run inside a host Microsoft 365 client application (such as Outlook, Word, Excel, PowerPoint, or OneNote) to provide additional functionality. They are built using standard web technologies (HTML, CSS, JavaScript) and are hosted either in the cloud or on-premises. Add-ins differ from traditional COM or VSTO (Visual Studio Tools for Office) add-ins because they are cross-platform, run in a sandboxed environment, and are easier to deploy and update. The MS-900 exam focuses primarily on these modern web add-ins, not legacy COM add-ins.
How Add-ins Work Internally
An add-in consists of three main components: - Manifest file: An XML file that describes the add-in's identity, permissions, and how it integrates with the host application. The manifest defines the add-in's ID, version, display name, description, icons, and most importantly, the activation rules (when the add-in should appear) and the URLs of the HTML pages that provide the UI and logic. - Web application: The actual add-in logic, hosted on a web server (could be Azure, a third-party cloud, or an on-premises server). The web application can be a simple single-page app or a complex server-side application. - Runtime: The add-in runs inside an embedded browser control (for desktop clients) or directly in the browser (for web clients). The host application provides a JavaScript API (Office.js) that allows the add-in to interact with the document, mailbox, or presentation content.
When a user launches an add-in, the host app reads the manifest, loads the specified HTML page in the add-in's task pane or content container, and injects the Office.js library. The add-in can then read or write data from the document, respond to events, and perform actions. All communication between the add-in and the host app is mediated by the Office.js API, which ensures security and consistency.
Key Components, Values, and Defaults
- Manifest schema: The manifest must conform to the Office Add-in manifest schema (Version 1.1 or later). Key elements include:
- <Id>: A GUID that uniquely identifies the add-in.
- <Version>: The add-in version (e.g., 1.0.0.0).
- <ProviderName>: The developer's name.
- <DefaultLocale>: The locale for the add-in (e.g., en-US).
- <DisplayName>: The name shown to users.
- <Description>: A description of the add-in.
- <IconUrl>: URL to the add-in icon (32x32 and 64x64 recommended).
- <SupportUrl>: A support URL.
- <AppDomains>: List of domains the add-in can communicate with (CORS).
- <Hosts>: Specifies which host apps (e.g., Workbook, Document, Mailbox) the add-in supports.
- <Requirements>: Specifies minimum Office.js API requirement sets.
- <FormSettings>: For mail add-ins, defines form factor settings.
- <Permissions>: Declares the level of access the add-in needs (ReadDocument, ReadWriteDocument, etc.).
Activation rules: For mail add-ins, the manifest includes <Rule> elements that define when the add-in should be activated. Rules can be based on the item type (appointment, message), the presence of a specific entity (email address, phone number, URL), or a regular expression match on the subject or body.
- Office.js API: The JavaScript library provided by Microsoft that allows add-ins to interact with the host application. Key namespaces include:
- Office.context: Provides information about the host environment (e.g., Office.context.mailbox.item for Outlook).
- Office.context.document: For Word, Excel, PowerPoint.
- Office.context.ui: For displaying dialog boxes.
- Office.context.auth: For authentication with Microsoft identity platform.
Requirement sets: Microsoft publishes requirement sets that define the minimum API version needed. For example, Mailbox 1.3 is required for certain Outlook add-in features. The manifest can declare which requirement sets are needed, and the host app will only activate the add-in if the requirements are met.
Configuration and Verification Commands
Add-ins are deployed via the Microsoft 365 admin center or through centralized deployment using PowerShell. For centralized deployment, administrators use:
New-App -Url <manifest_url>This command provisions the add-in for all users or specific groups. The manifest URL must be accessible via HTTPS.
To verify add-in deployment status, administrators can use:
Get-App | Where-Object {$_.ProductId -eq "<GUID>"}This lists all deployed add-ins and their status (enabled/disabled).
For troubleshooting, administrators can check the Office Add-ins health dashboard in the Microsoft 365 admin center or review client logs. In Outlook, users can check the add-in performance by opening the Add-in performance tab in the Outlook options.
Interaction with Related Technologies
Add-ins integrate with: - Microsoft Graph: Add-ins can call Microsoft Graph APIs to access user data, such as calendar events, contacts, or files, after obtaining consent via OAuth 2.0. - SharePoint: Add-ins can be deployed to SharePoint sites as SharePoint Add-ins (now deprecated) or as part of a SharePoint Framework (SPFx) solution. SPFx is the modern extensibility model for SharePoint. - Power Platform: Power Apps and Power Automate can be embedded in Teams and other apps via add-ins or tabs. Power Virtual Agents can be integrated as a chat add-in. - Teams Apps: Teams apps are a type of add-in that can include tabs, bots, messaging extensions, and connectors. They use a similar manifest (but with a different schema) and are deployed via the Teams admin center.
Types of Add-ins
Task pane add-ins: Display a sidebar in the host app (e.g., Word, Excel, PowerPoint). Used for research, translation, or data entry.
Content add-ins: Embedded directly into the document (e.g., a chart or map in Excel).
Mail add-ins: Appear in Outlook when reading or composing messages or appointments. They can be activated by rules (e.g., when the message body contains a tracking number).
Command add-ins: Add custom buttons to the ribbon or context menu. They can run a function or show a task pane.
Deployment Methods
Centralized deployment via admin center: Administrators upload the manifest XML file to the Integrated Apps section in the Microsoft 365 admin center. They can assign the add-in to users or groups. This is the recommended method for enterprise deployment.
AppSource: Public add-ins can be published to AppSource (Microsoft's app marketplace) for anyone to install. Users can install from AppSource directly.
Side-loading: Developers can sideload add-ins for testing by uploading the manifest to a document or via the My Add-ins dialog in Office apps. This is not intended for production use.
Exchange admin center (EAC): For Outlook add-ins, administrators can deploy via EAC by uploading the manifest under Organization > Add-ins.
Security and Compliance
Add-ins run in a sandboxed environment with limited access to the host app's resources. The manifest declares required permissions, and the user or administrator must consent to these permissions. Permissions include: - Restricted: Can only access the current document's metadata. - ReadDocument: Can read the document content. - ReadWriteDocument: Can read and write the document content. - ReadWriteMailbox: For mail add-ins, can read and write mailbox items.
Additionally, add-ins must use HTTPS for all communications. The manifest's <AppDomains> element restricts which domains the add-in can communicate with, preventing data exfiltration.
What MS-900 Tests
The exam expects you to understand:
The difference between add-ins and apps (add-ins run inside host apps; apps are standalone).
The types of add-ins (task pane, content, mail, command).
Deployment methods (centralized, AppSource, side-loading).
Security aspects (manifest permissions, sandboxing, HTTPS).
Integration with Microsoft Graph and Power Platform.
The role of AppSource as the public marketplace.
The deprecation of SharePoint Add-ins and the shift to SPFx.
Common exam scenarios include: choosing the correct deployment method for a given business requirement, identifying which add-in type fits a use case, and understanding permission scopes.
Create the add-in manifest
The developer creates an XML manifest file that describes the add-in. This includes the add-in ID (a GUID), version number, display name, description, icon URLs, and most critically, the activation rules and the URL of the HTML page that will be loaded. For a mail add-in, activation rules might specify that the add-in appears only when a message contains a specific entity like an email address. The manifest also declares required permissions (e.g., ReadWriteMailbox) and the host apps it supports (e.g., Mailbox for Outlook). The manifest must be hosted on an HTTPS endpoint.
Deploy the add-in via admin center
An administrator uploads the manifest XML file to the Microsoft 365 admin center under **Settings > Integrated Apps**. They select **Add-ins** and then **Deploy Add-in**. They can choose to deploy to all users, specific users, or groups. The admin can also enable or disable the add-in and set whether it's mandatory or optional. The admin center validates the manifest and provisions the add-in to the selected users' Office apps. For Outlook add-ins, the admin can also deploy via the Exchange admin center.
Host app loads the add-in
When a user opens a supported host app (e.g., Outlook), the app checks for deployed add-ins. It downloads the manifest from the URL provided during deployment. The host app parses the manifest to determine if the add-in should be activated based on the current context. For example, an Outlook add-in with an activation rule based on the presence of a phone number will appear only when viewing or composing an item that contains a phone number. The host app then loads the add-in's HTML page in a sandboxed browser control.
Add-in initializes and uses Office.js API
The add-in's HTML page loads the Office.js library (provided by the host app). The add-in calls `Office.initialize` to set up event handlers. It can then call Office.js methods to interact with the document or mailbox. For example, an Excel add-in might call `Office.context.document.getSelectedDataAsync` to read selected cells. All API calls are asynchronous and return results via callbacks. The add-in can also display UI elements using the task pane or content container.
Add-in performs actions and communicates with external services
The add-in can make HTTP requests to external services (e.g., a CRM system) as long as the domain is listed in the manifest's `<AppDomains>` element. For authenticated requests, the add-in can use the Microsoft identity platform to obtain tokens via `Office.context.auth.getAccessTokenAsync`. This token can be used to call Microsoft Graph APIs. After processing data, the add-in can write back to the document or mailbox using Office.js methods like `setSelectedDataAsync`. The user interacts with the add-in's UI until they close the task pane or the add-in completes its task.
Scenario 1: CRM Integration in Outlook
A sales organization uses a CRM system (e.g., Dynamics 365) and wants sales reps to view and update CRM records directly from Outlook. They deploy a mail add-in that activates when reading an email from a known contact. The add-in's manifest declares ReadWriteMailbox permission and includes a rule that triggers when the sender's email address matches a contact in the CRM. The add-in makes an API call to the CRM to fetch the contact's details and displays them in a task pane. The user can update the CRM record (e.g., log a call) without leaving Outlook. The add-in is deployed centrally to all sales users via the admin center. Performance considerations: the add-in must be responsive; if the CRM API is slow, the add-in may time out. Misconfiguration: if the manifest's <AppDomains> does not include the CRM's domain, the add-in will fail to make API calls. The admin must ensure the CRM domain is listed.
Scenario 2: Content Add-in for Financial Reporting in Excel
A finance department uses Excel to generate complex financial models. They deploy a content add-in that embeds a live stock price feed into a worksheet. The add-in uses Office.js to read the current cell selection and display a chart. The add-in is side-loaded for testing and then deployed via centralized deployment to all finance users. The add-in must be hosted on a secure server with HTTPS. Common issue: if the add-in's web server goes down, users see an error message. The admin should monitor the add-in's health via the admin center.
Scenario 3: Task Pane Add-in for Legal Document Review in Word
A law firm uses a third-party document review service. They deploy a task pane add-in for Word that integrates with the service. The add-in activates when the document contains certain keywords. The add-in sends the document text to the service for analysis and returns suggestions. The add-in requires ReadWriteDocument permission. The firm deploys the add-in via AppSource but also uses centralized deployment to enforce installation for all attorneys. Security: the add-in must use HTTPS and the manifest must restrict domains to the service's API endpoints. Misconfiguration: if the add-in is not properly tested, it might leak sensitive document content to external servers. The admin must review the add-in's permissions and domain list before deployment.
MS-900 Objective 2.4: Describe productivity solutions of Microsoft 365
This objective includes understanding add-ins and app integrations. The exam tests your ability to:
Identify the types of add-ins (task pane, content, mail, command).
Distinguish between add-ins and standalone apps.
Recognize deployment methods: centralized deployment, AppSource, side-loading.
Understand security: manifest permissions, sandboxing, HTTPS requirement.
Know integration points: Microsoft Graph, Power Platform, Teams apps.
Common Wrong Answers and Traps
Confusing add-ins with apps: Candidates often think an add-in is a separate application that runs independently. Wrong. An add-in runs inside a host app (e.g., Outlook) and cannot function without it. The exam may present a scenario where a user wants to extend Excel's functionality, and the wrong answer might suggest installing a standalone app instead of an add-in.
Choosing side-loading as a deployment method for enterprise: Side-loading is for development/testing only. For production, use centralized deployment or AppSource. The exam may ask how to deploy an add-in to all users in an organization; the correct answer is centralized deployment via the admin center.
Overlooking permission scopes: The exam may ask what permission an add-in needs to write to a document. The answer is ReadWriteDocument. Some candidates might choose ReadDocument or ReadWriteMailbox incorrectly.
Ignoring the manifest's role: The manifest is critical for defining activation rules, permissions, and supported hosts. The exam may test that the manifest must be hosted on HTTPS and that the <AppDomains> element controls CORS.
Specific Numbers and Values
Manifest schema version: 1.1 (or later).
Permission levels: Restricted, ReadDocument, ReadWriteDocument, ReadWriteMailbox.
Deployment methods: Centralized (admin center), AppSource (public), side-loading (testing).
Host apps: Word, Excel, PowerPoint, Outlook, OneNote (for web add-ins).
Requirement sets: e.g., Mailbox 1.3, ExcelApi 1.1.
Edge Cases and Exceptions
Add-ins in Office for Mac: Web add-ins work on Mac, but COM add-ins do not. The exam may ask about cross-platform compatibility.
Add-ins in Office Online (browser): Web add-ins work in the browser version of Office apps, but some features may be limited.
Add-ins in mobile apps: Office mobile apps have limited add-in support; generally only mail add-ins are supported.
Deprecated technologies: SharePoint Add-ins (the old model) are deprecated; the modern approach is SharePoint Framework (SPFx). The exam may test that you should not choose SharePoint Add-ins for new development.
How to Eliminate Wrong Answers
When you see a question about extending Office functionality, first determine whether the solution should be an add-in (runs inside the app) or a standalone app (runs separately). Then, if it's an add-in, identify the type: task pane (sidebar), content (embedded), mail (Outlook only), or command (ribbon button). For deployment, if it's for an entire organization, choose centralized deployment. For permissions, match the action: reading requires ReadDocument, writing requires ReadWriteDocument. Always look for the manifest requirement: HTTPS, AppDomains, and activation rules. If the answer mentions COM add-ins or VSTO, it's likely wrong for modern scenarios (though legacy still exists, the exam focuses on web add-ins).
Add-ins run inside host Office apps (Word, Excel, PowerPoint, Outlook, OneNote) using Office.js API.
Four types: task pane, content, mail, and command add-ins.
Deployment methods: centralized (admin center), AppSource (public), side-loading (testing).
Manifest XML must be hosted on HTTPS and includes permissions, activation rules, and app domains.
Permissions: Restricted, ReadDocument, ReadWriteDocument, ReadWriteMailbox.
Add-ins are sandboxed and cannot access system resources directly.
Modern web add-ins are cross-platform; COM/VSTO add-ins are legacy and Windows-only.
Integration with Microsoft Graph and Power Platform is common for data access and automation.
The exam focuses on web add-ins; SharePoint Add-ins are deprecated (use SPFx instead).
Centralized deployment is the recommended method for enterprise rollouts.
These come up on the exam all the time. Here's how to tell them apart.
Web Add-ins (Modern)
Cross-platform: works on Windows, Mac, Web, and mobile (limited).
Uses web technologies (HTML, CSS, JS).
Sandboxed: limited access to system resources.
Deployed via manifest XML; centralized deployment via admin center.
Automatic updates; no installer required.
COM/VSTO Add-ins (Legacy)
Windows-only; no Mac or Web support.
Uses .NET (C#/VB) or C++.
Full access to system resources; can cause crashes.
Installed via MSI or setup.exe; manual updates.
Requires administrative privileges to install.
Mistake
Add-ins are standalone applications that run independently of Office apps.
Correct
Add-ins run inside a host Office application (e.g., Word, Excel, Outlook) and cannot function without the host. They are loaded into the host's process and use Office.js to interact with the document or mailbox.
Mistake
All add-ins require ReadWriteMailbox permission to function.
Correct
Permissions are granular and depend on the add-in's functionality. An add-in that only reads document content needs only ReadDocument permission. ReadWriteMailbox is specifically for mail add-ins that need to read/write mailbox items.
Mistake
Side-loading is the recommended deployment method for enterprise rollouts.
Correct
Side-loading is intended for development and testing only. For production deployment to multiple users, administrators should use centralized deployment via the Microsoft 365 admin center or publish to AppSource.
Mistake
Add-ins can be developed using any programming language and framework.
Correct
Modern Office Add-ins (web add-ins) must use web technologies: HTML, CSS, and JavaScript. They cannot be written in .NET languages like C# (that would be VSTO add-ins, which are legacy and not supported on all platforms).
Mistake
Once deployed, add-ins cannot be updated without user intervention.
Correct
Add-ins are updated by updating the manifest URL or the web application. Centralized deployment allows administrators to update the manifest, and the new version is automatically picked up by clients (with some caching delay). Users do not need to manually reinstall.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An add-in is a lightweight extension that runs inside a host application (e.g., Word, Outlook) to provide additional functionality. It cannot run standalone. An app, on the other hand, is a separate application that runs independently, such as a mobile app or a desktop application. For MS-900, remember that add-ins extend Office apps, while apps are standalone solutions like Power Apps or third-party software.
Use centralized deployment via the Microsoft 365 admin center. Go to Settings > Integrated Apps > Add-ins, then click 'Deploy Add-in' and upload the manifest XML file. You can assign the add-in to all users, specific users, or groups. This is the recommended method for enterprise deployment. Alternatively, for Outlook add-ins, you can use the Exchange admin center.
Add-ins can request one of four permission levels: Restricted (access to document metadata only), ReadDocument (read document content), ReadWriteDocument (read and write document content), and ReadWriteMailbox (for mail add-ins, read and write mailbox items). The permission is declared in the manifest and must be appropriate for the add-in's functionality. Users or administrators must consent to these permissions.
No, modern Office Add-ins (web add-ins) must be built using web technologies: HTML, CSS, and JavaScript. They cannot use .NET languages like C# or VB.NET. .NET-based add-ins are called VSTO (Visual Studio Tools for Office) add-ins, which are legacy and only run on Windows. For cross-platform support, you must use the web add-in model.
The manifest is an XML file that describes the add-in to the host application. It includes the add-in's identity (ID, version), display name, description, icons, supported host apps, activation rules (for mail add-ins), required permissions, and the URLs of the web pages that provide the add-in's UI and logic. The manifest must be hosted on an HTTPS endpoint and is used by the host app to load and activate the add-in.
Add-ins can use the Office.js method `Office.context.auth.getAccessTokenAsync` to obtain an access token for the signed-in user. This token can then be used to call Microsoft Graph APIs. The add-in must be registered in Azure AD and have the necessary API permissions configured. The manifest does not store secrets; instead, the add-in uses the user's identity via the Office auth broker.
AppSource is Microsoft's public app marketplace for business applications, including Office Add-ins, Teams apps, Power Platform solutions, and more. Developers can publish their add-ins to AppSource for public availability. Users can install add-ins directly from AppSource. For enterprise deployment, administrators typically prefer centralized deployment to control which add-ins are available.
You've just covered Microsoft 365 Add-ins and App Integrations — now see how well it sticks with free MS-900 practice questions. Full explanations included, no account needed.
Done with this chapter?