A Multi-Phase Field Service Programme on an Estate of Old Versions

Why does a big-bang Field Service programme fail on an estate of mixed versions?

Because it asks the organization to change everything at once on a foundation nobody has measured. A typical patchwork estate grew region by region: one business unit on an older on-premises Dynamics CRM with a Field Service solution that predates the current app, another online on a current version, a third still dispatching from a scheduling tool or spreadsheets, and technicians spread across different mobile apps. Each has its own customizations, its own copy of customer and asset data and its own integrations to the ERP. A single programme that designs the future state for all of them, then migrates them together, stacks every unknown into one go-live.

The board sees the cost of that approach long before it sees any benefit. The design phase runs long because every region has exceptions, the estate keeps failing underneath the programme, and the first measurable result arrives at the end, if it arrives. The alternative is not a smaller ambition. It is a different order: make the estate safe and knowable, and in parallel prove the target model on one slice of real work where the result can be measured.

How do you assess a mixed Field Service estate before building anything?

One environment at a time, with the same questions for each, so the answers can be put side by side. The goal is not a report for its own sake, it is to know which environments can carry new work, which need remediation first, and which should be retired rather than upgraded. Where you want each environment audited independently, with findings rated by impact and effort, that is what our Dynamics 365 health check and technical audit delivers; this page only describes what the programme needs from it.

Which estate risks must be closed before any new build starts?

Not every finding has to be fixed before the pilot, and trying to fix all of them first is just a big-bang programme with a different name. The rule is narrower: close the risks that would undermine anything built on top of the estate, or that could stop the business while the programme is running. Everything else goes into a prioritised remediation backlog that runs alongside. Where unsupported code dominates the list, the classification and remediation in slices is described on our upgrade remediation service for unsupported customizations.

• An environment that cannot be restored, or whose restore has never been proven.
• Changes still made directly in production, with no source control and no way to roll back a release.
• Technicians depending on a mobile app that is retired or unsupported, with no plan to move them.
• Integrations nobody owns, running as a named person or with credentials nobody can rotate, that carry work orders, parts or invoicing.
• Administrator access that is shared, stale or held by a former partner.
• Customizations known to break on platform updates on the environments where the pilot or its integrations will run.
• Personal data about technicians or customers kept without an agreed retention rule.

How do you run estate remediation and a pilot in parallel without them colliding?

By giving each track a clear boundary and a small number of shared rules. The remediation track owns the platform baseline: environments, ALM, security, unsupported code and the integration contracts. The pilot track owns one slice of business change on top of that baseline. They collide when the pilot builds on an environment remediation is about to change, or when remediation breaks an integration the pilot depends on, so both are prevented by rule rather than by goodwill.

• The pilot is built on a current, supported environment with source control and a pipeline, never on an environment that is due to be retired.
• Both tracks release through the same pipeline and the same change calendar.
• The integration dependency map is the shared contract: any change to an integration the pilot uses is agreed with the pilot owner first.
• Findings from the pilot, such as a data quality issue in the asset master, go into the remediation backlog rather than being patched inside the pilot.
• One steering forum sees both tracks, with remediation reported as risk closed and the pilot reported against its baseline.
• Where the integration estate itself is the problem, it becomes its own workstream, following rationalising point-to-point integrations.

How do you choose a pilot that can prove ROI to the board?

The pilot is not a demo of the future platform, it is the smallest piece of real work where a change in the system produces a change in a number the board already cares about. The selection rule has four parts: one work type, one region or depot, a baseline you can measure today from data you already have, and few integrations. Preventive maintenance on contracted assets, or one category of reactive repair with a clear service level, often fits; a pilot that needs the ERP integration, the customer portal and route optimization all at once does not. The format for building it quickly on your own data, ending with technicians using it, is the feasibility sprint on our Dynamics 365 Field Service implementation partner page.

Which field-team objections actually sink these programmes, and how do you answer them?

Field programmes are rarely rejected in a steering meeting. They are rejected in vans, when technicians quietly go back to paper and the data stops meaning anything. The objections below are the ones worth taking seriously, because each one is usually correct about the first design. Answer them in the pilot, with the technicians in the room, not in the rollout training. The offline side is covered in depth in our guide to offline field apps that do not lose data, and what a completed job has to capture in our guide to field service proof of work.

Who else must agree before technician data is captured?

In several European countries a works council, where one exists, generally has a say over systems that can be used to monitor employee behaviour or performance, and technician location stamps, arrival and departure times and scheduling optimization based on them usually fall in that scope. Involve employee representatives when the pilot is scoped, with the exact fields, visibility rules and retention written down, rather than at go-live. The detail for manufacturers in Germany, Austria and Switzerland is on our manufacturing industry page. Take legal advice for your own jurisdiction; this page is not it.

Time recording deserves the same care. If travel and work time captured on the work order will feed payroll or working time records, agree the rounding and break rules with the people who own those obligations before the first technician uses the app.

How do you answer the regulator question about IoT data before it is asked?

Connected Field Service turns device telemetry into alerts and work orders, and that is exactly the point at which regulators, auditors and customer security teams start asking questions. The data arrives through an Azure IoT service or a third-party platform before anything reaches Dataverse, so the answers span two or three systems and nobody owns them unless the programme assigns them. Write a data flow register for the IoT scenario before it goes live, even in a pilot, and it becomes the document you hand over when the question comes.

Solzet designs the Field Service and Dataverse side and the register itself; the device fleet and the Azure IoT platform are usually owned by your engineering or infrastructure team, and the register makes that split explicit.

• What is collected: which devices, which signals, how often, and whether any of it can identify a person, such as a device tied to a named user or a home address.
• Where it is stored and processed: the Azure region of the IoT service, the Dataverse environment region, and any analytics store, with the retention period for each.
• What decides an alert: the rule or threshold that turns telemetry into an alert and a work order, who can change it, and whether changes are recorded.
• Who can see it: roles with access to raw telemetry, to alerts and to work orders, including partners and subcontractors.
• How devices and connections are secured: device identity, credential rotation and who is notified if a device is compromised.
• What the customer was told: the contract or notice that covers collecting data from equipment at their site.

What should the board measure, and when?

Two sets of measures, matching the two tracks, and a baseline taken before the pilot starts. Without the baseline any ROI claim at the end of the pilot is an opinion, which is why the pilot selection rule insists the number already exists. We do not publish typical improvement figures, because they depend entirely on where each organization starts; the board should compare the pilot against its own baseline and nothing else.

How are later phases sequenced once the pilot has proven itself?

Only after the pilot has reported against its baseline, and phase by phase with a decision point each time. The usual order is to extend the proven work type to the next region on the current environment, consolidate or retire the older environments as their regions move rather than upgrading each one, and add the harder capability, such as route optimization, customer portals or connected devices, once the core flow is stable. If dispatch is where the programme started and the choice between Field Service and a dedicated tool is still open, settle that first using our Field Service versus dedicated scheduling software comparison.

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. For a region or business line where per-user licensing does not fit, for example a large subcontractor network, the honest answer can be a lighter custom-built application integrated with Field Service rather than more licences. Solzet delivers the Field Service, Power Platform and custom build work remotely from Yerevan, Armenia, directly or white label for a Microsoft partner; we do not implement Dynamics 365 Finance, Supply Chain Management, Business Central or other ERP systems, and work alongside the team that owns them.