GDAP and delegated admin relationships
How CloudCapsule's tenant access differs from GDAP/DAP relationships, and what to check when you manage both for a client.
If you manage clients under a Granular Delegated Admin Privileges (GDAP) or legacy Delegated Admin Privileges (DAP) relationship, you might assume that relationship also governs what CloudCapsule can see and do in a tenant. It does not. CloudCapsule runs on its own app consent, granted separately per tenant, independent of any partner relationship you hold with Microsoft.
What GDAP and DAP are, at a high level
GDAP, and the older DAP model it is replacing, are Microsoft's mechanisms for giving a partner organization administrative access into a client tenant through the partner's own Partner Center relationship with that client. Access is scoped to specific administrative roles, tied to the partner-client relationship itself, and reviewed or renewed on whatever schedule you have set up with each client. If that relationship is restructured, re-negotiated, or removed, the roles it grants go with it.
How CloudCapsule's access is different
CloudCapsule does not ride on your GDAP or DAP relationship to reach a client tenant. A Global Administrator or Privileged Role Administrator on the client tenant grants consent directly to CloudCapsule, separate from any partner relationship. You choose Read Only (assessment and reporting) or Read & Write (adds remediation and policy deployment) consent. Behind those two levels sit two dedicated app registrations, one for read access and one that adds the write scopes needed for Manage features, each kept as least-privilege as the task allows.
That separation buys you two things. CloudCapsule only touches what its own registration is scoped for, regardless of what roles happen to sit inside a GDAP relationship. And tenant access to CloudCapsule survives changes on the GDAP side: if a relationship lapses, gets renegotiated, or a client switches partners, the consent already granted to CloudCapsule on that tenant keeps working until someone deliberately removes it.
The one place the two do intersect is tenant import. Partner tenant import uses your existing delegated-admin relationships to pull in the list of tenants under your partner tenant. That is a convenience for populating your tenant list, not a substitute for consent. Each imported tenant still needs its own CloudCapsule consent granted before CloudCapsule can assess or act on it.
Managing both without confusion
- Tenant list vs. tenant access: keep your GDAP or DAP relationships current if you rely on partner tenant import to populate your tenant list. That import reads from the relationship, not from CloudCapsule's own consent.
- Don't assume connection: an active GDAP relationship with a client is not proof that tenant is connected to CloudCapsule. Check the tenant's own connection status directly.
- Offboarding is a separate step: restructuring or removing a GDAP relationship does not remove CloudCapsule's access on its own. To fully offboard a tenant, revoke the CloudCapsule consent directly, apart from whatever you do with the GDAP relationship.
- Consent needs its own admin: granting or changing CloudCapsule consent still requires a Global Administrator or Privileged Role Administrator on the client tenant, regardless of the administrative role your GDAP assignment gives you.
- Upgrading consent is its own action: moving from Read Only to Read & Write to turn on Manage is a new consent grant on the CloudCapsule side, not a GDAP change.