Integrations. Microsoft 365
Microsoft 365 integration that connects the inbox where work arrives to the system that runs it.
Most of the work a business gets arrives in Outlook. The order lands as an email to a shared mailbox, the change request comes in as a reply, and the meeting that commits a crew sits on somebody's calendar. The business system finds out later, when a person retypes it. Or never, when they don't. That gap is where jobs get missed and where two people give a customer two different answers.
We connect Outlook mail and calendar, Teams, SharePoint, and OneDrive to the system where your work is tracked, through Microsoft Graph, Microsoft's one API across the whole tenant. Mail stays in Outlook. Documents stay in SharePoint, because that's where your people already are. What changes is that the system running the work hears about the email, the booking and the file the moment they happen. Nobody has to go tell it.
What we connect
What gets connected between Microsoft 365 and your other systems?
The flows below are the ones we build most often. The scope for your integration names exactly which of them apply, in which direction, and which system wins when the two disagree.
- Inbound email turned into records, so a message to a shared mailbox like orders@ or service@ creates or updates the job in your system with a link back to the original thread. The whole history sits one click from the record, and nobody has to go digging through somebody's mail folders for it.
- Outbound mail sent through your own mailboxes, so quotes, confirmations and status updates go out from your domain. They thread properly with the customer's replies and land in a sent folder anyone can audit.
- Calendar events tied to jobs and bookings, created with the right people invited when work is scheduled and read back when someone drags the meeting. Move it in Outlook and the job moves too, so the calendar and the system can't quietly disagree.
- Teams messages posted into the channel where your team already talks when something needs eyes. A new lead, a stalled approval, a sync failure. Nobody has to remember to go check a dashboard.
- Job folders in SharePoint or OneDrive, created per project with the contract, photos and drawings filed in them and linked from the record. Documents live in one governed place and stop being attachments scattered across six mailboxes.
- Sign-in and permissions through your Microsoft accounts, so the connected system uses the logins and groups you already manage in Microsoft 365. There's no second list of users to maintain and nothing to drift out of date.
How it works
How does a Microsoft 365 integration work?
Microsoft Graph is one REST API over the whole tenant. Mail, calendars, Teams, SharePoint, OneDrive and the user directory behind them, all secured with OAuth through Microsoft Entra. An integration is an app registered in your tenant with a written list of permissions, and most of the permissions worth having need a tenant admin to consent to them. We treat that as a feature. Before your admin ever sees the list, it's already cut to the minimum scope. Read access where read is enough, one shared mailbox when one mailbox is what the flow reads, SharePoint access limited to the sites the integration actually touches.
Graph tells us about changes through subscriptions, which are its version of webhooks. Our endpoint proves it's really ours in a validation handshake, gets a notification when a message arrives or an event changes, then goes and fetches the full record from Graph. It never acts on the pushed body alone. Subscriptions are short-lived by design, measured in days, so renewal runs on a schedule and gets built early. A delta sweep re-reads what changed since the last run, which catches anything a notification missed while an endpoint was down.
Graph throttles busy apps and answers with a retry-after when it does, so calls back off and queue up. Every write is keyed to a stable id, the message or the event or the file on Microsoft's side and your record on the other, so a repeated notification or a retried call can't create the same job twice. A reconciliation report lists messages that never became records, and records with no source behind them. A monitor watches the subscriptions themselves, because an expired subscription throws no errors at all. It just goes quiet.
The stakes
What does a bad Microsoft 365 integration cost you?
More than the build, because integrations fail without setting off an alarm. Nobody gets a message saying the numbers stopped agreeing. Somebody notices at month end, and then nobody trusts either system until it is proven again. The failures below are the ones worth designing against from the start.
- A subscription expires and nobody renews it. Mail keeps arriving in the shared mailbox, records stop being created, and everything looks calm, because an expired subscription doesn't throw an error. The first sign is a customer asking why nobody answered.
- One email becomes two jobs. Graph can deliver a notification more than once, and a sweep can overlap with a notification, so a handler that isn't keyed to the message creates duplicates. They get scheduled, worked and invoiced separately.
- The app is granted more than it needs. An integration built for one shared mailbox ends up with read access to every mailbox in the company, and one leaked credential now exposes correspondence it never had a reason to see. Your next security review finds it. The finding is fair.
The order of work
What happens, in what order, on a Microsoft 365 integration?
In this order, every time. The mapping comes before the code, and the reconciliation comes before we call it done. Nothing here is a date. The sequence is fixed, and the runway is set in your written scope once we have seen your actual data.
- 01
Write the permission list first
Before any code, we list which mailboxes, calendars, sites and channels the integration touches, and which Graph permissions that takes at the minimum scope for each flow. Whether the app acts as itself or on behalf of a signed-in person gets decided per flow and written down. Your admin reads that list before anyone asks them to consent to it.
- 02
Register the app in your tenant
The app registration is created in your Microsoft 365 tenant and owned by you. Credentials go into a secrets vault with an expiry reminder on them, because Entra credentials expire and an expired one stops the sync cold. Your admin grants consent with the permission list in front of them. We build against test mailboxes, a test site and a test channel before anything real gets watched.
- 03
Build the renewal before the features
Subscription expiry gets handled on day one. Renewals run on a schedule, the validation handshake is honored, and a delta sweep backstops any notification that never arrived. Every inbound message and event is handled by its id, so the second delivery of the same message gets ignored. A throttling response gets backoff, and the call waits its turn.
- 04
Run it alongside the current process
The integration runs while the person who does this by hand keeps doing it, and a reconciliation report compares the two. Messages that made a record, messages that didn't, records with no source message, calendar events that drifted from the job. Go-live is when that person agrees with the report. They're the one who knows what a Tuesday's inbox actually looks like.
- 05
Go live with an alarm on silence
The monitor watches the things that fail quietly. A subscription near expiry, a credential near expiry, a throttling pattern that keeps climbing, a working day with no events from a mailbox that always has them. Any of those tells a person the same day. A Microsoft 365 sync that stops doesn't look broken. It looks like a quiet day.
Limits
What we will not do
Cheaper to hear now than to discover halfway through. If one of these is what you are actually after, we will say so on the first call rather than take the work.
- We won't ask your admin for tenant-wide mailbox access when the flow needs one shared mailbox. If a flow can't be built at a scope you're comfortable granting, we change the flow. Exchange can also pin the app to a named set of mailboxes, so the boundary is enforced on Microsoft's side too.
- We won't build a robot that answers customers from a person's address. Mail the integration sends goes out from a system or shared mailbox, reads like what it is, and lands in a sent folder someone can audit. A person's name on an email means a person sent it.
- We won't delete or auto-archive anything in a mailbox. The mailbox is the paper trail, and half of these projects exist because somebody once needed the original thread. The integration reads, files and links. Cleaning up stays a human decision.
Questions
What people ask about Microsoft 365 integrations
Does the team have to change how they work in Outlook and Teams?
No, and that's the point. Work keeps arriving in the mailbox and conversation stays in Teams, because those habits aren't the problem. The integration watches the places work already lands and keeps the business system in step with them. What people notice is that they stop retyping, and stop getting asked whether they remembered to.
What is Microsoft Graph?
It's the single API Microsoft puts in front of Microsoft 365. Mail, calendars, Teams, SharePoint, OneDrive and the user directory are all reached through it, with one sign-in model and one permission model. That matters because one well-built connection can reach everything a flow needs, and the permission your admin granted for mail doesn't quietly extend to files. Graph is documented publicly, so nothing built on it is proprietary to us.
What will our IT admin have to approve?
An app registration in your tenant, and a specific list of Graph permissions, most of which need admin consent before the integration can run. We write that list at minimum scope and in plain English. This mailbox, this site, read or write. Nothing on the consent screen will surprise them. Someone with the admin role grants consent once, and it can be reviewed or revoked from the Microsoft Entra admin center at any time. If your organization routes requests like this through a security review, the list is written to survive one.
Can the integration read everyone's email?
Only if it's granted that, and it shouldn't be. Flows that act on behalf of a signed-in person see only what that person can see, and flows where the app acts as itself are limited to the permissions your admin consented to. For mailbox access specifically, Exchange can restrict an app to a named set of mailboxes, so an integration built for orders@ is provably unable to open the owner's inbox. We set that restriction up as part of the build. Leaving the scope broad is the easier option and we don't take it.
How does the system find out a new email has arrived?
Graph sends a notification to our endpoint through a subscription, usually within moments of the message landing. The notification says what changed. The integration then goes and fetches the message itself from Graph before it acts, so it never trusts a pushed payload. Subscriptions expire after a few days by design, so the build renews them on a schedule, and a periodic sweep re-reads recent changes to catch anything a notification missed.
What happens if the sync stops overnight?
Nothing is lost, and somebody gets told. The mail is still in the mailbox and the events are still on the calendar, because Microsoft 365 stays the store, so the delta sweep picks up everything that happened while the endpoint was down. Anything that fails for some other reason is queued with its payload for replay. And a monitor treats silence as a fault, because the dangerous failure here is an expired subscription that doesn't throw an error at all.
Can it file documents into SharePoint the way we already organize them?
Yes. The integration creates folders and uploads files through Graph into the sites and libraries you already have, following your naming and your structure. We don't impose ours. A job record in your system links to its folder, so the documents stay in SharePoint under your retention and sharing rules and the business system just knows where they are. Where your libraries use metadata columns, those get set as part of the filing, so your views and your search keep working.
Who owns the connection, and what happens if we part ways?
You do, at every layer. The app registration lives in your Microsoft 365 tenant, the credentials live in your vault, and the code lives in your repository. Your admin can revoke the app's consent from the Entra admin center and the integration stops that minute, with all your mail and files exactly where they were. There's nothing proprietary to us in any of it. The code talks to a documented public API, so any competent developer can pick it up.
Related
Where this fits
An integration is rarely the whole job. Usually it is one part of a CRM, an operations system, or a client portal that needs Microsoft 365 to agree with it.
Tell us which two systems disagree
Book a strategy call, or send a short note about what gets retyped today and where the numbers stop matching.