Security & Deployment

Last updated: August 7, 2026

This document describes how Annotate for Outlook handles data, what leaves your Microsoft 365 environment, and how to deploy the add-in across an organization. It is written for IT administrators and security reviewers.

Architecture at a glance

Personal annotations

When a user writes a private note on an email, the add-in stores it as a custom property on that mail item using the standard loadCustomPropertiesAsync Office.js API. Custom properties are a Microsoft-provided storage mechanism scoped to the add-in and the mailbox. The data lives in Exchange alongside the message.

A lightweight index of annotated emails (subject, sender, a short preview, tags, and timestamps) is kept in Exchange roaming settings, which is what powers cross-email search inside the add-in. Roaming settings are also Microsoft-hosted and tenant-resident.

Consequences of this design that matter for review:

• Personal annotation content is never transmitted to, processed by, or stored on infrastructure operated by the publisher.
• Personal annotations inherit your existing Exchange retention, eDiscovery, backup, and data residency posture, because they are stored in Exchange.
• Revoking the add-in removes the user's ability to view annotations, but does not transmit anything outward.
• There is no publisher-side account, login, or user database for personal use of the product.

What the add-in does not access

Annotate requests the ReadWriteItem permission. This is the minimum permission level required to attach custom properties to a mail item. In practice the add-in reads only:

• The subject line of the currently open message
• The sender's display name or address
• The message and conversation identifiers
• The signed-in user's display name and address

The add-in does not read message bodies, does not access attachments, does not enumerate the mailbox, does not read contacts or calendar data, and contains no analytics, advertising, or third-party tracking scripts.

Hosting and transport

The add-in is a static front-end application. There is no application server, no request logging of mail content, and no server-side rendering. Files are served over HTTPS from a CDN. The manifest restricts the add-in's domain to annotateforoutlook.com.

Shared team annotations (optional)

When an organization enables shared annotations, notes that a user explicitly chooses to share are stored in a hosted PostgreSQL database (Supabase, United States region) rather than in Exchange. This is necessary because the note must be readable by colleagues in other mailboxes, which Exchange custom properties cannot do.

Records stored for a shared annotation:

• Note content (rich text and plain text)
• Author display name and email address
• Conversation identifier and email subject line, so the note attaches to the right thread
• The workspace the note belongs to, which governs who can see it
• Tags and timestamps

Private notes are never uploaded. Only content a user types into the Team tab and explicitly shares is transmitted. Transport is HTTPS.

Before a user can view or post shared annotations, they verify their email address with a one-time code (no password to manage or leak). Access is then governed by workspace membership, enforced at the database level with row-level security. A user sees annotations from a workspace only if there is a membership record tying their verified address to it — membership is never inferred from the client, and the application cannot be tricked into bypassing it.

Workspaces are joined in one of three ways: an administrator invites a specific address; the address matches a domain the workspace has claimed (and only someone holding an address at that domain can claim it); or, for a new corporate domain, the first user creates the workspace and becomes its administrator. Administrator rights can be transferred. Personal email domains (gmail.com, outlook.com and similar) can never be claimed or auto-joined — users on those addresses must be explicitly invited, so unrelated people sharing a consumer provider are never grouped together.

Within a workspace, a user can only post as themselves, and can only edit or delete their own notes. Administrators may additionally remove notes in their own workspace, for offboarding and cleanup.

Known limitations in the current preview

We would rather state these plainly than have a reviewer discover them:

• An append-only audit log exists at the database level, but there is no admin console for reviewing it yet. Requests are handled by contacting support.
• There is no self-service bulk deletion of shared annotations yet.
• Sign-in currently uses Supabase's own verified-email accounts rather than Microsoft Entra ID / SSO. We evaluated Microsoft's Nested App Authentication for this and may adopt it in the future — as of this writing Microsoft is still transitioning tenants off the legacy identity token API a from-Outlook approach would depend on. In the meantime, every session is still backed by a cryptographically verified email, just not one issued by your Microsoft tenant.

Organizations that prefer not to use shared annotations at all can leave the feature unused and run the add-in in personal-only mode, which has none of the above considerations because it never leaves the user's mailbox.

Organization-wide deployment

Annotate can be deployed centrally so users do not install it individually.

Deploy via Microsoft 365 admin center

1. Sign in to the Microsoft 365 admin center as a Global Administrator.
2. Go to Settings → Integrated apps.
3. Select Get apps, then search for Annotate for Outlook.
4. Choose Deploy and assign to the whole organization, specific groups, or specific users.
5. Choose the deployment method: Fixed (always visible), Available (users opt in), or Optional (visible, can be removed).
6. Confirm. Propagation to clients typically takes up to a few hours.

Deploy a manifest directly

For pilots or environments that prefer not to use the marketplace listing, the same admin center flow accepts a manifest file via Upload custom apps. Contact us for a manifest URL.

Client and account requirements

• Microsoft 365 or Exchange account (Exchange Online or Exchange Server with add-in support enabled)
• Outlook on the web, new Outlook for Windows, Outlook for Windows 2016 or later, or Outlook for Mac
• No firewall changes required beyond normal HTTPS access to the add-in domain
• No Microsoft Entra ID app registration, consent grant, or Graph API permission is required

Removing the add-in

Removing the deployment in Integrated apps withdraws it from assigned users. Personal annotations remain stored on the mail items in Exchange and become inaccessible through the add-in interface; they are not transmitted anywhere as part of removal.

Data subject and deletion requests

Personal annotations are user-controlled and deletable from within the add-in at any time. Because they reside in Exchange, they are also covered by your own tenant's data handling processes. For shared team annotation data, deletion requests can be sent to support@annotateforoutlook.com.

Contact

Security questions, deployment support, and requests for additional documentation: support@annotateforoutlook.com. See also our privacy policy.