Microsoft, Microsoft 365, Outlook, SharePoint, OneDrive, Microsoft Teams, Microsoft Graph, Azure, and Entra are trademarks of the Microsoft group of companies. ImpressionsDirect360 is an independent provider and is not affiliated with, sponsored by, or endorsed by Microsoft.
Handing a provider access to your Microsoft 365 is the part that should make you uncomfortable. Here is exactly what we ask for, why each permission exists, and how you take it all back in about a minute without talking to us.
Last reviewed August 22, 2026
These are application permissions, and application permissions are not limited to particular mailboxes or sites. Once your administrator consents, our application can technically reach every mailbox, calendar and SharePoint site in your tenant — whether or not an automation of yours points at any of them. We point the automations only at what you nominate, but that is our configuration choice, not a boundary Microsoft is enforcing on us. The boundary Microsoft does enforce is an ApplicationAccessPolicy, which you create in your own tenant; it covers Exchange only, and there is no equivalent for SharePoint today.
This is the complete set, and it is the same for every customer — it is not assembled per tenant and buying fewer automations does not shrink it. These are application permissions, so they are tenant-wide rather than limited to the mailboxes and sites you nominate; we point the automations only at those, but that is our configuration, not a boundary Microsoft enforces on us. Microsoft's own consent screen is the authoritative statement of what you are granting.
Mail.ReadWriteRead + writeRead the mail an automation is built to handle, file its attachments, and leave a drafted reply in Drafts. Tenant-wide: it reaches every mailbox in your tenant, not only the one an automation points at.
Invoice filing, expense receipts, lead routing
Mail.SendWriteSend the message an automation composes — a morning brief, a meeting prep note, an acknowledgement. Tenant-wide: it can send as any mailbox in your tenant.
Morning digest, meeting prep, notifications
Calendars.ReadRead onlyRead today's meetings so a brief can list them. Read only — we cannot create, move, or cancel anything in a calendar.
Morning digest, meeting prep
Sites.ReadWrite.AllRead + writeFile documents into the SharePoint library an automation is configured for. This is the broadest permission we hold: it reaches every SharePoint site in your tenant, and there is no per-site restriction on it today.
Invoice filing, expense receipts, document filing
User.Read.AllRead onlyResolve who owns what, so a notification reaches the right person and a filed document is attributed correctly. Read only — we cannot create, change, or disable an account.
Routing, mailbox selection during onboarding
Your Microsoft 365 admin consents to a single named ID360 application from inside your own admin center. Its permissions are tenant-wide, not confined to the mailboxes and sites you nominate — we point the automations only at those, but that is our configuration, not a limit Microsoft imposes on us. There is no shared admin account and no password of yours in our hands, and you can withdraw that consent yourself at any time — the access ends the moment you do. Granular delegated administration (GDAP), which adds a hard expiry date to a partner relationship, is created through Microsoft Partner Center; we will move to it when our reseller enrolment completes, and we will not describe it as in place before then.
This is how we work, not a product we ship. We have not built software that manages or reports on delegated relationships — Microsoft's admin center is the system of record, it belongs to you, and it is the place to check what any partner can do in your tenant. During onboarding we agree the roles in writing and you grant them yourself.
admin.microsoft.com, with a Global Administrator account of your own. You never need us present, and you do not need to tell us first.
This is where the consent you granted actually lives. Our access is a single named application in your tenant — not a partner relationship — so this list, not Settings > Partner relationships, is the page that controls it.
Open it and you can see exactly which Microsoft Graph permissions your admin consented to. That screen is authoritative; if it ever differs from the list above, believe it and tell us.
Revoking consent under Permissions, or deleting the enterprise application outright, ends our access immediately and for good. Nothing of yours is deleted — your tenant, licences, mail, and files are unaffected, and any file we filed for you stays exactly where it is.
You do not owe us notice, an explanation, or a support ticket to do this. If revoking breaks an automation you still want, we will help you re-grant a narrower scope.
Your content lives in your own Microsoft 365 tenant, which is a boundary Microsoft enforces — not one we implement. There is no shared pool of customer mail or documents on our side to separate in the first place.
Every automation authenticates against one tenant with that customer's own consent-issued token. A credential for your tenant opens nothing in anyone else's, and revoking yours affects only you.
On the ID360 side, database rules deny by default and scope every record to its owner, with billing and entitlement fields writable only by the server. See the trust page for what backs that.
The short version: your content stays in your tenant, and everything we run around it runs in the United States.
| Data | Where it lives | Notes |
|---|---|---|
| Your mail, files, calendar, and Teams content | Your own Microsoft 365 tenant | In your name, under your billing, in the Microsoft region you chose. We never copy it into a store of ours to make an automation work. |
| Automation logic and run state | Azure Functions and Logic Apps, United States | The code that orchestrates a workflow, plus the run history Azure keeps for it. |
| ID360 AI inference | Google's Gemini API, United States | Every shipping AI feature calls Gemini today. A second, not-yet-used path for open-weight models is restricted to a code-enforced allowlist of US-hosted providers — a build pointed at a non-allowlisted host refuses to start. Your content is not used to train models. |
| Your ID360 account, billing, and Studio content | Google Cloud / Firebase and Stripe, United States | Account records, subscription state, and anything you create in ID360 Studio. Card data stays with Stripe. |
The vendor-by-vendor version, including what data category reaches each one, is on the subprocessors page.
The full true-today versus roadmap breakdown lives on /trust, and how to report a suspected incident is on /trust/incident-response.
Bring your requirements to the setup call and we will write down the exact permissions each automation needs before you grant anything.