Field Service Mobile Showing Only the Last Visit: Getting Full Asset Service History in Front of Technicians

Why does the Field Service mobile app show only the last visit?

Because the technician is looking at the copy of Dataverse that was downloaded to the device, through forms and views someone configured, not at the whole database. In the office, the same asset opened in a browser can show years of work orders, while the phone shows one. Both are working as configured.

The Field Service mobile experience is a model-driven app running in the Power Apps mobile app, with a mobile offline profile deciding which rows of which tables are downloaded. The profile is designed for the next few days of work, which is exactly right for sync time and battery, and exactly wrong for a technician who needs to know what was done to this machine three years ago. How we scope the profile during a rollout is on our Field Service implementation partner page; this page is the troubleshooting path when history is missing.

• The offline profile only downloads work orders tied to the technician's own bookings or a recent date range.
• The form has no subgrid for historical work orders, or the subgrid uses a view that shows only active or own records.
• Past visits are linked to the asset through work order incidents, a parent asset or a replaced unit, not the field the subgrid follows.
• The older records no longer exist in the active database, because a retention policy or bulk deletion job removed them.

How do you check the mobile offline profile scope and filters?

Open the mobile offline profile used by the Field Service mobile app in the Power Apps maker portal or the app's offline settings, confirm which profile the affected technicians actually use, and read the filter on each table that holds history. Profile names, defaults and where the settings live have changed across releases, so check current Microsoft documentation for your version rather than assuming the out-of-the-box filters.

Is the app in offline mode or online mode when history is missing?

It matters, because the two modes read from different places. In offline mode, or in an app configured as offline-first, forms, views and subgrids read from the data on the device, so a row outside the profile is simply not there, even if the phone has a signal. In online mode the app queries Dataverse directly, subject to the user's security role, so the same subgrid can show full history.

A quick test: open the same asset on the same device with a signal, once with the offline profile active and once in online mode or in a browser session with the same user. If history appears online and not offline, the profile is the cause. If it is missing in both, look at the form, the relationship chain or retention. If it is missing only for some technicians, compare security roles and business unit access. How offline-first apps treat tables and rows outside the profile has changed between releases, so confirm the current behaviour in Microsoft documentation before relying on an online fallback.

Does the work order form actually have a service history subgrid?

Often it does not, or it has one that filters out what the technician needs. The mobile forms used in Field Service are separate from the forms office users see, so a history tab added to the desktop form does not appear on the phone.

• Check the form the mobile app actually uses for work order and for customer asset, including form order and security role assignment, not the one you edit most often.
• On the work order form, look for a section showing other work orders for the same customer asset or functional location, rather than only the incidents of this work order.
• On the customer asset form, add or check a subgrid of related work orders and a subgrid of work order incidents, since those two relationships hold different visits.
• Open the view each subgrid uses: views such as active, open or "my" work orders hide closed and completed visits, which are exactly the history. Use a view that includes completed and closed statuses, sorted newest first.
• Check the number of rows the subgrid shows and that "see all" opens a view the technician can use on a phone.
• Publish the customizations and resync the device; the app caches metadata, so a change may not appear until it refreshes.

Is the history linked to the customer asset the way the subgrid expects?

A subgrid follows one relationship, and service history in Field Service rarely sits on one relationship. When a subgrid on the asset lists work orders through the primary customer asset on the work order header, every visit that recorded the asset only on a work order incident, or not at all, is invisible.

• Header versus incident: a work order has a primary incident customer asset, and each work order incident can carry its own customer asset. Multi-asset visits often only link the extra assets on the incident.
• Parent and component assets: a visit recorded against the top-level machine does not appear on the component asset, and the reverse. Decide which level the technician opens and show history for the hierarchy where it helps.
• Replaced units: when a unit is swapped, its history stays on the old asset record. A functional location, or a link from the new asset to the one it replaced, keeps the history of the position visible.
• Legacy history: visits imported from a previous system may sit in notes, a custom table or on the account, not as work orders linked to the asset.
• Visits with no asset: work orders created against an account or site without choosing an asset never show on any asset. Make the asset required on the incident types where it matters.

Could a retention policy or bulk deletion job have removed older records?

Yes, and it is worth checking early, because every day a recurring job runs, more history goes. In the Power Platform admin center and advanced settings, review system jobs for recurring bulk deletion jobs on work orders, bookings, incidents, notes or activities, and check who created them and their criteria. Also check Dataverse long term data retention policies: where configured, retained rows move out of the active tables into a read-only long term store, which means they no longer appear in app views, subgrids or on the mobile device. Look for flows, scheduled integrations or storage cleanup scripts that delete completed records too. Long term retention capabilities and how retained data can be viewed change by release, so check current Microsoft documentation.

Storage pressure is the usual reason these jobs exist. Which records are safe to clean up, and which should never be bulk deleted, is covered in our Dataverse storage capacity cleanup guide.

What should you preserve immediately if a job is deleting service history?

Stop the loss first, then decide the policy. Deleted Dataverse rows are not something to count on recovering later.

• Pause or cancel the recurring bulk deletion job, or disable the flow or integration doing the deleting, and record its criteria and schedule before changing anything.
• Export what remains of the affected tables now, including work orders, incidents, service tasks, products used, notes and attachments, to a store you control, such as Azure Synapse Link for Dataverse, Microsoft Fabric or a plain export.
• Check whether recently deleted rows can be restored through the Dataverse recycle bin feature, if it is enabled for your environment, and within its retention period.
• If important history is gone, restore a system backup into a separate environment, never over production, and extract the missing records from there. Check current Microsoft documentation for backup retention for your environment type.
• Agree a written retention rule for service history with the service owner and, where relevant, compliance, before re-enabling any cleanup.

Which configuration changes surface multi-year history without custom development?

Most teams can get full history in front of technicians with configuration alone. Pick the combination that suits how often technicians need it and how much the devices can hold.

How much service history can the offline device realistically hold?

Less than the database, and the limit you hit first is usually sync time rather than storage. Every extra year of work orders, incidents, tasks and notes multiplies the rows synchronised for every technician, and first sync on a new or reset phone is when a wide profile hurts: technicians wait at the depot, sync is interrupted, and people stop trusting the app.

Bound history by what a technician actually uses on site. For many operations that is a few years of completed visits for the assets on the next few days of jobs, as structured records, with photos and documents left online. Test with the technician who has the largest territory on the oldest supported device, measure first sync and incremental sync, and adjust the window from that. Why offline records sometimes fail to arrive at all is a different problem, covered in our guide to offline field apps that do not lose data.

Where does customer-facing asset history fit in?

If customers also need to see the service history of their equipment, the same underlying questions of one canonical asset, reliable links from visits to assets and a curated history table apply, with portal security on top. That design, including the curated service history table that also makes a compact offline download, is covered in our guide to Field Service asset history customers can see. For manufacturers in Germany and DACH, the offline and works council context is on our manufacturing industry page, and the choice between the standard mobile app, a canvas app and a custom app is on our Dynamics 365 mobile app options page.

Should service history for field technicians run on Dynamics 365 Field Service or a custom build?

For most organisations already on Field Service, this is a configuration fix, not a reason to change platform. 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. Where technicians outnumber office users by a wide margin, per-user licensing does not fit, and the workflow is simple, a custom-built CRM with a mobile interface on React, Node.js, PostgreSQL or .NET is the alternative we build.

How does Solzet fix missing service history on the Field Service mobile app?

We run the checks on this page against your environment: the profile each technician uses, the mobile forms and views, how visits link to assets, and any retention or deletion activity, and we stop any job that is removing history before anything else. Then we widen the profile with bounded filters, add history subgrids to the mobile forms, fix the asset links on incident types, and test sync on real devices with your largest territories.

The work is done by senior consultants and full-stack developers delivering remotely from Yerevan, Armenia, with 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly for your team or white-label for Microsoft partners.