Dynamics 365 Mobile and Field Apps: Native, Canvas or Custom?

Which mobile route fits which constraint?

Start from the constraint that cannot move, not from the technology the team likes. Most organisations asking this question have one hard constraint: a process that already matches Field Service, a group of users who find the full app too heavy, a device or connectivity requirement the platform does not meet, or a licence count that finance will not sign. The table gives the rule for each route; the sections below explain where the edges are.

When is the standard Field Service mobile app simply the right answer?

More often than buyers expect. The Field Service mobile app is a model-driven app built on the Power Apps mobile platform, available as its own store app, using the same Dataverse tables, security roles and business logic as the office. Work orders, bookings, service tasks, customer assets, product consumption, signatures and service reports come with it, and offline is handled by a mobile offline profile that downloads what a technician needs for the next few days. If your technicians do that work, building a canvas or custom app duplicates a product you are already licensed for and creates a second thing to maintain.

The usual reason a native rollout disappoints is not the app itself: it is a form with too many fields, an offline profile nobody tested without signal, or an asset model that does not match the equipment. Those are fixable inside the product, and the Field Service implementation partner page describes how we test them in a feasibility sprint before anyone commits to a build.

• Choose it when the technician is the main user and the job is a work order from start to finish.
• Choose it when the office already runs Dynamics 365 Field Service, so scheduling, history and reporting stay in one model.
• Simplify the forms, tabs and required fields for mobile before concluding the app is unusable.
• Scope the offline profile to one route and a few days of work, and test it with the network switched off.

Can you extend the native app before replacing it?

Yes, and this is usually the cheapest way to close a gap. A model-driven app accepts custom controls, custom pages and embedded canvas components, so a single awkward step, such as a guided checklist, a measurement grid or a photo markup, can be improved without leaving the Field Service app. The technician stays in one app with one sign-in and one sync, and the rest of the work order lifecycle keeps using the standard product.

A custom PCF control is the right tool when the gap is one interaction that the standard controls handle badly. Our PCF control development service covers that work. Replace the app only when the list of gaps is long enough that the extensions would become the product.

When does a Power Apps canvas app on Dataverse make more sense?

When the people capturing data are not doing the full work order job. A quality inspector, a site supervisor, a driver confirming delivery or an operator logging downtime needs three screens, large buttons, scanning and validation at the point of entry, not the navigation of a full model-driven app. A canvas app gives you that flow over the same Dataverse tables, so the office still sees one set of records.

Canvas apps built on Dataverse can run offline through the platform offline capability, using an offline profile in the same way as model-driven apps, which is the preferred route for new offline canvas apps. The capture design itself, including staging tables and why offline decides whether a pilot survives, is set out in how Power Apps replaces paper forms on the shop floor. If the question is whether to build the capture app on Power Apps at all or buy a standalone inspection platform, that is a separate decision covered in the field inspection app cost comparison.

• Good fit: a short, repeatable capture flow used by many people with little training.
• Good fit: device camera, barcode scanning and location, which canvas apps support directly.
• Poor fit: rebuilding bookings, service tasks, parts and signatures that the Field Service app already provides.
• Watch: a canvas app that one maker built and only one maker understands becomes a key-person risk within a year.

When does a custom application justify the extra ownership?

A custom mobile application is justified by a constraint the platform cannot meet, not by preference. It is the route that gives you full control over local storage, background sync and retry behaviour, direct access to device hardware, and the freedom to run on your own backend without Microsoft per-user licensing. It is also the route where every one of those things becomes your responsibility.

• Offline durability: when work lasts days or weeks without signal and you need a local database, your own queue and your own conflict rules rather than the platform sync.
• Device hardware: Bluetooth instruments and sensors, label and receipt printers, rugged scanner integrations, kiosk or shared-device modes that go beyond camera, barcode, location and file capture.
• Licensing at scale: hundreds or thousands of frontline staff who each capture a small amount of data, where per-user licences are hard to justify, and the data can live on a platform you own.
• Experience: an app used by subcontractors or customers who will not accept a business app shell.
• Not a reason: wanting the app to look different. Form design and a canvas front end usually solve that for far less ownership.

How does per-user licensing change the answer for hundreds of frontline staff?

Every Microsoft route is licensed per user. A technician using the Field Service mobile app needs a Field Service licence. A person using a canvas app over Dataverse needs a Power Apps licence that covers it, and some Dynamics 365 tables are restricted so that writing to them needs a Dynamics 365 licence of an appropriate type, so a canvas app that writes work orders is not automatically a cheaper seat. We do not publish prices, and the right answer depends on the tables each group touches and on Microsoft terms at the time, so confirm it with your licensing contact.

The common misunderstanding is that a custom app avoids licensing. A custom app that reads and writes Dataverse through a service account does not: Microsoft counts the people whose work reaches Dataverse, and pooling them behind one account (multiplexing) does not reduce what they need. A custom app only removes Microsoft licensing when its data lives on your own platform, for example PostgreSQL behind a Node.js or .NET API, with only the summary the office needs synchronised back. How to count seats across options is covered in the field inspection app cost comparison.

How do the three routes compare on offline behaviour?

All three can work without signal; they differ in who controls what happens when the device reconnects. The Field Service mobile app and offline canvas apps use the platform offline profile and platform sync, so you control what is downloaded and how the app is designed, and Microsoft controls the sync engine. A custom app gives you the sync engine too, which is only an advantage if you are prepared to design and test it properly.

Why offline records go missing, how conflicts are resolved, client-generated keys, idempotent upsert and reconciliation views are all covered in our offline field data loss guide, so we do not repeat them here. Read it before deciding that offline problems justify a custom build: most offline data loss we are asked about is a design problem that the same platform can fix.

What maintenance obligation does each choice create, and who has to own it?

The build is the smaller part of the cost of a frontline app. Decide who owns each obligation before you choose, and write it into the support model, because an app nobody owns degrades quietly until technicians go back to paper.

Should frontline mobile run on Dynamics 365 or on a custom-built platform?

The mobile decision is often the first place the wider platform question becomes concrete. We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both.

If the office runs on Dynamics 365 and the frontline are technicians or a manageable number of licensed staff, keep the mobile app on the platform: the native app first, a canvas app for simplified capture, and extensions where a step is awkward. If the frontline workforce is very large, captures a small amount of data each and has no need to work inside Dynamics 365, a custom-built CRM and field app on React, Node.js, PostgreSQL or .NET, integrated with Dynamics 365 where the office needs the data, can be the more sustainable choice. Both are legitimate, and some organisations run both for different groups.

How does Solzet help you choose and build a field mobile app?

We start with the constraint, not the build. A short assessment walks through a real job with the people who do it, reviews the data model and offline needs, counts who touches which tables, and ends with a written recommendation: native app, canvas app, custom application or a combination, with the maintenance owner named for each.

We then build whichever route wins: configuring and extending the Field Service mobile app, building canvas apps on Dataverse, developing PCF controls, or delivering a custom application and backend. Solzet delivers remotely from Yerevan, Armenia, with senior consultants and full-stack developers and 8+ years of Dynamics 365 Customer Engagement, Power Platform and custom CRM development, directly or white-label for Microsoft partners.