IT request · Outlook add-in approval

Approve the Email Tracker add-in for Outlook

We use a small self-hosted Outlook add-in that records when our outreach emails are opened and when links in them are clicked. We need it deployed to named users, or those users allowed to install custom add-ins. The security details below are for your review.

Ask: Deploy the add-in to named users (Option A), or grant them My Custom Apps (Option B)
Users: Requester to list names / security group
Add-in type: Outlook web add-in (XML manifest), active in the compose window only
Permission: ReadWriteItem: the draft being written, nothing else
Microsoft APIs: Office.js only. No Microsoft Graph, EWS, OAuth tokens or mailbox-wide access
Hosting: Cloudflare Workers + Cloudflare D1 database, on the requester's Cloudflare account
Endpoint: {{TRACKER_URL}}
Manifest: Sent to IT separately as an .xml file. It contains the private admin URL, so please don't share it further.

Action required

Choose one. Option A keeps control with IT and doesn't widen anyone's permissions.

Option A: Deploy it centrally

Recommended

Microsoft 365 admin center → Settings → Integrated apps → Upload custom apps.
App type Office Add-in → Upload manifest file (.xml) → select the file provided.
Assign to the named users or a security group, not the whole organisation.
Accept the permission prompt (ReadWriteItem) and deploy.

It can take up to 24 hours to appear in Outlook. Users get no extra rights, and IT can remove it at any time.

Option B: Let named users install it

Exchange admin center → Roles → User roles → create a new role assignment policy that copies the default roles and adds My Custom Apps. Leave the default policy unchanged.
Assign it only to the named users:
Set-Mailbox -Identity user@company.com -RoleAssignmentPolicy "Custom Add-ins"
Users then add it in Outlook: Apps → Add apps → My add-ins → Add a custom add-in → Add from file.

Those users could also install other custom add-ins, so Option A is the tighter control.

Network: users need outbound HTTPS to {{TRACKER_HOST}} and appsforoffice.microsoft.com (Microsoft's Office.js library).

What the add-in can and can't touch

It runs only when the user opens the add-in in a draft and clicks Track this email. It does nothing on its own.

Can, for the open draft only

Read the subject and To / Cc / Bcc addresses
Read and rewrite the HTML body: adds a 1×1 image and, depending on the mode the user picks, adds tracking tags (utm_…) to links or routes them through the tracker
Save a tracking ID on that draft (a custom property)
Keep the tracker's access key in the user's Outlook roaming settings

Cannot

Read the inbox, other messages, calendar, contacts or files
Run in the background, on incoming mail, or without a click
Send mail or act on the user's behalf
See other users' mailboxes or any other tenant data
Get a Microsoft sign-in token or call Microsoft Graph / EWS

Data inventory

Everything the system collects, where it comes from, and how it's kept. The email body and attachments never leave Outlook.

Data	Collected from	Kept as
Subject line	Draft, on "Track"	Stored
Recipient addresses	Draft, on "Track"	Stored
Link URLs	Draft, on "Track"	Stored redirect mode only; in tag mode links stay in the email and aren't sent
Body text & attachments	Not collected	Never sent
Open / click time	Recipient's mail app	Stored
IP address	Recipient's mail app	Salted SHA-256 raw IP never stored
Country & city	Cloudflare geolocation	Stored
User-agent string	Recipient's mail app	Stored truncated to 400 chars

Security controls

Transport: HTTPS only. TLS is terminated by Cloudflare, and every URL in the manifest and in tracked emails is https://.
Authentication: The dashboard and API need a 256-bit random access key, compared in constant time. The key is held as an encrypted Cloudflare secret, never in source code.
Hidden admin surface: The dashboard, API and manifest sit under an unguessable path. Every other address returns a blank page. robots.txt and an X-Robots-Tag: noindex header on every response keep it out of search engines.
Tracking IDs: 16-character random IDs (~95 bits), so they can't be enumerated to find other emails' data.
No open redirect: Click links only redirect to http/https URLs registered by an authenticated request. javascript: and other schemes are rejected.
Injection: All database queries are parameterised. The dashboard renders stored values as plain text, never as HTML.
Data at rest: Cloudflare D1, encrypted at rest by Cloudflare.
Supply chain: No runtime dependencies. The only third-party script is Microsoft's Office.js. The app is about 1,000 lines of code, available for review on request.

Known limitations

Listed up front so they can be conditions of approval if needed.

Limitation
Hosted on the requester's Cloudflare account, which may not be company-owned.

If required
Set it up on a company Cloudflare account and serve it from a company subdomain.
Limitation
One shared access key. No per-user accounts, MFA or audit log.

If required
Put the dashboard behind Cloudflare Access (SSO or email one-time code). The tracking links stay unaffected.
Limitation
No automatic retention period. Data stays until deleted, per email, from the dashboard.

If required
Add automatic deletion after a set period, e.g. 90 days.
Limitation
Recipient data (email address, approximate location) is personal data under UK GDPR and PECR.

If required
Mention open/click tracking in our privacy notice and record it in the processing register or DPIA.
Limitation
Some mail filters distrust workers.dev links.

If required
Serve the tracker from a company subdomain instead.