Business Central and SharePoint: Why Your Integration May Have Broken
If your organization pulls documents, syncs attachments, or exposes files between Business Central and SharePoint through a custom AL integration or a Power Automate flow, that connection may already be broken, and it may have failed quietly enough that no one has traced the problem back to its source yet.
On April 2, 2026, Microsoft retired Azure ACS (Access Control Service) app-only authentication for SharePoint Online. Any integration still relying on that older authentication path stopped functioning that day, regardless of whether the client secret behind it was still valid. There was no phase-out window, and none has appeared since.
We recently guided a client through this exact situation after their BC-to-SharePoint integration hit this wall. If document uploads, attachment syncs, or file lookups between the two systems have started throwing vague authentication errors, this retirement is the likely cause. Here’s what changed and what it takes to fix it.
What the Old Authentication Method Looked Like
Integrations set up more than a couple of years ago were typically registered through SharePoint’s own appregnew.aspx and appinv.aspx pages, using an AllowAppOnlyPolicy request. That process granted app-only access through Azure ACS, an older authentication layer that existed before modern Entra ID app registrations became standard.
It ran reliably for years. It’s also precisely what Microsoft just shut off.
Moving to Entra ID App Registration
The fix is authenticating through Microsoft Entra ID instead, using an app registration with application-level permissions against Microsoft Graph and the SharePoint API rather than ACS. In practice, this involves:
- Registering a new app in Entra ID, or confirming an existing one
- Granting Application permissions, such as Sites.Read.All or Sites.ReadWrite.All, on Graph and SharePoint
- Securing tenant-level admin consent
- Authenticating using a certificate instead of a client secret
That last requirement is more consequential than it sounds.
Why the Fix Requires a Certificate, Not a Secret
A client secret will produce a valid Entra token, but SharePoint’s REST API inspects a particular claim on that token, appidacr, to determine whether it can be trusted. Tokens generated from a client secret carry a different claim value than tokens generated through certificate-based authentication, and SharePoint Online’s app-only model specifically requires the certificate version. Attempt a SharePoint REST call with a secret-based token and the response is an unhelpful “Unsupported app only token” error.
The solution is a self-signed certificate, which, despite how it sounds, is Microsoft’s recommended approach here rather than a workaround. No public trust chain is involved; Entra simply verifies a signature against the public key that gets uploaded. The real consideration is how the private key is managed afterward: it belongs in a protected store, ideally Azure Key Vault, never in source control or a shared drive, with an expiration date that’s actively tracked.
The Detail Most Guides Skip: BC Can’t Sign Its Own Tokens
This is where the migration often stalls. Certificate-based client credential flows require signing a JWT client assertion with the private key, and Business Central Online (the SaaS version) doesn’t have access to the cryptographic libraries needed to perform that signing within AL code. That’s a platform constraint, not a configuration oversight.
The practical solution is to move the signing step outside of Business Central:
Business Central’s AL code calls an Azure Function, which handles the signing and requests the token, and that token is then used against SharePoint REST or Graph. The function retrieves the certificate from Key Vault at runtime, builds and signs the client assertion, exchanges it for a bearer token at Entra’s token endpoint, and returns that token. From BC’s perspective, it’s just calling an HTTP endpoint, receiving a token back, and using it like any other bearer token for the SharePoint call.
If Power Automate is involved instead of, or alongside, AL code, the same approach applies: the flow calls the function for a token, then uses that token in an HTTP action against SharePoint.
A Practical Migration Checklist
Organizations working through this migration generally follow this sequence:
- Identify every integration still authenticating through the old ACS model. If it hasn’t been migrated, treat it as already non-functional rather than at risk.
- Register the app in Entra ID, or confirm the existing registration, with the appropriate Application permissions on Graph and SharePoint.
- Scope permissions carefully. Sites.Read.All and Sites.ReadWrite.All grant access across every site collection in the tenant. For most single-integration use cases, Sites.Selected, limited to the specific site or sites the integration actually needs, is the more audit-friendly option.
- Generate a certificate, upload the public key to the app registration, and store the private key in Key Vault.
- Build the token-signing layer. An Azure Function is generally the best fit for BC SaaS scenarios; test the token exchange independently with a tool like Postman before wiring it into a live process.
- Update the integration, whether AL code or Power Automate, to call the function for a token and use that token for the actual document read and write operations.
- Retest the full flow before returning it to production. A broken integration already costs time, and a rushed fix that fails in the same way costs more.
The Bigger Picture
Microsoft hasn’t discontinued SharePoint-to-Business Central document integration. What’s gone is one specific, older authentication method underneath it. The fix is a one-time effort: adopt Entra ID app registration, switch to certificate-based authentication, and add a lightweight signing layer to handle what BC can’t do on its own. Once that’s in place, the integration ends up more secure than it was under the old model.
Next Steps
If your organization has a Business Central integration that touches SharePoint, whether built through custom AL development, Power Automate, or a legacy ISV connector, it’s worth confirming now whether it still depends on the retired ACS model, particularly if anyone has flagged document uploads or attachment syncs quietly failing. Logan Consulting can help diagnose the cause and manage the migration to a secure, working setup. For more information, contact Logan Consulting at info@loganconsulting.com or call (312) 345-8800.
