GDAP / M365 Management Portal Guide

This guide covers the Ops Center’s Microsoft 365 capability — the first-wave foundation of what will eventually be a much broader operations platform. Today, that foundation covers how RebelPSA connects to a customer’s Microsoft 365 tenant, three read-only Insight tracks (Security Posture, Service Health, Microsoft Updates), and a first set of write actions for managing users and licenses.

Everything in the Ops Center’s Microsoft 365 capability is organized into two planes, and this split is both how it’s presented to you and how it’s built underneath:

• Insight (read) — every read-and-alert surface. It shows you what’s happening across your managed customer tenants — security posture, service health, upcoming Microsoft changes — without ever changing anything in the customer’s environment.
• Control (write) — every action surface. This is where a technician does something inside a customer’s Microsoft 365 environment — resetting a password, assigning a license, disabling sign-in.

RebelPSA uses two different connection methods, with a clear primary and a clear fallback.

GDAP (Primary Method)

GDAP — Granular Delegated Admin Privileges, Microsoft’s own partner-relationship model — is the primary way RebelPSA connects to your customers’ Microsoft 365 tenants, and it’s built specifically to scale across many customers at once rather than requiring a separate setup per client.

• One GDAP relationship covers your whole RebelPSA tenant. A single partner relationship, established once, fans out to every customer tenant that approves it — you don’t set up a new connection for each individual client.
• Customers are discovered automatically through Microsoft, then matched to the correct company record in your CRM. If a customer can’t be automatically matched, it lands in a technician review queue rather than being auto-created incorrectly.
• Once your organization’s partner credential is established, individual technicians never need to separately authenticate to Microsoft — the system handles token exchange behind the scenes for each customer as needed.

Direct Connection (Fallback)

For edge cases where a GDAP relationship isn’t available or appropriate, a Direct connection — one dedicated app registration per client company — is available instead.

• A Direct connection is structurally isolated from any mailbox/calendar credentials for that same client, so applying a Conditional Access policy to M365 admin actions never affects mail or calendar sync.
• Each Direct connection is explicitly flagged read-only or write-capable, and the broader management permissions are only ever requested on connections flagged write-capable.

A per-client view of Microsoft 365 security health, built from Microsoft’s own security signal sources:

A mirror of the Microsoft 365 Admin Center’s own service health view — this track is purely operational, not a security signal, so a service degradation never feeds into the security alert model above.

Clicking an advisory badge opens a detail panel with the full advisory record — title, affected service, impact summary, advisory ID, affected feature groups, the latest message, and the complete message history, stored exactly as Microsoft published it.

A searchable feed of Microsoft 365 change communications — Message Center posts and Microsoft 365 Roadmap items — so you can stay ahead of feature changes, retirements, and rollouts before a customer is surprised by one.

• Each update shows its title, affected product(s), category (updated / retirement / new feature / plan-for-change), latest update date, and a short excerpt, with a full detail view available.
• Filter by product, category, and date, or free-text search across title and body.

Per-Tenant Relevance Filter

By default, every tenant sees the same full Microsoft update feed — this keeps things simple and requires no extra computation. Your organization can optionally turn on a per-tenant relevance filter that narrows the feed to only what’s relevant to a given client’s licenses and services.

The first set of write actions available lets you manage the core user lifecycle directly inside RebelPSA, without needing to jump into the Microsoft 365 admin center separately:

The following are planned in detail but are not available to use today. If a customer or colleague asks about any of these, the honest answer is: planned, not yet built.

• Groups, distribution lists, and Enterprise App role assignment
• Shared mailboxes, aliases, forwarding, and convert-to-shared for offboarding
• Intune device actions (wipe, retire, sync, compliance state)
• Per-user MFA reset/re-enrollment and Conditional Access review from within RebelPSA
• Bulk actions applied across multiple client tenants at once
• Tenant Assessments against frameworks like CIS, Essential 8, NIS2, or CMMC, and branded assessment reports
• Copilot readiness scoring and ongoing Copilot management
• Policy backup, restore, and drift detection
• SaaS/Shadow-IT discovery
• Broader reporting/usage analytics and compliance-readiness auditing
• Automated alerts-to-workflow, approval routing, and flow agents

Checking a client’s security standing before a call

• Open that client’s Security Scorecard and note their Secure Score and MFA adoption rate.
• Check the Risky Users panel for anything flagged that needs a conversation.
• Check Coverage Gaps for any devices with no security vendor reporting at all.

Resetting a user’s password for a client

• Open that client’s user list and find the user.
• Use Reset Password, choosing whether to force a change at next login.
• Confirm the action — this executes directly against the customer’s Microsoft 365 tenant.

Staying ahead of a Microsoft change that could affect clients

• Check the Microsoft Updates feed regularly or search it when you hear about a change secondhand.
• Read the detail view for affected products and whether action is required.
• Communicate proactively with any affected client before the change lands, since update-to-ticket automation isn’t built yet.