Field Service Asset History Customers Can Actually See

Why do customers say the asset data in the portal is wrong?

Because they are looking at the join between two systems that never agreed on what an asset is. The asset register holds serial numbers, models and install dates; the service system holds visits against a site, a contract or a free-text equipment description. When the two are stitched together for a portal, visits attach to the wrong unit, replaced equipment still shows as installed, and a machine moved between sites carries history that belongs to its old location. The customer knows their own equipment better than your data does, so they notice immediately.

Publishing the stitched data faster does not help. The fix is to decide what the single asset record is, where it lives, and which system is allowed to change each part of it, before any customer sees it.

• Visits recorded against a site or contract, not a specific serial number.
• Different identifiers for the same unit in each system, with no mapping table.
• Replaced or scrapped units never closed in the asset register.
• Equipment sold, moved or transferred between customers, with history following the unit to the new owner.
• Contacts linked to the wrong account, or to a shared account used for convenience.

What should the canonical asset model in Dataverse look like?

Use the Dynamics 365 Field Service tables for what they are designed for, and add a small number of your own where the portal needs a curated view. The customer asset is the record every system points to. Assets form a hierarchy through the parent asset, with the top-level asset identifying the whole installation, and functional locations describe the position at the customer site separately from the unit currently installed there. How to model that hierarchy for your equipment is part of the build described on our Field Service implementation partner page, so we only cover what the portal adds.

The important design choice is not to show customers raw work orders. Work orders carry internal notes, costs, scheduling detail and statuses that mean nothing outside your company. Publish a customer-facing service history table instead, one row per completed visit per asset, written by the legacy import for past visits and by a process on work order completion for new ones.

How do you match legacy asset and service records to one asset?

Matching is the part that decides whether customers trust the portal, and it cannot be fully automated. Load the asset register first, because it holds the identity of each unit, then attach service history to those assets. Store every legacy identifier on the Dataverse record as an alternate key, so each source record maps to exactly one row and can be reloaded safely.

• Match on product and serial number first, then on legacy identifiers from any existing cross-reference, then on site and equipment description with a human review.
• Put every record that does not match cleanly into an exceptions table with a named owner, rather than guessing or dropping it.
• Where history was recorded against a site only, attach it to the functional location, not to whichever asset happens to be there now.
• Mark units that are replaced or scrapped as inactive with a date, so the installed base shows what is really on site.
• Give customers a "report incorrect data" action on each asset that creates a correction request for your team; it turns complaints into a queue you can clear.
• Duplicate detection rules on serial number help stop new duplicates once the load is done.

How do you make sure no customer sees another customer's equipment?

Scope everything through the relationship between the signed-in contact and their account. In Power Pages, a table permission with the Account access type grants rows related to the parent account of the signed-in contact, through a relationship you choose. Put an Account-scope read permission on customer asset through its account relationship, and on functional location and service history in the same way. Documents and other child records get Parent-scope permissions that follow the relationship to a record the user can already reach, so a report is visible only because its asset is.

The full model, including why a Parent permission under a Global parent is effectively Global and how to test as a real external user rather than as an admin, is on our Power Pages table permissions guide. Two points are specific to asset portals.

• Equipment changes hands. If service history is only scoped through the asset, a new owner sees the previous owner's visits. Store the account on each service history row at the time of the visit and scope history by that account, not only by the asset.
• Group customers. Account scope follows the contact's parent account; if head office users must see equipment at several site accounts, design that access explicitly and test it, rather than assuming an account hierarchy is followed.
• Contact hygiene. A contact attached to the wrong or a shared account exposes that account's whole installed base; review contact-to-account links before invitations go out.
• Read only by default. Customers rarely need to write to assets; route corrections through a request table instead of granting write.
• Never enable the Web API for these tables with wider permissions than the pages use.

What should customers see first?

A short list of things they can check against reality, done well. The first release earns trust when every asset a customer sees is theirs, correctly located and correctly dated. Adding more screens before that is true multiplies complaints.

• Never show technician internal notes, costs, prices, margins or internal statuses.
• Show dates in the customer time zone and state when the data was last updated.

How are external customer users licensed?

Customer contacts who sign in to a Power Pages site are covered by Power Pages authenticated user capacity for that site, counted per month as unique people who sign in, not by internal Power Apps or Dynamics 365 licences. Anonymous visitors to pages that read Dataverse count towards anonymous capacity. Internal staff with qualifying licences can generally use the site without consuming external capacity. Capacity is per website, so running a separate portal per region or brand multiplies it.

We do not quote prices, and Microsoft revises definitions and qualifying licences, so check current terms before you budget. How licensing scales with audience size, and why a custom front end over Dataverse does not remove it, is covered in our Power Pages or custom front end comparison.

How do you sync from legacy systems while they keep running?

Treat the legacy systems as the source of truth until each one cuts over, and make Dataverse a one-way, incremental copy of them in the meantime. A full reload every night is simple to build and painful to run: it rewrites every row, fires every plug-in and flow, and makes it impossible to tell what actually changed. An incremental sync moves only what changed since the last successful run and can be replayed safely when a run fails.

• Detect change in the source: a modified date watermark, a change table or an export of changed records since the last successful run, stored per source.
• Upsert on alternate keys that hold the legacy identifiers, so a record is created once and updated after that, and a rerun never creates duplicates.
• Load in dependency order: accounts, functional locations, assets and their parents, then service history, then documents.
• Handle deletions explicitly with an inactive flag rather than deleting rows the portal or history may still reference.
• Block edits in Dataverse to fields the legacy system still owns, by security role or form logic, so the sync is never overwritten and never overwrites.
• Run a reconciliation of counts and key fields per source after each run, with differences reported to a named owner.
• Tooling can be dataflows, Azure Data Factory or an integration service; the choice matters less than keys, watermarks and reconciliation.

How do you cut over from the legacy systems without a gap in history?

One source at a time, with ownership moving on a stated date. Customers should never see a period where recent visits are missing because the old system stopped and the new process had not started. If you are also untangling several Field Service versions or regions at once, the sequencing guidance in Field Service transformation on a legacy estate applies here too.

Should the customer portal run on Power Pages or a custom front end?

For most Field Service customers Power Pages is the natural route, because the assets and history already live in Dataverse and table permissions do the scoping. The Power Platform consulting service describes what a Power Pages build covers. It is still a platform decision worth making deliberately. 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.

A custom front end becomes the better choice when the portal is a product in its own right with its own experience requirements, or when the asset data belongs on a platform you own and a very large external audience makes Microsoft licensing hard to justify. In that case a custom-built CRM and portal on React, Node.js, PostgreSQL or .NET, integrated with Field Service for the technicians, carries the same canonical model and the same account-scoped security in your own code.

How does Solzet deliver a customer asset history portal?

We start with a data assessment: exports from the asset register and the service system, a trial match of a representative sample, the list of exceptions and their causes, a proposed canonical model, and the permission design written out table by table. That tells you how much of the history can be shown with confidence before a portal is built.

Delivery then combines three pieces of work in one project: the Field Service and Dataverse model, the incremental sync from the legacy systems, and the Power Pages site with tested table permissions. 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. We integrate with ERP and finance systems that hold equipment or billing data but do not implement them.