Tenant

A tenant in the Microsoft cloud is the top-level container for a customer organisation: one Entra ID directory, one set of users and licences, and a collection of environments — Microsoft 365, Power Platform, Dynamics 365, and any Azure subscriptions linked to it. All Dynamics 365 access flows through the tenant's Entra ID; all Power Platform environments belong to the tenant; all licence assignments happen at the tenant level. Tenants are pinned to a specific geographic region at creation, which is why data-residency questions ("where does our data actually live") get answered by which region the tenant was created in, not by a setting changed later.

In practice, the tenant is the boundary that everything else nests inside — a user exists once per tenant regardless of how many environments or apps they touch, a security group defined at the tenant level (via Entra ID) can be reused across every Power Platform environment, and conditional access policies configured once apply tenant-wide rather than per app. This is also why tenant-level decisions carry outsized weight: choosing the wrong region at tenant creation, or ending up with two tenants after a merger or acquisition, is expensive and disruptive to unwind later, involving a genuine tenant-to-tenant migration rather than a configuration change. Tenant administration itself is split across several admin centres — the Microsoft 365 admin centre for users and licences, the Power Platform admin centre for environments and DLP policies, the Business Central admin centre for BC-specific environment settings, and Lifecycle Services for Finance and Operations — each owning a slice of the same underlying tenant.

Where confusion shows up: "tenant" and "environment" get used loosely as if interchangeable, but a tenant is the whole organisation's cloud presence while an environment (a Power Platform environment, a Dataverse instance, an F&O environment in LCS) is one workspace inside that tenant — a single tenant routinely holds a dozen or more environments across dev, test, and production for different apps and business units. One tenant per customer is the standard pattern; multi-tenant configurations exist for specific scenarios (holding companies with genuinely separate IT governance, for instance) but add real administrative complexity and are worth avoiding unless there's a concrete reason for the split.