EXPLAINER

Microsoft 365 for Developers

Microsoft 365 (M365) is the cloud suite that includes SharePoint, Exchange, Teams and the identity boundary in Entra ID. Developers extend it with Graph, SPFx and Teams apps rather than scraping the web UI.

Short answer: Microsoft 365 (M365) is the tenant that holds mail, files, sites and Teams. Build against Graph and SPFx, and sign users in with Entra ID.

What it is

Microsoft 365, often shortened to M365, is Microsoft's subscription suite for work: Outlook and Exchange for mail, SharePoint and OneDrive for files, Teams for chat and meetings, plus Office apps and admin portals. Office 365 (O365) is the older name. You will still see it in docs, URLs and licence names. For a developer they are the same tenant story: a directory of users, a set of licensed services, and APIs in front of those services.

M365 is not the same product as Azure. Azure is infrastructure and platform services (compute, storage, functions). M365 is the end-user productivity cloud. They meet at identity: both can use Microsoft Entra ID, and an app can live in Azure while reading mail or files through Microsoft Graph.

Why and when it is used

You care about M365 when the data your app needs already lives there: a user's files, a team's channel, a SharePoint list, a calendar. Building inside the tenant means you inherit sign-in, compliance boundaries and the admin's ability to turn your app off. That is the right trade when you are extending how a company already works.

Use a plain web app on Azure or another host when the product is not about a customer's tenant data. Do not scrape outlook.office.com or sharepoint.com HTML. Those pages change, break automation, and violate the point of Graph. Prefer Graph for data, SPFx for SharePoint UI, and the Teams SDK for tabs and bots inside Teams.

How it works

An organisation gets a tenant, for example contoso.onmicrosoft.com, and licences that turn services on. Users and groups live in Entra ID. Each service stores its own content but Graph exposes a single REST surface: /users, /groups, /sites, /drives, /me/messages, /teams. An app registration holds the client's id. Permissions are either delegated (the app acts as a signed-in user) or application (the app acts as itself, which admins treat as high privilege).

Admins control consent. A permission in your code does nothing until consent exists. Developer tenants from the Microsoft 365 Developer Program give you a sandbox with sample users so you are not experimenting in production.

Technologies and dependencies

Plan on Entra ID app registrations, Graph, and the service you actually touch (SharePoint, Teams, Exchange, Planner). SPFx packages deploy through the SharePoint app catalog. Teams apps deploy through Teams admin or sideloading in a dev tenant. Power Platform is the low-code neighbour: Power Automate and Power Apps sit on the same tenant data but are not a substitute for Graph when you need a real service.

SDKs exist for .NET, JavaScript and Python (@microsoft/microsoft-graph-client and others). Raw HTTP is fine and often clearer. Tokens are OAuth 2.0 access tokens; do not invent a different login for each workload.

How to get started

  1. Join a developer tenant or use a sandbox your admin assigns.
  2. In Entra ID, register an application. Note the application (client) id and the tenant id.
  3. Add the delegated Graph permission you actually need, such as User.Read first, not Mail.ReadWrite on day one.
  4. Sign in with the auth-code flow and call GET https://graph.microsoft.com/v1.0/me.
  5. Open SharePoint and Teams in the same tenant so you can see the objects your next calls will use.
  6. Only then add files, mail or sites. Read the permission docs for the exact scope. Application permissions require admin consent and a daemon design, not a user login.

Keep production tenants and dev tenants apart. Sample data packs are useful; real customer mail is not a test fixture.

Cautions and trade-offs

Graph throttles. Batch and delta queries exist because looping every user every minute will be blocked. Permissions are sharp: application Mail.Read is tenant-wide mail, which most apps do not need. Prefer delegated scopes and least privilege.

Names drift. Office 365, Microsoft 365, and product SKUs do not line up one-to-one with APIs. Licence a feature before you debug a 404. Some admin settings (conditional access, tenant restrictions) will block your dev flow until an admin exempts the app. Finally, M365 data residency and retention are legal questions. Copying a tenant's files into your own database creates a second copy you must secure and delete. Store identifiers and fetch content when you need it, unless you have a written reason to cache.