Microsoft 365 operations documentation

EasyTenant brings the Microsoft 365 operations you run for your clients every day into a single console. Instead of opening each tenant’s admin portal, you work from one interface and the application acts on the tenant you have selected.

Every action runs with the permissions the client granted to the application, never with your personal credentials. You only see and operate the tenants attached to your organisation.

On first access, sign in with your Microsoft work account: it is what identifies you, and the application never stores a password. You then create your organisation, of which you become the owner.

Before any operation, the subscription must be active: subscribe under Settings → Billing. Until it is, the console redirects you to that page.

It then remains to connect a first client tenant from “Add a client tenant” on the dashboard and, if you work as a team, to invite your technicians under Settings → Team.

For a tenant to appear in the console, one of the client’s administrators must authorise the application once. From the dashboard, the account owner starts “Add a client tenant”: they get a consent link to follow themselves if they have the rights, or to forward to the tenant administrator.

On the client’s side, the link opens a guided EasyTenant page, valid for 1 day and single-use: the administrator signs in with a Global Admin account, approves consent, then assigns the three directory roles — two Microsoft sign-ins in all, nothing more is asked of them. To reassure them: the application requests only strictly necessary permissions, with no access to email content or files; it keeps no standing access, tokens are short-lived and never stored; and the Exchange roles can take up to an hour to take effect.

Consent grants the required permissions. For sensitive operations (password, 2FA, account management), Microsoft also requires directory roles to be assigned to the application. The “Add a client tenant” wizard chains this assignment right after consent. If it fails or stays incomplete, the tenant page shows “Troubleshoot”: missing roles and a PowerShell script as fallback. Without these roles, the operations concerned are refused by Microsoft.

The tenant’s state shows as a dot: red “Consent inactive” while consent isn’t granted, orange “Incomplete setup” once consent is active but roles are missing, green “Ready” once everything is in place. A grey “Roles to check” dot means the application cannot determine the role state — see “Common issues”.

The account has two access levels. The owner holds every permission and manages billing, the team and access rights. Members they invite only get the permissions assigned to them under Settings → Permissions.

If an action is not offered to you while the tenant is active, the matching permission has usually not been granted to you. The owner can enable it in seconds.

Permissions granted under Settings → Permissions apply to every tenant. The owner can also set a per-tenant scope: custom rights then fully replace the member’s global rights on that one tenant, without affecting the others. Only the right to read the audit log stays global, since the log spans every tenant.

The owner adds technicians under Settings → Team by entering their email address. The application generates an invitation link, valid for 7 days and single-use, which the owner copies and forwards to the technician. The member joins the MSP by following the link and signing in with their Microsoft account.

Until a member has activated their account this way, they stay marked “Pending” in the list. A new member has no permissions by default: the owner grants them under Settings → Permissions.

The owner can remove a member at any time, or transfer ownership of the MSP to an already-active member — becoming a member themselves in the process. Billing, team, permissions and administrator account protection stay owner-only.

Access to the console requires an active subscription. It is managed under Settings → Billing, owner-only; members see only the subscription status there.

With no subscription yet, the “Subscribe” button opens secure checkout. Once subscribed, “Manage subscription” opens the portal to change the payment method, retrieve invoices or cancel.

If the subscription becomes inactive, the console redirects to this page and operations are blocked until it is resolved; access is restored as soon as payment is confirmed.

To stop operating on a tenant, the owner uses “Remove” on the tenant’s card on the dashboard. Access is cut immediately and EasyTenant tries to delete the enterprise application from the tenant. If that automatic removal fails, the console says so: a client tenant administrator must then remove it by hand (Entra → Enterprise applications → EasyTenant → Delete). Until that is done, the application stays present on the client side without EasyTenant using it.

Removal can also come from the client: a tenant administrator can revoke consent from their own Entra at any time. The tenant then flips to “Consent inactive” in the console — this is expected; run “Add a client tenant” again if access should be restored.

To close the account entirely, the owner uses “Delete the MSP account” under Settings → Account, in the danger zone. The action is final: the subscription is cancelled, access to every tenant is revoked and the MSP’s data is deleted. Here too, if the application could not be removed automatically from some tenants, the list is shown: each client administrator must delete it by hand from their Entra.

An account holding an administrator role on the client tenant (Global Admin, User Administrator, etc.) is a privileged account: changing its password changes what a client administrator can do, not just a regular user. The application therefore applies an extra rule whenever a password reset targets one of these accounts — including when its role could not be determined, as a precaution.

The applied mode is set from Settings → Account, in the “Administrator account protection” block, only visible to the owner. In “Locked” mode, the reset is refused for everyone, including the MSP owner. In “Approval required” mode (enabled by default), a member who starts the operation does not run it directly: it is filed as an approval request, visible to the owner from the Requests page. The owner, on the other hand, acts directly in this mode — they have no request to send to themselves.

On the Requests page, the owner approves or denies each pending request. Approving runs the operation immediately, under their own name: the generated password is then shown once, as with any reset. Denying or canceling closes the request without any change having been made to the target account.

Some sensitive operations do not run directly but go through an approval request — today, resetting an administrator account’s password when the MSP is in “Approval required” mode (see “Administrator account protection”). These requests are followed from the Requests page.

A member sees only their own requests there and can cancel those still pending. The owner sees the whole queue and approves or denies each one: approving runs the operation immediately under their name, and the result — the generated password, for instance — is shown once in the request’s card.

Each request carries a status: pending, approved, denied or canceled, with the history of recent decisions on the same page. The count of pending requests shows as a badge next to “Requests” in the menu — the whole queue for the owner, their own requests for a member.

Every operation is recorded in the audit log, whether it succeeds or fails, with its author, target and timestamp. The log is available from the “Audit” entry; the page can be filtered by operation and by result (success or failure), and is browsed page by page.

For sensitive operations, Microsoft may require the tenant administrator to have authenticated recently. If such an action is refused, a fresh sign-in by that administrator usually clears the block.