Setup guide · from scratch
Register the multi-tenant Entra app for the Graph/Connect API
Creates the app identity Decolla/Connect uses to drive Intune via Graph across customer tenants. Choose multi-tenant, add the Graph Intune permissions, and remember each customer admin must consent separately.
≈ 15 min
Start here — Microsoft foundation · step 2 of 3 · ≈ 15 min‹ PreviousNext ›
Do these first — this guide assumes you already have:
The Decolla way — skip the clicks.
Every step below can be done by hand. Or connect your Microsoft tenant to Decolla once, and Decolla performs this for you over Microsoft Graph in your own tenant — then hands back a verified result you can see and roll back per item. It also puts the fundamentals this step depends on in place — the target group, the licence allocation — so a build is never blocked half-way by a missing dependency.
⏱ By hand: about 15 min of clicking, every build. The Decolla way: part of one tenant connect, then automatic.
Before you start
- Two accounts, often two different people: an Application Developer to register the app, and a Cloud/Global Admin to grant consent.
- A decision made in advance on the auth flow — confidential 'Web' with a secret, or 'Public client/native' device-code — because it sets the Redirect URI.
- A secure vault (password manager or Key Vault) open and ready to catch the client-secret value, which is shown only once.
- The three Graph delegated scopes to hand: DeviceManagementApps.ReadWrite.All, DeviceManagementServiceConfig.ReadWrite.All, DeviceManagementConfiguration.ReadWrite.All.
The steps
- Go to entra.microsoft.com and sign in (Application Developer to create;…
- Browse to Entra ID > App registrations > New registration.
- Enter a Name (e.g. 'Decolla Connect') and under 'Supported account types' choose…
- Set the Redirect URI: 'Web' for a server/confidential app (HTTPS callback) or…
- On Overview copy the Application (client) ID and Directory (tenant) ID.
- Manage > API permissions > Add a permission > Microsoft Graph; add the Intune…
- Click 'Grant admin consent for <tenant>' and confirm Yes.
- Manage > Certificates & secrets > New client secret; set description + expiry, Add,…
- (Optional) Under Authentication enable 'Allow public client flows' if using device-…
- For each customer tenant an admin must consent via…
0 of 10 done
Step 1. Go to entra.microsoft.com and sign in (Application Developer to create; Cloud/Global Admin to consent).
Screenshot: Entra admin center home (captured during a live customer build — coming to this page)
Why: The two roles are split on purpose: whoever registers the app usually cannot grant tenant-wide consent, so line both people up before you start.
Watch for: Application Developer lets you create the app but not consent it — with only that role you will stall at the 'Grant admin consent' step.
Don’t: Do NOT assume a single account covers both jobs.
If this step errors: Zero-touch Intune enrolment fails after Microsoft sign-in
Step 2. Browse to Entra ID > App registrations > New registration.
Screenshot: New registration pane (captured during a live customer build — coming to this page)
Why: This registration is the identity Connect authenticates as — every later step just configures this one object.
Don’t: Do NOT reuse an unrelated existing registration to save time — its permissions, secrets and expiry dates are not yours to manage.
If this step errors: Duplicate apps in Intune after VPP token renewal
Step 3. Enter a Name (e.g. 'Decolla Connect') and under 'Supported account types' choose 'Multiple Entra ID tenants'.
Screenshot: New registration with 'Multiple Entra ID tenants' selected (captured during a live customer build — coming to this page)
Why: Multi-tenant is the whole point: it lets one app work in every customer tenant. A single-tenant app can never be consented to by another organisation.
Watch for: Decolla drives Intune across customer tenants, so choose 'Multiple Entra ID tenants' (multi-tenant) here rather than single-tenant.
Don’t: Do NOT leave it on the default single-tenant setting — that quietly locks the app to your own tenant only.
If this step errors: Renew or recreate the Apple MDM push certificate in Intune?
Step 4. Set the Redirect URI: 'Web' for a server/confidential app (HTTPS callback) or 'Public client/native' for device-code; click Register.
Screenshot: Redirect URI + platform selection (captured during a live customer build — coming to this page)
Why: The platform type decides Connect's auth flow — 'Web' for a confidential app holding a secret, 'Public client/native' for device-code.
Watch for: A 'Web' redirect URI must be HTTPS — an http:// or mistyped callback fails later at sign-in, not here, so it is easy to miss now.
Don’t: Do NOT pick a platform before you have decided the flow — it dictates what you switch on in step 9.
Step 5. On Overview copy the Application (client) ID and Directory (tenant) ID.
Screenshot: Overview page showing client and tenant IDs (captured during a live customer build — coming to this page)
Why: These two IDs identify the app everywhere else — the Application (client) ID goes straight into the per-customer consent URL in step 10.
Watch for: Copy the Application (client) ID, not the Object ID beside it — they look alike and the wrong one silently breaks sign-in.
Step 6. Manage > API permissions > Add a permission > Microsoft Graph; add the Intune scopes (DeviceManagementApps.ReadWrite.All, DeviceManagementServiceConfig.ReadWrite.All, DeviceManagementConfiguration.ReadWrite.All). Choose DELEGATED permissions (not Application) - Decolla acts as the signed-in admin, per the Connect design.
Screenshot: API permissions with the Graph Intune scopes added (captured during a live customer build — coming to this page)
Why: These three Graph scopes are exactly what Connect needs to drive Intune apps, service configuration and device configuration as the admin.
Watch for: Delegated and Application sit on two near-identical tiles — pick Delegated, or Connect authenticates as itself instead of as the signed-in admin.
Don’t: Do NOT add the Application-type versions of these scopes — it contradicts the Connect design and over-privileges the app.
Step 7. Click 'Grant admin consent for <tenant>' and confirm Yes.
Screenshot: API permissions showing 'Granted' status (captured during a live customer build — coming to this page)
Why: Consent flips the permissions from requested to active in your own tenant; until you click it, the scopes sit dormant.
Watch for: This consents your tenant only — every customer tenant still needs its own consent in step 10.
Don’t: Do NOT expect this button to be clickable with just Application Developer — it needs a Cloud/Global Admin.
Step 8. Manage > Certificates & secrets > New client secret; set description + expiry, Add, and copy the secret VALUE immediately (shown once). Prefer a certificate for production.
Screenshot: New client secret with the value field visible (captured during a live customer build — coming to this page)
Why: The secret is how a confidential Connect app proves its identity to Graph with no user present.
Watch for: The Value is masked the instant you leave the blade — copy it now; the Secret ID shown afterwards is NOT the credential.
Don’t: Do NOT set a never-expiring or over-long secret for convenience — prefer a certificate for production.
On a schedule: The expiry you set is a hard deadline: diarise renewal a couple of weeks ahead, because when the secret lapses Connect stops authenticating with no warning.
Step 9. (Optional) Under Authentication enable 'Allow public client flows' if using device-code.
Screenshot: Authentication blade public client flows toggle (captured during a live customer build — coming to this page)
Why: Device-code sign-in only works with public client flows enabled — it is off by default.
Watch for: Only relevant if you chose 'Public client/native' in step 4.
Don’t: Do NOT enable this for a secret-based Web app that never uses device-code — it needlessly loosens the app.
Step 10. For each customer tenant an admin must consent via https://login.microsoftonline.com/{tenant}/adminconsent?client_id=... — you cannot consent silently on their behalf.
Screenshot: The admin-consent prompt a customer admin sees (captured during a live customer build — coming to this page)
Why: A multi-tenant app appears in a customer tenant only after their admin consents — this URL is how you trigger that prompt per customer.
Watch for: Swap {tenant} for the customer's tenant ID and client_id for the value from step 5 — a wrong ID sends the admin to the wrong consent screen.
Don’t: Do NOT tell customers you can switch it on without them — consent is theirs to give and cannot be done silently on their behalf.
On a schedule: Bake this consent link into customer onboarding so every new tenant is consented before go-live.
Put these on a schedule
| Step | Recurring action to diarise |
|---|---|
| Step 8 | The expiry you set is a hard deadline: diarise renewal a couple of weeks ahead, because when the secret lapses Connect stops authenticating with no warning. |
| Step 10 | Bake this consent link into customer onboarding so every new tenant is consented before go-live. |
If it goes wrong
The failures people actually hit on this process, each with the diagnosis and fix:
- Renew or recreate the Apple MDM push certificate in Intune? — Renew — never recreate — your Intune APNs certificate. Why device trust follows the push topic, what the Apple ID actually controls, and the safe path.
- Zero-touch Intune enrolment fails after Microsoft sign-in — Android zero-touch enrolment fails after Microsoft sign-in with 'Page not found'? Zero-touch did its job — the fault is Intune-side. How to fix it.
- Duplicate apps in Intune after VPP token renewal — Renewing an Apple VPP token as a new entry duplicates every app in Intune. How to renew in place, recover from duplicates, and catch early expiry.
‹ Get Microsoft 365 and a Microsoft Intune licence (from having nothing)Connect Decolla to your Microsoft Intune tenant (admin consent) ›
See it on a real device.
Decolla is in private build — early-access members see a build defined, deployed and rolled back first.
Get early access