> ## Documentation Index
> Fetch the complete documentation index at: https://university.triggr-app.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](/core/get-started/connect-microsoft-365) and [Add your clients](/core/get-started/add-your-clients).

## Before you start

<AccordionGroup>
  <Accordion title="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>

  <Accordion title="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>

  <Accordion title="What do I need before setting up GDAP?">
    Partner Center access as an Admin agent, an [active GDAP relationship](/integrations/microsoft-graph/gdap-service-account#request-a-gdap-relationship-with-each-client) with each client that includes the [recommended roles](/integrations/microsoft-graph/recommended-roles#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](/integrations/microsoft-graph/conditional-access) or per-user MFA).
  </Accordion>

  <Accordion title="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>

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

## GDAP relationships and roles

<AccordionGroup>
  <Accordion title="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>

  <Accordion title="Which roles should the GDAP relationship include?">
    The [recommended set](/integrations/microsoft-graph/recommended-roles#recommended-set), or the [narrower alternatives](/integrations/microsoft-graph/recommended-roles#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>

  <Accordion title="Can I add a missing role to an existing relationship?">
    No. [Request a new relationship](/integrations/microsoft-graph/gdap-service-account#request-a-gdap-relationship-with-each-client) that includes it and, once approved, assign the role to Triggr's security group.
  </Accordion>

  <Accordion title="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](/integrations/microsoft-graph/gdap-service-account#give-the-account-access-to-your-clients).
  </Accordion>

  <Accordion title="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](/core/manage/gdap-alerts) can email your team.
  </Accordion>

  <Accordion title="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>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

## The service account

<AccordionGroup>
  <Accordion title="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](/integrations/microsoft-graph/gdap-service-account#create-the-service-account).
  </Accordion>

  <Accordion title="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>

  <Accordion title="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>

  <Accordion title="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>

  <Accordion title="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](/integrations/microsoft-graph/conditional-access).
  </Accordion>

  <Accordion title="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>

  <Accordion title="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>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

## Consent and permissions

<AccordionGroup>
  <Accordion title="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>

  <Accordion title="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>

  <Accordion title="App not consented">
    Triggr's app has no consent in the client's tenant yet. In the client's GDAP health, click Grant app consent, then Grant consent, or click **Repair**; both need Cloud Application Administrator in the relationship. 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".
  </Accordion>

  <Accordion title="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>

  <Accordion title="“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.
  </Accordion>
</AccordionGroup>

## Linking clients

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="“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>

  <Accordion title="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>

  <Accordion title="Does a client have to buy its licences through us?">
    No; Core only needs the GDAP relationship, which Partner Center lets you [request](/integrations/microsoft-graph/gdap-service-account#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>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

## Health checks and repairs

<AccordionGroup>
  <Accordion title="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>

  <Accordion title="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. | Add the named role in Partner Center. |
    | 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>

  <Accordion title="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>

  <Accordion title="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>

  <Accordion title="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>

  <Accordion title="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](/integrations/microsoft-graph/conditional-access#your-clients-tenants), then click **Check now**.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

## Per-client app instead of GDAP

<AccordionGroup>
  <Accordion title="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>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

## Exchange Online

<AccordionGroup>
  <Accordion title="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](/integrations/microsoft-exchange).
  </Accordion>

  <Accordion title="“Exchange isn't set up” or “Microsoft Exchange integration is not configured for tenant …”">
    The client has no Exchange connection in Triggr yet. 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>

  <Accordion title="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. Add it for Triggr's security group and run Repair again, or [grant Exchange access yourself](/integrations/microsoft-exchange#grant-exchange-access-yourself).
  </Accordion>
</AccordionGroup>

## Access, data and security

<AccordionGroup>
  <Accordion title="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>

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

  <Accordion title="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>

  <Accordion title="Who on my team can change Microsoft access?">
    Only admins can run Set up Microsoft access, Repair and Sign in with Triggr's service account, and change [GDAP alerts](/core/manage/gdap-alerts). Members can view GDAP health and click Check now and Check all. See [roles](/core/get-started/invite-your-team#invite-teammates).
  </Accordion>
</AccordionGroup>

## Errors you might see

<AccordionGroup>
  <Accordion title="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: open it 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>

  <Accordion title="“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>

  <Accordion title="“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>

  <Accordion title="“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.
  </Accordion>
</AccordionGroup>


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