Dynamics 365 Field Service Implementation Partner
A feasibility sprint that validates your requirements against the product and ends in a working pilot, for service organizations in the Netherlands and across Europe.
Solzet is a Dynamics 365 Field Service implementation partner. We are a Microsoft Dynamics 365 Customer Engagement and Power Platform consultancy based in Yerevan, Armenia, delivering Field Service for service organizations in the Netherlands and across Europe, either directly or white label underneath a Microsoft partner who needs Field Service capacity. We do not open with a licence count and a twelve month plan. We open with a feasibility sprint: a short fixed scope engagement that tests your real work orders, assets and technician routes against what the product actually does, and ends with a configured pilot running in your own tenant rather than a proposal. The two things that decide a Field Service rollout are the asset and work order model underneath it, and whether the mobile app still works when the technician has no signal. Those are the two we build first.
The short answer
- What we implement. Dynamics 365 Field Service on Dataverse: customer assets and functional locations, work orders, incident types and service tasks, agreements and preventive maintenance, bookable resources, the schedule board and resource scheduling optimization, and the technician mobile app, extended with Power Apps, Power Automate, Power BI and custom PCF controls where the standard product stops short.
- How we start. A feasibility sprint of roughly three weeks, fixed scope and fixed price, agreed in writing before it begins. It ends with a pilot configured in a real environment, an honest verdict on whether Field Service fits, and an estimate for the rollout that is based on your data rather than on a discovery questionnaire.
- Where we deliver. Remotely from Yerevan for clients in the Netherlands, the wider EU, the UK and the US. Armenia is UTC+4 with no daylight saving, so we are two to three hours ahead of Amsterdam and our working day opens before yours. Contracts are B2B with a mutual NDA, a GDPR compliant data processing agreement, and IP ownership stated in the statement of work.
- What we are not. A Dutch company, a Dutch language service desk, or a partner for the Microsoft finance and ERP products. We stay on the Customer Engagement side of Dynamics 365 and on the Power Platform, and we integrate cleanly with whichever ERP you already run rather than claiming ground we do not hold.
Still deciding whether the Microsoft route is right at all? Start with our comparison of Dynamics 365 Field Service against dedicated scheduling and dispatch tools, then come back here.
Why we start with a sprint instead of a proposal
Most Field Service engagements begin with a requirements workshop and end with a number that was invented before anybody looked at the data. These are the six reasons we think that order is backwards, and they are also, in our experience, the six places these projects go wrong.
A demo proves the product works, not that it fits you
Every Field Service demo schedules a clean job for a clean technician against clean data. Yours has a two person lift, a certification that expires, a customer site that only accepts visits on Tuesday morning, and a machine whose serial number exists in three systems and matches in none. The demo cannot tell you whether the product handles that. Three weeks against your own data can.
The requirements document is written before anybody knows the vocabulary
Requirements gathered before the team has seen the data model come back in the language of the current spreadsheet, so they ask for a maintenance request table and a status column. Field Service already has that concept, under different names, wired into the scheduling engine. Requirements are worth writing after you know what the product calls things, which is the wrong way round from how most projects run.
The estimate everyone signs is the least informed one
The number in the proposal is produced at the moment of maximum ignorance, before anybody has opened your asset export or watched a dispatcher work. It then becomes the budget the whole project is judged against. A sprint moves the estimate to after the evidence, which is the single change that most reduces the odds of a rescue later.
Mobile and offline get discovered at user acceptance testing
Offline is treated as a setting to switch on near the end. It is a design decision that shapes the data model, the filters, and what a technician can do in a plant room with no signal. Found late, it is the thing that makes the app unusable and the rollout stall. We test it in the first sprint, on a real phone, with the network switched off.
Nobody agreed where Field Service stops and the ERP starts
Work orders, parts consumption, van stock, invoicing and stock valuation touch two systems. If the boundary is not drawn early, both sides assume the other owns it and the gap surfaces at go live, in finance, in front of the people least willing to be surprised. Drawing that line is a sprint deliverable.
The pilot is the only honest reference
You can read our case study and you should, but a build for another company is evidence about us rather than about your project. A pilot in your own tenant, with your assets and your dispatcher clicking through it, is the reference that actually predicts the rollout. It is also yours to keep whether or not you continue with us.
The failure modes themselves are written up separately in why mid-market companies fail at D365 Field Service implementation, which is the right read before you scope anything.
The feasibility sprint, day by day
Roughly three weeks, fixed scope and fixed price agreed in writing before it starts. Every window below has a deliverable with a name, so the scope is something you can check rather than something you have to trust. The sprint runs in your own tenant, in a sandbox, and touches nothing in production.
- 1
Before day one: agree the scope note and the access
We write down what the sprint covers before it starts: which service organization, which one or two work order types, which crew or territory, which data extracts we need, and who from your side is in the room. The fixed price and the dates go on the same page. You create us accounts in your own tenant with least privilege, and a sandbox environment for the pilot. Nothing touches production.
- 2
Days 1 to 3: follow the work, not the requirements
We sit with the dispatcher for a morning and watch how the day is really assembled, including the parts that happen on the phone and in a spreadsheet. We follow two or three jobs end to end, from the call or the maintenance interval that created them through to the paperwork that closes them, and we talk to two technicians about what the job is actually like. The deliverable is a written description of the current process that your own dispatcher agrees is accurate.
- 3
Days 4 to 6: map your operation onto the Field Service model
We translate what we saw into the product vocabulary on paper: what is a customer asset and what is a functional location, which incident types carry which service tasks, which work is generated by an agreement and which arrives reactively, which resources are bookable and what characteristics and territories constrain them, and where a requirement group is needed because a job takes two people or a specific vehicle. The deliverable is the model, plus a short list of the places your operation does not fit the standard shape and what each of those costs to handle.
- 4
Days 7 to 9: open the data and see what is really there
Scheduling is arithmetic over data you may not have. We take exports of the installed base, the service addresses, the technician skills and the parts catalogue and check them against what the model needs: assets with a serial number and a location, addresses that geocode, skills recorded as something other than free text. The deliverable is a data readiness note that says what is usable now, what needs cleaning, and what does not exist and has to be captured.
- 5
Days 10 to 12: build the pilot, configured rather than mocked
We configure the model in the sandbox and load a real slice of your data into it: your assets, your incident types, your technicians, one territory. Work orders are generated the way they would be in production, the schedule board is set up with your constraints, and the whole thing goes into a managed solution with development, test and production separated from the first day, so the pilot is the beginning of the build rather than something thrown away.
- 6
Days 13 to 14: put it in a technician hand and switch the network off
The mobile app is loaded on a real device with an offline profile scoped to one technician and one route. Then we go through a full job with the network disabled: open the asset, run the inspection tasks, record measurements, take photographs, consume a part, capture a signature, produce the service report, and sync it afterwards. The deliverable is the recorded run and an honest note on what the standard app does not cover and would need a canvas app or a custom control.
- 7
End of sprint: the verdict, the number, and the plan
We present the pilot to the people who will own it, then give the verdict in writing: proceed as configured, proceed with a named set of changes, or do not proceed and here is why. With it comes a rollout estimate built on what we found rather than on assumptions, a sequenced plan with the data cleanup on the critical path where it belongs, and everything we produced, including the solution, handed to you. If you take that plan to a different partner, it still works.
How the sprint can end
Three outcomes, and we will tell you which one you have in writing. A sprint that can only conclude yes is a sales process wearing a delivery costume.
Proceed, and here is the number
The model fits, the data is workable, and the pilot did what it needed to do. You get a rollout plan sequenced against the real constraints, with the data cleanup on the critical path, an estimate grounded in the sprint rather than in assumptions, and a pilot that is already the first increment of the build rather than a throwaway.
Proceed, but not the way it was scoped
This is the most common outcome. The product fits, but something in the plan does not: the asset hierarchy has to be rebuilt before anything else is worth doing, the scheduling ambition needs to wait until skills exist as data, or the phase order should be reversed so preventive maintenance goes first and reactive dispatch follows. Better found in week three of a sprint than in month seven of a rollout.
Do not proceed, and here is why
Sometimes the answer is that Field Service is more platform than the operation needs, and a dedicated scheduling and dispatch tool is the better buy. We say so, in writing, and you have spent the cost of a sprint rather than the cost of a programme to find out. If you want that argument before you spend anything at all, our comparison of Dynamics 365 Field Service against dedicated dispatch tools makes it in full.
Asset management is where Field Service is won or lost
Scheduling gets the attention because it is the part you can see moving. The model underneath it is what actually decides whether the system is still useful in year three. These are the tables we care about most, and what breaks when each one is modelled carelessly. If a partner cannot talk about these without prompting, that tells you something.
Customer assets, in a hierarchy that matches the machine
The installed base is the spine of the system. Assets model in a parent and child hierarchy, so a production line holds machines and a machine holds the components that get replaced, each with its own serial number and warranty. Get this right and service history, warranty and failure analysis follow for free. Get it flat and you can never answer which component keeps failing, only which customer keeps calling.
Functional locations, for structure that outlives the equipment
A functional location is the position in the plant rather than the box currently sitting in it. Model the site structure separately from the assets and a swapped unit keeps the history of its position, which is what makes an inspection record meaningful three years later. Skip it and every replacement resets the history to zero.
Incident types carrying service tasks, products and duration
An incident type is the reusable definition of a kind of job: the tasks to perform, the parts usually consumed, the services billed and the realistic duration. This is where estimating accuracy comes from, and where the technician gets a checklist rather than a title. Projects that skip incident types end up with a free text description field and a schedule board that cannot estimate anything.
Agreements that generate the preventive work by themselves
Contracted maintenance is modelled as an agreement against the asset, with the interval, the incident type to use and the booking window. The system then generates the work orders and the bookings on schedule without anybody remembering. This is the piece that converts a reactive break and fix operation into a planned one, and it is usually the fastest measurable return in the whole build.
Bookable resources with characteristics, territories and calendars
Technicians, and also vehicles and specialist equipment, are bookable resources. Certifications and skills are characteristics with proficiency, geography is territories, and availability is a real work calendar including part timers and shifts. The scheduling assistant is only as good as these three. Where they are missing, the system suggests the nearest person rather than the right one, dispatch stops trusting it, and the schedule board reverts to being decoration.
Requirement groups for the jobs that are not one person and one hour
A two person lift, a job needing an electrician and a mechanic together, or a task that must follow another on the next day, is a requirement group. It is the standard answer to the complex jobs that people assume need custom development, and knowing that in advance is often the difference between configuring the product and rebuilding a chunk of it.
The anti pattern we look for first
If the previous design proposes a custom maintenance request table with a status option set, Field Service is being rebuilt from scratch on top of itself and the scheduling engine has been thrown away. It is the most expensive mistake available on this product and it is entirely avoidable. Finding it before the build starts is one of the reasons the sprint pays for itself.
This is the same modelling work behind our Field Service digitization case study for a European manufacturer, where an installed base of customer assets in Dataverse, work orders generated from maintenance agreements and a mobile app the technicians adopted moved 50 plus technicians off spreadsheets and phone calls in four months.
Mobile and offline, designed for no signal at all
The technician mobile app is the only part of the system most of your field team will ever touch, and it is the part that decides adoption. We design it offline first, because plant halls, basements and remote sites are where the work happens and guest wifi is refused as a matter of policy at plenty of customer sites.
Offline is the design, not a switch
We treat connectivity as the exception rather than the norm, because plant halls, basements, lift shafts and rural sites are where the work is. Every decision about the mobile experience is made assuming there is no signal, and the online case then takes care of itself. The opposite order does not work: an app designed online first and made offline late is the app technicians stop opening.
The offline profile is scoped to a technician and a route
The profile brings down what one person needs for the next few days of work, not the database. Filters pull the assets, agreements, service history, parts and price lists for the accounts on that route. The practical test is the first sync on a new phone: minutes, not an afternoon, or the rollout stalls on day one at the depot.
Conflict rules agreed before anybody hits them
Two people will eventually touch the same record while one of them is offline. Which fields resolve in favour of the field, which in favour of the office, and what happens to the ones that cannot be decided automatically, is a conversation to have with dispatch during the build rather than a defect raised after go live.
A whole job closed with the network off
The workflow we build is designed to complete with no signal at all: scan the machine by QR or barcode to open the right asset, run the service tasks, record measurements against typed fields rather than a notes box, photograph the fault, consume parts from van stock, capture the customer signature, and generate the service report on the device. Everything queues and syncs on return to coverage, and dispatch sees a sync status per resource instead of guessing.
Where the standard app stops, we extend rather than replace
Multi day jobs, a shift with no coverage at all, a device or workflow requirement of your own, or an inspection form that has to look like the paper one it replaces: these are handled with a Power Apps canvas app caching the same Dataverse tables, or with a custom PCF control inside the standard app. Building custom controls is a service line of ours in its own right, so this is our normal work rather than an escalation.
Adoption is a technician question, not a training question
Technicians adopt an app that takes fewer taps than the paperwork it replaces and abandon one that takes more, whatever the training plan says. So we count the taps in a real job during the sprint, we put the app in a technician hand before the design is frozen, and we treat the first two people who try it as the design authority for the mobile layer.
The extension route is described in more detail in our guides on using PCF controls in canvas apps and on custom PCF control development. If you are weighing a Field Service mobile rollout against a standalone inspection product, our Power Apps versus inspection platforms comparison covers that decision.
A Dynamics 365 Field Service partner for the Netherlands
Dutch service organizations work with us in two shapes: directly, where we are the implementation partner and your people deal with our consultants, and white label, where a Dutch Microsoft partner has won a Field Service project and needs the delivery capacity under their own brand. Both run the same way technically. The claim worth checking first is the time zone one, because it is arithmetic rather than marketing. Armenia sits on UTC+4 and has not observed daylight saving since 2012.
| Period | Offset | Our 09:00 to 18:00 in your time | Overlap with a 09:00 to 17:30 Dutch day |
|---|---|---|---|
| Dutch winter time (CET, UTC+1) | Yerevan is 3 hours ahead | 06:00 to 15:00 in Amsterdam | 09:00 to 15:00, six hours of live overlap |
| Dutch summer time (CEST, UTC+2) | Yerevan is 2 hours ahead | 07:00 to 16:00 in Amsterdam | 09:00 to 16:00, seven hours of live overlap |
| Shifted schedule by agreement | Team starts two hours later in Yerevan | 08:00 to 17:00 in Amsterdam in winter | Almost the whole Dutch working day |
For a feasibility sprint that overlap matters more than it does for a build, because the first days are workshops with your dispatcher and your technicians rather than heads-down configuration. Those sessions run live over Teams, in English, and we hold the later slots for the people who are only free after a shift ends. Travelling to your site for the observation days is possible by agreement where you would rather have somebody in the room, and it is worth the cost more often than people expect.
On data, we work inside your tenant rather than moving your data to ours. Dataverse stays in the region you already chose for your environments, access is through accounts you create with least privilege and can revoke at any time, and where something has to be reproduced outside production we use masked or synthetic data. Every engagement carries a mutual NDA and a GDPR compliant data processing agreement, the AVG in Dutch terms, with IP ownership defined in the statement of work. Field Service holds personal data about your own technicians as well as your customers, so retention per table, audit log configuration and who can read technician location and timestamps are decisions we put on the table during scoping rather than at go live.
Commercially, engagements are B2B, either fixed price per milestone or time and materials, invoiced in euros. For a Dutch VAT registered business buying services from a supplier outside the EU the reverse charge normally applies, so we invoice without VAT and you account for it in your own return. Confirm that with your own adviser, since it depends on your registration and how the services are classified.
Already running Power Platform in the Netherlands and looking for ongoing support rather than a new build? That is a different service, described on our Netherlands Power Automate and Power Platform support page. For manufacturers in Germany, Austria and Switzerland, the DSGVO, works council and van stock specifics are covered on our Dynamics 365 for manufacturing page.
After the sprint
If you proceed, the rollout continues from the pilot rather than restarting. The solution built during the sprint is already managed and already moving through separate development, test and production environments, so the first increment of production is an extension of work you have seen rather than a new project with a new team. A typical shape is two or three senior engineers with one named lead who is in your steering call, working in your Azure DevOps or Jira, with dated milestones and acceptance criteria in the statement of work so progress is a demo rather than a status colour.
You are also free to take the sprint output elsewhere. The model, the data readiness note, the pilot solution and the estimate are yours, and they are written so another partner can execute them. We would rather be chosen on the strength of three weeks of real work than retain a client who has no alternative.
Where we are the wrong answer
A partner page that only lists strengths is not much use to somebody trying to choose. If field work is the entire business, the workflow is quote, schedule, do the job, invoice, get paid, and there is no CRM worth integrating with, a purpose built dispatch product will serve you better and faster than a platform will. If you need consultants physically on site every week, or a service desk answering in Dutch to people who will phone rather than raise a ticket, a local partner is the right call.
And if the work you need is on the Microsoft finance and ERP side, that is outside what we do at all. We stay on the Customer Engagement side of Dynamics 365 and on the Power Platform, and we would rather integrate cleanly with your ERP partner than claim ground we do not hold. Where we fit best is the middle of the market: a service organization with real assets, contracted maintenance and technicians who travel, that wants senior people on the model and the mobile app rather than a large team on a long plan.
Frequently Asked Questions
Are you a Dynamics 365 Field Service partner?
Yes. Solzet is a Microsoft Dynamics 365 Customer Engagement and Power Platform consultancy in Yerevan, Armenia, and Field Service is one of the modules we implement, alongside Sales, Customer Service and Customer Insights. We work directly with service organizations and white label underneath other Microsoft partners who need Field Service delivery capacity. Our engineers hold Microsoft certifications across Dynamics 365 and the Power Platform, including MB-240 for Field Service, and the reference build is our Field Service digitization case study for a European manufacturer.
Do you work as a Dynamics 365 Field Service partner in the Netherlands?
Yes. We deliver Field Service for Dutch service organizations remotely from Yerevan, and for Dutch Microsoft partners on a white label basis under their brand. Armenia is UTC+4 with no daylight saving, so we are three hours ahead of the Netherlands in winter and two in summer and our working day opens before yours, which means a Dutch morning question is answered the same morning. Projects run in English, contracts are B2B with a mutual NDA and a GDPR compliant data processing agreement, the AVG in Dutch terms, and invoicing is in euros. What we are not is a Dutch company or a Dutch language service desk, and the page above says so plainly.
What exactly is the feasibility sprint, and what do I get?
It is a fixed scope, fixed price engagement of roughly three weeks that answers whether Dynamics 365 Field Service fits your operation, using your data rather than a demo. You get a written description of your current process, your operation mapped onto the Field Service model with the mismatches named and costed, a data readiness note on your assets, addresses and skills, a pilot configured in a sandbox in your own tenant with a real slice of your data, a recorded offline run of a full job on a real device, and a rollout estimate and plan. Everything, including the solution, is handed over. If you continue with a different partner, the plan still works.
Why not just start the implementation?
Because the estimate everyone signs is produced at the moment of maximum ignorance, before anybody has opened your asset export or watched your dispatcher work a morning. The two things that most often stall a Field Service rollout, an asset and work order model that does not match the operation and a mobile app that fails without signal, are both knowable in three weeks and both very expensive to discover in month seven. If you already know your model and your data are sound, say so and we will skip the sprint and quote the build.
Can the Field Service mobile app really work offline?
Yes, and it is a design decision rather than a setting. The standard Field Service mobile app supports offline through an offline profile, and the work is in scoping that profile to what one technician needs for the next few days of work, filtering the assets, agreements, history, parts and price lists to the accounts on that route, and agreeing conflict rules for the fields two people can touch at once. We build the workflow so a job can be closed with no signal at all, including asset scan, service tasks, typed measurements, photographs, van stock consumption, customer signature and the service report, then queued for sync. Where the standard app cannot cover a case, we extend it with a Power Apps canvas app or a custom PCF control.
Can you take over a Field Service rollout that has already stalled?
Yes, and we treat it as a different engagement rather than as a sprint. It starts with an audit of the environment as it stands, what is configured, what is custom, what is load bearing and what is only risk, followed by a fixed scope reset. Our project rescue and takeover service covers the shape of that work, and our health check and technical audit is the assessment that usually comes first. Where the symptom is a schedule board that has become unusably slow, the health check page carries a specific diagnostic for it.
How does Field Service connect to the ERP we already run?
Field Service becomes the master of what a technician did, and your existing ERP stays the master of stock and value. We model each technician van as its own warehouse in Dataverse, synchronize the article master, serial numbers and price lists one way from the ERP, and post parts consumption back the other way when a work order closes, so a part used on a job decrements the van and creates the goods movement without anybody rekeying it. The posting is built to be idempotent and to survive a technician syncing two days late, and anything the ERP rejects lands in an exception queue with the reason attached. We do not implement the Microsoft finance and ERP products ourselves, which is exactly why we are careful about drawing that boundary early.
Do you work white label under another Microsoft partner?
Yes, and it is one of our core service lines. Our consultants work under your brand, in your Azure DevOps or Jira, inside your delivery process, and do not appear to your end client as a third party. For a partner who has won a Field Service project without the bench to staff it, that is usually two or three senior engineers with one named lead who joins your steering call. The commercial shape is a B2B subcontract with an NDA, a data processing agreement and IP ownership written into the statement of work.
Which industries do you deliver Field Service for?
Most of our Field Service work is industrial: equipment manufacturers servicing an installed base at customer sites, and organizations maintaining distributed plant and machinery under contract. The pattern that fits best is an operation with real assets, contracted maintenance and technicians who travel, rather than a pure dispatch business with no CRM behind it. If field work is the whole business and there is no customer record worth integrating with, a dedicated scheduling tool is often the better buy and our comparison page makes that argument honestly.
Start with a feasibility sprint
Tell us how many technicians you have, what they service, and what the schedule lives in today. We will come back with what we would put in the scope note, what the sprint would cost, and an honest read on whether Dynamics 365 Field Service is the right platform for you at all.
Already mid rollout and stuck? See our project rescue and takeover service and our health check and technical audit, which carries a diagnostic for a schedule board that has become unusably slow.