Since there were no in-depth tutorials available on the Celigo Community, I decided to share a complete and practical guide. OAuth setup for Microsoft 365 Business Central can be tricky, so I’ve documented the full process to help you connect M365 to Celigo more easily:
Store the Client Secret securely. You cannot retrieve it again later. Creating a Business Central connection via OAuth still uses the Azure App Registration, which may grant higher privileges than intended if the app has broad permissions — bypassing user-level scope limitations.
Create Connection in Celigo
Go to Connections
Create Connection
Select Microsoft Dynamics 365 Business Central application and select for example API:
@nuriensing You've been such a great part of the Celigo Connective community from its inception and this post is another great example of your awesome partnership. Thank you for taking the time to share your knowledge in such a detailed and thoughtful way!
Separately, I've sent this to @stephenbrandt and his docs team to improve our docs around this! As you can imagine, doing this for all 800 connections is a challenge so we appreciate the help!
When creating a connection via Celigo > Microsoft 365 Business Central using OAuth 2.0, the process still opens a Microsoft consent screen — a pop-up that asks the user to grant permissions to the app.
Even if the OAuth app in Azure is configured with limited scopes (e.g., Financials.ReadWrite), the connection still results in full read/write access within Business Central. This behavior suggests that the actual access granted may exceed the scope requested, which is concerning.
Nuri,
I am not 100% sure, as I have not tested this myself, but this could have to do with the permissions type that you set on the app.
Microsoft has the ability for you to define Delegated or Application.
Depending on how the app was configured, if you are using delegated and then logging in with an Admin user it could be inheriting permissions from the user.
As per the comparison below delegate permission is "Limited to what the user could do (plus any extra scopes granted). Can be further constrained by Conditional Access or RBAC targeted at the user."
I would suggest trying to setup a specific user in Azure, such as app_login@mycompany.com, with only the specific access you want to grant and use that to login in Integrator.IO when setting up the connection.
===============================================================================
In Azure AD (and therefore Microsoft Entra ID and Microsoft Graph), “Delegated” and “Application” designate the two fundamental permission types an app can ask for. They differ in whose identity is used, how tokens are issued, what appears inside the token, and who can grant consent.
Aspect
Delegated permissions (“scope”)
Application permissions (“app-only / app role”)
Identity in the access token
The signed-in user + the app (the app is acting on behalf of that user).
The app itself (service principal) only; no user context.
Typical OAuth 2.0 flow
Authorization-code / hybrid / device-code, etc.—interactive, because a user must sign in.
Client-credentials (daemon/daemonless), certificate or secret—non-interactive.
Claim that carries privileges
scp claim lists the scopes (e.g., user.read, mail.send).
roles claim lists the app roles (e.g., User.Read.All).
Consent required
User can self-consent to low-impact scopes; higher-impact scopes need tenant-admin consent.
Always needs admin consent because it allows the app to act without a user present.
Granularity of access
Limited to what the user could do (plus any extra scopes granted). Can be further constrained by Conditional Access or RBAC targeted at the user.
Often broader: the app can reach every object the permission covers across the tenant. You must constrain it with its own RBAC assignments or resource-specific permissions.
Typical scenarios
Single-page or mobile apps, web apps where users read/write their own mail, calendars, files, etc.
Daemons and background jobs, sync engines, export tools, unattended automation, APIs that must run 24×7.
Key points explained
User context vs. app context
With delegated permissions the access token represents both the user and the application, so every call happens “through” the user. If that user loses access (e.g., disabled account), the call fails because the user can no longer sign in. (Microsoft Learn)
With application permissions the token represents only the application. The user factor is irrelevant; the app still works even when no one is logged in. (Microsoft Learn)
Consent and security posture
Delegated scopes can be granted by individual users for low-impact data (for example, an Outlook add-in requesting Mail.Read). More sensitive scopes, or scopes in tenants where user consent is disabled, require an administrator. (Microsoft Learn)
Application permissions bypass user-level checks, so Azure always requires an administrator to approve them. Apply the least-privilege principle: request only the narrowest app role your service really needs. (Microsoft Learn, Microsoft Learn)
Token differences
Delegated token → scp claim lists granted scopes.
Application token → roles claim lists granted app roles. These claims tell Microsoft Graph (or any API that trusts Entra ID) which operations are allowed. (Microsoft Learn)
Example
Suppose you have a nightly export service that copies every user’s OneDrive content to an archive bucket:
You’d register an app with Files.Read.Allapplication permission and run it with the client-credentials flow—no user ever signs in.
Conversely, if you’re building a Teams add-in that shows the signed-in person’s recent files, you’d request Files.Readdelegated scope. Each user consents the first time the add-in runs, and the token only lets the add-in see that user’s files.
Choosing the right type
Need a signed-in user? → Delegated.
Run headless / server-to-server? → Application.
Want to limit access to exactly what the user can already do? → Delegated.
Need tenant-wide or cross-user access? → Application, plus extra guardrails (e.g., restrict the service principal via Azure RBAC or resource-specific consents in SharePoint/Teams).
Understanding the distinction is crucial for designing secure solutions and passing Azure’s consent review.
Provided by Teknuro.com
Background
Step-by-Step: Set up OAuth in Azure
Example Output (For Reference Only)
Store the Client Secret securely. You cannot retrieve it again later.
Notes