Integrating Dynamics 365 with custom mobile apps

Most mobile needs on Dynamics 365 are met by apps Microsoft already ships: the Power Apps mobile app for model-driven and canvas apps, the Field Service mobile app, the Sales mobile app, the Business Central mobile app, and the Warehouse Management app for F&O. Our Dynamics 365 mobile strategy guide covers when each fits. This guide is about the remaining cases, where an organisation decides to build its own app, and about what integrating that app with Dynamics 365 actually involves.

When a custom app is justified

• Customers or the public are the users. Microsoft's mobile apps are for licensed internal users. A customer-facing app for booking, tracking, or self-service needs its own identity model and cannot put a Dynamics 365 licence in every customer's hand.
• The experience is the product. A consumer-grade UX, hardware integration (scanners, sensors, payment terminals), or platform features the Power Apps container does not expose.
• The Dynamics 365 part is small. The app does many things and Dynamics 365 is one data source among several. Wrapping all of it in a canvas app would be backwards.
• Offline needs exceed what the platform offers. Field Service mobile and canvas offline are capable but opinionated; some workloads need full control of the local store and sync logic.

If none of those apply, build in Power Apps. A custom app costs an order of magnitude more to maintain, and the platform apps get better every release without your involvement.

The integration surface

For Dataverse-based apps (Sales, Customer Service, Field Service, custom tables), the app talks to the Dataverse Web API, an OData v4 REST endpoint. For Business Central, it is the API v2.0 pages or custom API pages, also OData. For Finance and Operations, data entities over OData or custom services. All three are HTTPS and JSON, and all three have request throttling that a chatty mobile app will hit. See batch operations in the Dataverse Web API for how to reduce round trips.

The first architectural decision is whether the app calls Dynamics 365 directly or goes through a backend of your own. For internal users with Entra ID accounts and a licence, direct calls with delegated authentication are acceptable. For customers, for any app you cannot fully trust, and for any app that needs to combine data from several systems, put an API in front: an Azure Function app or a small web API, fronted by API Management, that holds the service identity and applies its own authorisation. See APIM in front of Dataverse and API gateway patterns. This is also where the licensing question gets resolved: an external user reaching Dataverse through a multiplexing backend still needs an appropriate licence position, and the backend should be designed with that reviewed rather than discovered at audit.

Authentication

Internal users: MSAL on the device, an app registration with delegated Dataverse permissions, and the user's own Entra ID sign-in. The user's Dataverse security roles apply, which is what you want. Conditional access and Intune app protection policies apply too, if the app is registered for them.

External users: Entra External ID or Azure AD B2C on the device for the customer's identity, exchanged at your backend for a call to Dataverse under a service principal, with your backend enforcing that the customer only sees their own rows. See B2C authentication with Dynamics 365. Never ship a client secret in a mobile app; assume anything in the binary is public.

Offline and sync

This is where custom apps earn their cost and where they fail. A local store (SQLite is the usual choice), a sync engine that pulls changes since a watermark and pushes local edits, and conflict handling for the cases where the server changed too. Dataverse supports this pattern through change tracking, which returns only what changed since a token; use it rather than polling full tables. Business Central has no change tracking on standard APIs, so a modified-date filter on custom API pages is the practical equivalent.

Design the conflict rules per table before writing the sync. "Server wins" is fine for reference data; "last edit wins with an audit record" is usually right for field-entered data; some tables need the user to choose. See canvas app offline mode for how the platform handles it, which is a reasonable model to copy.

Framework choice

.NET MAUI is the natural fit for teams already in the Microsoft ecosystem, with MSAL and the Dataverse SDK available. React Native and Flutter are equally viable; the Dynamics 365 side is plain REST and does not care. Pick what the team can maintain for five years, because that is how long the app will live.

Cost of ownership

An app store presence, OS version churn, device testing, certificate renewals, and the Dynamics 365 API evolving underneath. Budget a permanent fraction of a developer, not a one-off project. Organisations that do not have that budget should not build a custom app.

What breaks in practice

Token expiry handled badly, so users are logged out mid-task. Sync that works on Wi-Fi and fails on a real mobile network. API throttling during a morning login storm. A Dataverse column renamed by an administrator who did not know an app depended on it. App store review delays on the day a critical fix is needed.

Stability verdict

The APIs are stable and well documented, and the authentication libraries are mature. The instability is entirely in the app you build and the sync you own. A custom app justified by one of the reasons above, with a backend in front of Dynamics 365 and a maintenance budget, is a sound pattern. One built because someone did not like the look of the Power Apps mobile app will be regretted.