> ## Documentation Index
> Fetch the complete documentation index at: https://kb.mspprocess.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Microsoft and GDAP FAQ

> Answers to common questions about connecting Triggr Core to your clients' Microsoft 365 tenants: GDAP, the service account, consent, GDAP health, Exchange and the errors you might see.

For the setup steps, see [Connect Microsoft 365](https://kb.mspprocess.com/core/get-started/connect-microsoft-365.md) and [Add your clients](https://kb.mspprocess.com/core/get-started/add-your-clients.md). For a client that shows a warning, see [Fix Microsoft connection problems](https://kb.mspprocess.com/core/reference/fix-microsoft-connection-problems.md).

<video controls preload="none" playsInline poster="/images/videos/microsoft-faq.jpg" src="https://mintcdn.com/triggr/qlzU2ZPfGS3YFsZy/images/videos/microsoft-faq.mp4?fit=max&auto=format&n=qlzU2ZPfGS3YFsZy&q=85&s=ae082e1c7479bf727fbf14853c29944e" />

Microsoft questions: GDAP or a per-client app, missing roles, Repair, when Core checks and renewing Triggr's sign-in (1:27).

## Before you start

> [accordion] Should I choose GDAP or a per-client app?
>
> GDAP (Partner Center) if you're a CSP partner with GDAP relationships: one sign-in reaches every client. Otherwise Per-client app: each client's Global Administrator approves Triggr once.

> [accordion] Can some clients use GDAP and others a per-client app?
>
> No. One Default Microsoft connection (Settings > General) applies to every client, and changing it moves every Microsoft workflow at once, so connect your clients the new way first.

> [accordion] What do I need before setting up GDAP?
>
> Partner Center access as an Admin agent, an [active GDAP relationship](https://kb.mspprocess.com/integrations/microsoft-graph/gdap-service-account.md#request-a-gdap-relationship-with-each-client) with each client that includes the [recommended roles](https://kb.mspprocess.com/integrations/microsoft-graph/recommended-roles.md#recommended-set), an admin in your own tenant who can create users and assign Entra roles, and a way to require MFA on the service account ([Conditional Access](https://kb.mspprocess.com/integrations/microsoft-graph/conditional-access.md) or per-user MFA).

> [accordion] We use CIPP today. Can Core keep using it?
>
> Core connects through GDAP or a per-client app. If Choose how to connect says "Connected via CIPP today", confirming a card moves your Microsoft workflows off CIPP straight away, so connect each client the new way first.

> [accordion] Some clients sync users from on-premises Active Directory. What changes?
>
> Set their environment to **Cloud + On-Prem (synced)** and [deploy the desktop agent](https://kb.mspprocess.com/core/get-started/add-your-clients.md#deploy-the-desktop-agent). Core then makes user changes in Active Directory ([which workflows](https://kb.mspprocess.com/core/reference/workflow-catalogue.md#clients-with-on-premises-ad)), and GDAP health stops asking for the Entra roles those changes would otherwise need.

## GDAP relationships and roles

> [accordion] What is GDAP, and can Core use DAP instead?
>
> GDAP is Microsoft's time-limited, role-based partner access to a customer's tenant, replacing DAP ([Microsoft's GDAP FAQ](https://learn.microsoft.com/en-us/partner-center/customers/gdap-faq)). Core acts only within the roles a client's relationship gives Triggr's security group, and GDAP health looks for that relationship, so move DAP clients to GDAP.

> [accordion] Which roles should the GDAP relationship include?
>
> The [recommended set](https://kb.mspprocess.com/integrations/microsoft-graph/recommended-roles.md#recommended-set), or the [narrower alternatives](https://kb.mspprocess.com/integrations/microsoft-graph/recommended-roles.md#narrower-alternatives). Global Administrator isn't needed, and Microsoft won't auto-extend a relationship that includes it. GDAP health names any role a client lacks, for example "Needs User Administrator for Onboarding".

> [accordion] Can I add a missing role to an existing relationship?
>
> No: Microsoft doesn't let you add roles to a relationship after it's created ([Microsoft's guide](https://learn.microsoft.com/en-us/partner-center/customers/gdap-obtain-admin-permissions-to-manage-customer#request-a-granular-admin-relationship-with-a-customer)). If the relationship already includes the role, assign it to Triggr's security group. Otherwise [request a new relationship](https://kb.mspprocess.com/integrations/microsoft-graph/gdap-service-account.md#request-a-gdap-relationship-with-each-client) that includes it and, once approved, assign the role to Triggr's security group.

> [accordion] Can I assign GDAP roles straight to the service account?
>
> No. Partner Center assigns roles to security groups, so put the service account in a group and give that group its roles in each relationship. See [Give the account access to your clients](https://kb.mspprocess.com/integrations/microsoft-graph/gdap-service-account.md#give-the-account-access-to-your-clients).

> [accordion] How long does a relationship last, and when does Core warn me?
>
> Up to two years; with Auto Extend on, Microsoft [extends it](https://learn.microsoft.com/en-us/partner-center/customers/expiring-gdap-relationships-and-auto-extend-gdap) six months at a time. In the last 30 days of one that doesn't auto-extend, the client shows Expires in *N* days, the Expiring filter on Clients lists it, and [GDAP alerts](https://kb.mspprocess.com/core/manage/gdap-alerts.md) can email your team.

> [accordion] A relationship has expired. Can I renew it?
>
> No. Request a new one, assign Triggr's security group its roles again, then click **Check now** in the client's GDAP health.

> [accordion] Expiring says “Triggr can't read GDAP end dates yet”
>
> An admin clicks **Sign in with Triggr's service account** and signs in as the account Core already uses. Signing in as anyone else changes the access Triggr uses for every client.

## The service account

> [accordion] What does the service account need?
>
> Membership of AdminAgents and your GDAP security groups, Global Administrator until setup is finished, MFA, and a Conditional Access exclusion with its own MFA policy. See [Create the service account](https://kb.mspprocess.com/integrations/microsoft-graph/gdap-service-account.md#create-the-service-account).

> [accordion] Why does it need Global Administrator, and when can I remove it?
>
> Only to approve Triggr's app in your tenant: Microsoft requires the approver to be a Global Administrator and Admin Agent. Remove it on the Done step (Open Entra) once every sign-in is finished.

> [accordion] Does the service account need a licence or a mailbox?
>
> No. Mailbox steps run as Triggr's own app, never through the account's mailbox.

> [accordion] Does it need MFA?
>
> Yes. Partner Center rejects requests unless the sign-in used MFA. If you add MFA after setup, redo Connect Microsoft Graph and Connect Partner Center.

> [accordion] Which Conditional Access policies should leave it out?
>
> In your tenant, policies that require a compliant or hybrid-joined device or allow only named locations. In clients' tenants, exclude your partner tenant's service provider users. See [Conditional Access](https://kb.mspprocess.com/integrations/microsoft-graph/conditional-access.md).

> [accordion] Microsoft keeps signing me in as myself
>
> Choose **Use another account** in Microsoft's window. Every client uses this sign-in, so signing in as yourself changes the access Triggr uses for all of them.

> [accordion] What happens if the service account's password changes?
>
> Microsoft revokes Triggr's sign-in (as it does if someone revokes the account's sessions). Clients shows "Triggr's Microsoft sign-in needs renewing — every client is affected." and each client reads Check org sign-in. Click **Renew**, then Redo on Connect Microsoft Graph and Connect Partner Center, signing in as the service account with MFA.

> [accordion] Will the sign-in expire if nobody uses Core for a while?
>
> No. Triggr refreshes it in the background; you sign in again only if Microsoft revokes it.

## Consent and permissions

> [accordion] What do the sign-ins on the Sign in step do?
>
> Approve Triggr's app gives admin consent in your own tenant. Connect Microsoft Graph is the service account sign-in Core uses in clients' tenants, and Connect Partner Center lets Core list your customers and grant its consent in their tenants.

> [accordion] What permissions does Triggr's app get in a client's tenant?
>
> Delegated Microsoft Graph permissions granted through Partner Center, plus Exchange.ManageAsApp for Exchange Online. With GDAP, Triggr can use them only within the roles the client's relationship gives Triggr's security group.
>
> The Graph permissions are `Application.ReadWrite.All`, `AppRoleAssignment.ReadWrite.All`, `AuditLog.Read.All`, `DeviceManagementConfiguration.Read.All`, `DeviceManagementConfiguration.ReadWrite.All`, `DeviceManagementManagedDevices.Read.All`, `DeviceManagementManagedDevices.ReadWrite.All`, `DeviceManagementServiceConfig.Read.All`, `Directory.AccessAsUser.All`, `Directory.Read.All`, `Directory.ReadWrite.All`, `Files.ReadWrite.All`, `Group.ReadWrite.All`, `GroupMember.ReadWrite.All`, `IdentityRiskEvent.Read.All`, `IdentityRiskyUser.Read.All`, `Member.Read.Hidden`, `offline_access`, `Organization.Read.All`, `Policy.Read.All`, `RoleManagement.Read.Directory`, `SecurityEvents.Read.All`, `Sites.Manage.All`, `Sites.ReadWrite.All`, `TeamsTelephoneNumber.ReadWrite.All`, `User.DeleteRestore.All`, `User.EnableDisableAccount.All`, `User.Export.All`, `User.Invite.All`, `User.ManageIdentities.All`, `User.Read`, `User.ReadWrite.All`, `User.RevokeSessions.All` and `UserAuthenticationMethod.ReadWrite.All`.

> [accordion] App not consented
>
> Triggr's app has no consent in the client's tenant yet. With GDAP, Triggr grants it by itself; to grant it now, click Grant app consent, then Grant consent, in the client's GDAP health, or click **Repair**. Microsoft takes a minute or two to apply it, so wait before Check now, or if Repair says "Microsoft is still applying Triggr's new consent". If Partner Center refuses, see [Consent refused](https://kb.mspprocess.com/core/reference/fix-microsoft-connection-problems.md#consent-refused).

> [accordion] Missing permissions
>
> Triggr's consent in that client is from an older permission set. Click **Repair**: it removes the consent and grants it again, so Triggr can't reach the client for a minute or so.

> [accordion] “Partner Center rejected Triggr's sign-in for this consent change”
>
> Check the client's GDAP relationship is active and the service account is still in AdminAgents, then redo Connect Partner Center on the Sign in step and try again.

## Linking clients

> [accordion] What's the difference between adding a client and linking it to GDAP?
>
> Adding puts the client on Clients with its tenant ID; linking lets Core reach that tenant through GDAP. The Microsoft setup's Add clients step does both; Import > Microsoft Partner Center only adds, so click **Link all** afterwards. Once a client is linked, Triggr connects it by itself.

> [accordion] “Couldn't link this client — add its Microsoft tenant ID first.”
>
> Open the client, fill in Microsoft tenant ID under Details (or click Look up from domain), then click **Link to GDAP** again.

> [accordion] A client isn't in our Partner Center list
>
> Click **Add client** on Clients and enter its domain, then open it and click Link to GDAP. It still needs an active GDAP relationship that gives Triggr's security group its roles.

> [accordion] Does a client have to buy its licences through us?
>
> No; Core only needs the GDAP relationship, which Partner Center lets you [request](https://kb.mspprocess.com/integrations/microsoft-graph/gdap-service-account.md#request-a-gdap-relationship-with-each-client) from a customer you don't resell to. Clients you can't reach through GDAP need Per-client app, which then applies to every client.

> [accordion] How long does setting up hundreds of clients take?
>
> Set up Microsoft access works on three clients at a time, 20 seconds to 2 minutes each. Keep the tab open; finish any later with Set up Microsoft access for all clients on the Add clients step.

## Health checks and repairs

> [accordion] What does Core check, and when?
>
> Every night at 03:30 UTC: each GDAP-linked client's Microsoft sign-in, Graph permissions, Admin roles and GDAP relationship, plus Recent failures from the last 7 days. Check sooner with Check now in the client's GDAP health (once a minute) or Check all on Clients (once every 10 minutes).

> [accordion] What do Setting up… and a warning on a client mean?
>
> Setting up… means Triggr is connecting the client or fixing it by itself. A warning that names a cause, such as Needs a GDAP role or Blocked by Conditional Access, needs you or the client's admin: see [Fix Microsoft connection problems](https://kb.mspprocess.com/core/reference/fix-microsoft-connection-problems.md).

> [accordion] What does each GDAP health status mean?
>
> | Status | Meaning | Fix |
> | - | - | - |
> | Healthy | Sign-in, consent, roles and relationship cover your workflows. | None needed. |
> | Expires in *N* days | The relationship ends within 30 days and doesn't auto-extend. | Turn on Auto Extend, or request a new relationship. |
> | Missing roles | Triggr's group lacks a role a workflow needs. | Assign the named role to Triggr's security group in Partner Center, or request a new relationship that includes it. |
> | Missing permissions | Triggr's consent is from an older permission set. | Repair |
> | App not consented | Triggr's app has no consent in the client. | Grant app consent or Repair |
> | Broken | Core can't sign in, or the relationship is missing, expired or inactive. Hover for the reason. | See the reason's entry below. |
> | Check org sign-in | Triggr's own Microsoft sign-in is failing, so the client wasn't checked. | Renew |
> | Not checked | Not checked yet, or the check couldn't run. Core tries again tonight. | Check now |

> [accordion] What does Repair change?
>
> It grants or replaces Triggr's consent in the client's tenant, adds the client's Exchange connection and gives Triggr's app Exchange access, then re-checks, skipping anything already in place. It never changes GDAP relationships or roles. Admins only, at most once every six minutes per client.

> [accordion] Why does GDAP health ask for a role we don't use?
>
> It counts the workflows not set to Disabled on Config, and only the steps turned on in them. Set an unused workflow to **Disabled**, or add the role named under Won't fully work here.

> [accordion] GDAP relationship missing
>
> Microsoft didn't let the service account into the client's tenant. Check the relationship is Active in Partner Center (not Approval Pending), Triggr's security group has an Active role assignment in it, the service account is in that group, and the client's Microsoft tenant ID is its own.

> [accordion] Blocked by Conditional Access
>
> A policy in the client's tenant blocked the service account. Exclude your partner tenant's service provider users, as in [Your clients' tenants](https://kb.mspprocess.com/integrations/microsoft-graph/conditional-access.md#your-clients-tenants), then click **Check now**.

> [accordion] Connection Audit shows crosses, but GDAP health says Healthy
>
> GDAP health checks what your enabled workflows need. Connection Audit and Check permissions also test reads such as Devices, Risky users and Security alerts that Core's workflows don't use.

## Per-client app instead of GDAP

> [accordion] How does the per-client app option work?
>
> A Global Administrator of your tenant approves Triggr's app on Approve the app. Then each client's Global Administrator approves it from Approve clients, or the Approve access button in the client's panel while it reads Needs approval.

> [accordion] Do GDAP health and alerts work with a per-client app?
>
> No. To test a client's access, click **Check permissions** under Microsoft connection in its panel, or use Connection Audit on Clients.

## Exchange Online

> [accordion] How does Core run mailbox tasks?
>
> As Triggr's own app through Exchange Online PowerShell, not as the service account. In each client's tenant the app needs Exchange.ManageAsApp and the Exchange Administrator role, which Repair sets up for GDAP clients. See [Microsoft Exchange](https://kb.mspprocess.com/integrations/microsoft-exchange.md).

> [accordion] “Exchange isn't set up” or “Microsoft Exchange integration is not configured for tenant …”
>
> The client has no Exchange connection in Triggr yet. With GDAP, Triggr adds it by itself; if it stays, click **Repair** in the client's GDAP health. With a per-client app, click Set up Microsoft access for all clients on the Approve clients step.

> [accordion] Repair says Triggr's GDAP roles “can't assign admin roles”
>
> Repair needs Privileged Role Administrator in the relationship to give Triggr's app the Exchange Administrator role; Clients shows [Needs Privileged Role Admin](https://kb.mspprocess.com/core/reference/fix-microsoft-connection-problems.md#needs-privileged-role-admin). Add it for Triggr's security group and run Repair again, or [grant Exchange access yourself](https://kb.mspprocess.com/integrations/microsoft-exchange.md#grant-exchange-access-yourself).

## Access, data and security

> [accordion] How do I stop Core working in a client's tenant?
>
> With GDAP, remove Triggr's security group from the relationship or [terminate it](https://learn.microsoft.com/en-us/partner-center/customers/gdap-partner-terminate) in Partner Center, and [delete Triggr's enterprise app](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/delete-application-portal) (application ID `e0ce32ae-7ba3-4f66-b686-d22dd0eb7841`) from the client's tenant, since mailbox steps run as that app. With a per-client app, the client's admin deletes Triggr's enterprise apps there.

> [accordion] Where do Microsoft actions run from?
>
> From Triggr's cloud; only on-premises Active Directory changes go through the [desktop agent](https://kb.mspprocess.com/desktop-agent/overview.md). If a Conditional Access policy allows only named locations, exclude the service account or add [Triggr's IP addresses](https://kb.mspprocess.com/security/ip-allowlist.md).

> [accordion] What does Triggr keep? Does it store the service account's password?
>
> Triggr never sees the password: you sign in on Microsoft's own page. It keeps the sign-in tokens, encrypted with keys unique to your organisation, plus each client's tenant ID and domain and its latest GDAP health results.

> [accordion] Who on my team can change Microsoft access?
>
> Only admins can run Set up Microsoft access, Repair, Fix now and Sign in with Triggr's service account, and change [GDAP alerts](https://kb.mspprocess.com/core/manage/gdap-alerts.md). Members can view GDAP health and click Check now and Check all. See [roles](https://kb.mspprocess.com/core/get-started/invite-your-team.md#invite-teammates).

## Errors you might see

> [accordion] A step fails with “no Microsoft Graph (GDAP) integration is configured for this client”
>
> It can also read "microsoftGDAP integration is not configured for tenant …". The client isn't linked. Check its Microsoft tenant ID on Clients, click **Link to GDAP**, then run the workflow again. With a per-client app the message names Microsoft Graph (SAM) or `microsoftSAM`; click Approve access instead.

> [accordion] “Triggr's Microsoft app credentials for your organisation need updating — every client is affected.”
>
> Microsoft rejected the app ID or client secret saved for Microsoft Graph (GDAP). If you use your own app registration, put a new client secret on its Base configuration in Integrations; otherwise contact Triggr support.

> [accordion] “Your organisation isn't connected to Microsoft Partner Center”
>
> On the Microsoft setup's Sign in step, click **Sign in** (or Redo) on Connect Partner Center, sign in as the service account, then try again.

> [accordion] “Reconnect Microsoft 365 in Settings first”
>
> Either Default Microsoft connection isn't GDAP, or Triggr's own Microsoft sign-in needs fixing. Check **Settings > General**, then redo the sign-ins on the Sign in step.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.