Privacy Policy
Effective Date: September 6, 2026
This Privacy Policy explains how Margin for Outlook (the "Add-in," "Service," or "we"/"us"/"our") collects, uses, shares, and protects information when you use the Add-in. Margin for Outlook is an Outlook task-pane add-in that lets members of an organization add internal collaborative comments and private notes alongside their email conversations.
Margin for Outlook is operated by Younes Azamiyan (ABN 53 691 109 499), a software developer based in New South Wales, Australia. We handle the personal information described below in line with the Australian Privacy Principles, as a matter of our own practice.
Where this policy stands. The Add-in is in private beta and is operated by an individual. The descriptions of what we collect, store, and delete are accurate and current. The legal characterisations in this policy — who is controller, who is processor, which statutory regimes apply — are our own assessment and have not been reviewed by a lawyer.
Who decides what happens to your data. The Add-in runs inside your organization's Microsoft 365 tenant, and your organization decides who uses it, what is written in it, and how long that content is kept. We therefore treat your organization as the controller of the comments, notes, memberships, and preferences held in the Add-in, and ourselves as a processor acting on its instructions. That is how we operate in practice; the characterisation itself is our own assessment, not a legal opinion.
One limit we place on ourselves. Your organization can direct us to delete the private notes in its tenant, as it can any other data we hold for it. It cannot obtain their contents from us: a note is written by one person for themselves, and we do not disclose note content to anyone but its author, whatever the instruction. The only exception is where we are compelled by law or legal process. See Sections 6 and 8.
We are the controller for a narrower set of information we decide to collect for our own purposes: feedback and support requests you send us, operational and error-monitoring logs, and the list of organizations invited to the beta. Section 3a sets out our legal basis for each of these.
The practical consequence is in Section 8: for data your organization controls, requests are best directed to your organization's administrator, and we assist them.
We have designed the Add-in to access as little of your email as possible and to encrypt the content you create. This policy describes exactly what that means.
1. Introduction
We are committed to protecting your privacy. This policy applies to the Margin for Outlook add-in and its backend service. It does not apply to Microsoft Outlook, Microsoft 365, or any third-party services that you access independently of the Add-in.
By using the Add-in, you agree to the collection and use of information as described in this policy.
2. Information We Collect
We collect only the information needed to provide the Service.
2.1 Identity information (from Microsoft Entra ID)
When you sign in, we receive the following from your Microsoft 365 identity token:
-
Your Microsoft Entra user ID (
oidobject identifier). -
Your tenant ID (
tid) — the identifier of your organization's Microsoft 365 tenant. - Your email address (user principal name).
- Your display name.
2.2 Email association data (identifiers only)
To attach your comments and notes to the correct email, the Add-in reads a limited set of properties from the currently selected message via Office.js:
-
The conversation identifier (
conversationId) and item identifier (itemId) of the email. - The email subject line — used only at runtime to display context and, optionally, within a support request you choose to send. We do not store standalone subject lines as part of normal comment/note storage.
- For shared mailboxes, the shared mailbox owner's email address, to determine which mailbox a comment belongs to.
Important: We do not store the body of your emails, the recipients of your emails, attachments, or sender/recipient address books. We store only the conversation and item identifiers needed to link your comments and notes to a message.
2.3 Content you create
- Comments and private notes that you write. Comments are limited to 10,000 characters and private notes to 5,000 characters, and both are encrypted at rest (see Section 7).
- Feedback and support requests that you choose to send. For feedback, we store the message text and whether it is positive or negative, associated with your user and tenant identifiers. If you opt in to being contacted, your email address is included in the notification we receive but is not stored in our database. Support requests are delivered to us by email rather than stored as records.
- Membership data: the email addresses and roles of members you invite to a mailbox, and verification codes (stored only in hashed form).
2.4 Usage and preference data
- Preference flags and timestamps that drive the user experience (for example, onboarding completion, banner dismissals, and usage reminders).
- Operational logs (request method, path, status, and a request identifier) used for reliability and troubleshooting. These logs do not include your email content and do not identify you; the verbose authentication logging that could is disabled by default and is never enabled in production. Who did what is recorded separately, in the audit records below.
- Audit records of security-relevant actions, so that we can answer your organization's questions about who did what and when: which member accessed a mailbox's comments on a given day, who invited, approved, removed or changed the role of a member, who claimed or transferred a mailbox, who deleted or restored a comment, who exported comments or their own notes, and when we ourselves answered a data request for a person, a mailbox, or an organization — an export or an erasure run by our operator, recorded with the counts of what was returned or removed. Each record holds the internal identifiers of the people involved (never your email content, and never a comment or note body), the action, the mailbox, the time, and the request identifier. Invitations sent to someone who has not yet used the Service record the invited address, since no other identifier exists for them yet. These records are for our operator and your organization on request; there is no in-app view of them. We hold this data because it is necessary to keep the Service secure and to answer your organization's requests (Australian Privacy Principle 6.2(a) and 11.1; GDPR Article 6(1)(f), where it applies), and it is deleted after 12 months (Section 6).
3. How We Use Your Information
| Information | Purpose |
|---|---|
| Entra user ID, tenant ID, display name, email | Authenticate you, enforce tenant isolation, attribute comments/notes, and display authorship |
| Conversation ID / item ID | Link your comments and notes to the correct email conversation |
| Comment and note content | Provide the core collaboration and private-notes features |
| Membership data (emails, roles, hashed codes) | Manage who can access shared comments in a mailbox and verify invitations |
| Feedback and support content | Respond to your requests and improve the Service |
| Preference and usage data | Personalize and improve the in-app experience |
| Operational logs | Maintain security, reliability, and troubleshoot issues |
| Audit records | Answer your organization's questions about who did what and when; investigate security incidents |
We do not use your information for advertising, and we do not sell your personal data.
3a. Our legal basis for processing
Where the GDPR or an equivalent law applies, processing needs a legal basis. Which basis applies depends on whether we are acting as a processor for your organization or as a controller in our own right (see the note at the top of this policy).
| Information | Our role | Legal basis |
|---|---|---|
| Comments, membership, preferences, and the identifiers that link them to a conversation | Processor | We process these only on your organization's documented instructions. Your organization determines its own legal basis for holding them |
| Private notes | Processor | Same basis, with one limit: we act on instructions to delete them, and never on instructions to disclose their contents to anyone but their author (Sections 1 and 6) |
| Feedback and support requests you send us | Controller | Performance of our agreement with you, and our legitimate interests in responding to you and improving the Service |
| Operational logs, error monitoring, and rate limiting | Controller | Our legitimate interests in keeping the Service secure, available, and free from abuse |
| Audit records (Section 2.4) | Controller | Our legitimate interests in keeping the Service secure and in being able to answer your organization's questions about who did what in its mailboxes |
| The list of organizations invited to the beta | Controller | Our legitimate interests in administering access to the Service |
Where we rely on legitimate interests, we have considered whether those interests are overridden by your interests, rights, and freedoms. You may request a summary of that assessment using the contact details in Section 12.
4. Microsoft Integration
The Add-in operates within the Microsoft 365 ecosystem and relies on Microsoft Entra ID for sign-in.
-
Authentication uses single sign-on (SSO) through Office.js
(
getAccessToken()). Sign-in is required on every session; there are no bypasses. -
The Add-in requests the following scopes:
access_as_user,openid,profile,email, andUser.ReadBasic.All. -
The Add-in itself does not call Microsoft Graph directly. Our
backend performs an on-behalf-of (OBO) token exchange with Microsoft and uses
User.ReadBasic.Allto look up the Microsoft Entra object identifier for an email address. It does this in two cases: to link comments and notes on a shared mailbox to a stable identifier for that mailbox (an object ID does not change when an email address or username does), and to confirm that an invited member belongs to a user in your tenant. Only the directory object identifier is read; no other profile information is retrieved or stored through this lookup. If this permission is not granted, your private notes still work: they fall back to using the mailbox email address as their identifier; only shared comments require the object identifier. -
Mailbox access uses the
ReadWriteItempermission. Reading is limited to the email you currently have open; the only thing the Add-in ever writes is an Outlook category on that email, and only when that category has been switched on — the shared comment category by a moderator of the mailbox, the category marking your own private notes by you. The Add-in cannot send, move, delete, or modify the content of your email, and cannot access other items in your mailbox. - Outlook categories are visible to everyone with access to the mailbox. A category marking your private notes is opt-in per person and carries your name — the note's content is never shared, but the fact that you have notes on a thread would be visible to others with mailbox access. It is off unless you turn it on.
Your use of Microsoft Outlook and Microsoft 365 is governed by Microsoft's own privacy terms.
5. Data Sharing and Sub-processors
We do not sell your data and we do not share it with advertising networks. We share information only with the service providers necessary to operate the Add-in:
- Microsoft — for authentication (Entra ID) and directory lookups (Microsoft Graph) when verifying member invitations.
- Neon (neon.com) — our managed PostgreSQL database provider, hosted in the Sydney, Australia region. This is where the information we store is held, including your identity details, your comments and notes (encrypted at rest — see Section 7), membership data, preferences, and feedback records. The service is operated by Neon, LLC, whose parent company is Databricks, Inc., based in the United States — see the overseas-disclosure note below.
- SMTP2GO (smtp2go.com) — our transactional email provider, operated by Sand Dune Mail Limited (New Zealand), sending from its Sydney, Australia data centre. We use it to deliver invitation/verification emails, and to relay feedback and support requests. Depending on the action, SMTP2GO may process recipient email addresses, verification codes, and the text of feedback or support messages.
In addition, we use the following infrastructure and operational sub-processors:
- Cloudflare (cloudflare.com) — our edge network and DNS provider. Every request the Add-in makes to our API passes through Cloudflare, which terminates the encrypted connection at its edge and forwards the request to our backend. It therefore handles request metadata (including your IP address) and request content in transit. Cloudflare does not store your comments or notes.
- Sentry — error monitoring. It receives error context that can include your user and tenant identifiers. It does not receive your comment or note content.
- Microsoft Azure Key Vault — secure storage of encryption keys in production. No user content is sent to it; we only retrieve keys.
- Redis — distributed rate-limiting counters keyed by IP address or user ID. No email content is stored. (May be used, depending on deployment configuration.)
We do not use general-purpose analytics or marketing telemetry (for example, Google Analytics, Mixpanel, or Application Insights).
Data location and overseas disclosure. The information we store is held in Australia: our database is hosted in the Sydney region, and our application backend and encryption-key storage run in the Microsoft Azure Australia East region. The Add-in's static web files — which contain no personal information — are served from a Microsoft Azure region in the United States.
Two of the companies operating that Australian infrastructure are themselves based overseas. Where the data sits and who operates it are separate questions, and both matter: the data stays in Australia, but the company operating it may be able to reach it from where it is. Our database provider is Neon, LLC, whose parent company Databricks, Inc. is based in the United States — this is the store that holds everything described in Section 2. Our email provider, SMTP2GO, sends from its Sydney, Australia data centre but is operated by a company based in New Zealand, so email-related data may be accessible to it there.
Two further providers process data overseas outright. Sentry, our error-monitoring provider, is based in the United States, so the error and diagnostic identifiers sent to it are processed overseas. Cloudflare operates a global network, so requests are handled at whichever of its locations is nearest to you.
Transfers of European and UK personal data. Australia has not been the subject of an adequacy decision by the European Commission. We do not currently have Standard Contractual Clauses or a UK International Data Transfer Addendum in place, and we cannot supply them today. Where an organization subject to the EU or UK GDPR wants to use the Add-in, we will put a written data processing agreement in place with it first — incorporating the European Commission's Standard Contractual Clauses, together with the UK International Data Transfer Addendum where UK data is involved, and supported by an assessment of the laws of the destination country. If that applies to your organization, contact us using the details in Section 12 before deploying the Add-in. New Zealand, where our email provider is domiciled, is covered by an EU adequacy decision.
We choose sub-processors whose own published terms and security commitments are consistent with this policy, and we name every one of them above. We have not yet completed a formal assessment of each provider's contractual terms against the Australian Privacy Principles.
We may also disclose information if required to do so by law or valid legal process, or to protect the rights, safety, and security of our users and the Service.
6. Data Retention
- Comments are retained for as long as they are needed to provide the Service to your organization.
- Private notes are retained for as long as you keep them. You can delete any note yourself at any time, and export all of your notes from the Add-in. Your organization can direct us to delete the notes held in its tenant — for example when it stops using the Add-in — but it cannot obtain their contents: see End of service below and Section 8.
- When a comment is deleted, it is soft-deleted: it is removed from normal views, but the record is retained server-side for audit and integrity purposes. Comment edits and self-deletion by the author are available only within a 15-minute window after creation; moderators may delete comments at any time.
- Deleted comments are permanently erased after 30 days. On a scheduled basis, the content of any comment that has been deleted for more than 30 days is irreversibly removed from our database (and the record of who deleted it is cleared). A minimal, content-free placeholder may be retained so that reply threads remain coherent, but the comment text itself is gone from our live systems and cannot be recovered from them (see Backups below for how long an erased comment may persist in backup copies).
- Backups. We take a nightly encrypted backup of our database so that we can recover from data loss or corruption. Each backup is kept for 14 days, after which it is deleted; for up to a further 30 days a deleted backup remains recoverable in our storage provider as protection against accidental or malicious deletion. Content erased from the live database therefore continues to exist in backups until those backups expire — in the worst case, about 44 days after erasure — after which it is unrecoverable.
- Unaccepted invitations. When you are invited to a mailbox, or ask for access to one, we hold your email address and a hashed verification code until the invitation is accepted. The code itself is emailed to the mailbox you are joining, not to you, so the people who can already read that mailbox can see that you were invited. The same applies to an unfinished claim of a mailbox: we hold which mailbox you tried to claim and a hashed code until you finish or the code expires (24 hours) — at which point the record is deleted. An invitation that is never accepted is deleted 30 days after it expires, and a request that is declined is deleted 30 days after it is declined. Open access requests that are never actioned are deleted after 90 days.
- Feedback records are retained for 24 months from submission, after which they are deleted. Support requests reach us as email rather than as database records, and are retained in our support mailbox for as long as needed to handle the request and any follow-up.
- Operational logs are retained for 30 days. Error-monitoring records held by Sentry are retained for 30 days under its retention policy.
- Audit records (Section 2.4) are retained for 12 months from the event they record, then deleted. When a person's data is erased, audit records that name them are kept for the rest of that period but no longer identify them: the identifiers they hold point at a record that has been blanked, and any invitation address is removed. When an organization's data is erased at end of service, its audit records are deleted with it.
- End of service. If your organization stops using the Add-in, we delete or return the personal data we hold on its behalf within 30 days of the end of the relationship, at your organization's choice, except where we are required by law to retain it. The backup timeline described above applies to that deletion in the same way.
- Private notes are deleted, never returned. The choice above — delete or return — applies to shared content. Private notes are only ever deleted: when your organization's data is returned to it, the file we produce contains no note content, and the notes themselves are destroyed without being read. This is a limit we place on ourselves, and the only exception is where we are compelled to disclose them by law or legal process. If you want a copy of your own notes, take one from the Add-in before your organization's use ends, or ask us for one — see Section 8.
To request deletion of your data, contact us at [email protected] (see Section 8).
7. Data Security
We apply technical and organizational measures to protect your information, including:
- Encryption at rest of all comment and note content using AES-256-GCM, with keys managed in Microsoft Azure Key Vault in production.
- Encryption in transit over HTTPS/TLS, with HTTP Strict Transport Security (HSTS) enforced.
- Tenant isolation as a hard requirement: every database query is scoped by your organization's tenant identifier, taken from your signed Microsoft identity token, so that one organization's data is not reachable from another organization's session. This is enforced in code and covered by automated tests.
- Authentication with RS256-signed Microsoft Entra ID tokens, validated against Microsoft's published signing keys (JWKS), including issuer, audience, and expiration checks.
- Rate limiting to protect against abuse, applied globally and more strictly on sensitive actions.
- Cross-site scripting defences: comment and note content is stored and displayed as plain text, never as HTML. The task pane escapes it on render, and links are restricted to an allowlist of safe URL schemes.
- Secrets management through environment configuration and Azure Key Vault, with security HTTP headers applied to all responses.
No method of transmission or storage is completely secure, but we work to protect your information using industry-standard practices.
8. Your Rights
Wherever you are, you can ask us to:
- Access the personal information we hold about you.
- Correct personal information that is inaccurate, out of date, incomplete, irrelevant, or misleading.
- Complain about how we handle your personal information. Raise it with us first using the details in Section 12. If you are not satisfied with our response and you are in Australia, you can take the complaint to the Office of the Australian Information Commissioner (OAIC) at oaic.gov.au.
If you are in the European Union or the United Kingdom, or another jurisdiction with equivalent laws, you may additionally have rights to:
- Delete your personal data ("right to erasure").
- Port your data to another service, in a structured, commonly used, machine-readable format.
- Object to processing we carry out on the basis of our legitimate interests.
- Restrict processing — to have us hold your data without further use while a dispute about its accuracy or our basis for holding it is resolved.
- Withdraw consent at any time, where we rely on your consent. Withdrawing it does not affect processing already carried out.
- Complain to a supervisory authority in the country where you live or work, or where you believe the issue arose. If you are in Australia, that is the Office of the Australian Information Commissioner (see above).
We do not carry out automated decision-making or profiling that produces legal or similarly significant effects.
How to exercise these rights. For the comments, notes, memberships, and preferences held in the Add-in, your organization is the controller — it decides what is kept and for how long, and it is best placed to confirm your identity. Direct those requests to your organization's administrator; where they ask us to act, we assist them promptly. For the information we hold as controller in our own right — feedback, support requests, and operational logs — contact us directly at [email protected].
Your private notes are an exception, in one direction. Your organization can have them deleted, but it cannot get a copy: we do not release note content to your administrator, or to anyone else, on anyone's instruction but yours. To get a copy of your own notes, use the export in the Add-in, or write to us at [email protected] from the address on your account. The only circumstance in which we would disclose note content otherwise is where a law or legal process compels us to.
We respond to requests within one month of receiving them. If a request is complex, or you have made several, we may extend that by up to two further months, and will tell you within the first month if we do.
One thing to know about deletion. We take nightly backups and keep them for a limited period (see Section 6). When we erase something from our live systems it is gone from them immediately, but it continues to exist in backup copies until those copies expire — in the worst case about 44 days later. We never use a backup to bring erased data back into service, and if we ever have to restore from one to recover from data loss, we re-apply any erasures as part of that recovery.
9. Cookies and Local Storage
The Add-in does not use cookies for authentication. Sign-in tokens are obtained through Office.js and sent in the request authorization header; they are not persisted in cookies.
The Add-in may use the browser's local storage within the task pane to remember user-interface state (such as onboarding progress or dismissed banners). This data stays on your device and is not used for tracking.
This storage exists only to provide the task pane you have opened: without it the pane cannot remember the state it was left in between sessions. It is not used for advertising, analytics, profiling, or tracking you across sites, and we do not display a consent banner for it.
10. Children's Privacy
The Add-in is intended for use by organizations and their staff through Microsoft 365 work or school accounts that the organization provisions. It is not directed to children.
We are not involved in the creation of these accounts and do not receive any date-of-birth or age information about users, so we have no means of independently verifying a user's age. Because access to the Add-in is provisioned and approved by your organization's administrators, your organization is responsible for ensuring that the individuals it authorizes to use the Add-in meet the applicable age requirements (see the Eligibility section of our Terms of Service). Consistent with this, we do not knowingly collect personal data from anyone under the age of 16.
If you or your organization believe that a child has provided us with personal data, contact us at [email protected] and we will delete it.
11. Changes to This Policy
We may update this Privacy Policy from time to time. When we do, we will revise the "Effective Date" above and communicate material changes through the Add-in or by other reasonable means. Your continued use of the Add-in after changes take effect constitutes acceptance of the revised policy.
12. Contact Information
For privacy questions or to exercise your rights, contact us at:
- Privacy contact: Younes Azamiyan (ABN 53 691 109 499), operator of Margin for Outlook, New South Wales, Australia
- Support / privacy requests: [email protected]
- Website: https://marginforoutlook.com
We have not appointed a Data Protection Officer; the operator named above is the contact point for all privacy matters.