Hire Microsoft Dynamics 365 experts

Hire Microsoft Dynamics 365 Field Service consultants

In short

MS Dynamics Guys provides Microsoft Dynamics 365 Field Service consultants for dispatch, mobile and parts work. They configure work orders, scheduling, the mobile offline profile, parts and customer assets, then test them with your dispatchers and technicians in field acceptance scenarios. Your dispatch lead accepts each change after its field test, and your service manager sets the priorities. Custom code and ERP (enterprise resource planning) interface builds need other specialists, and we say which ones.

Scope Field Service capacity See project delivery

When a Field Service consultant from MS Dynamics Guys fits

A Field Service consultant turns your dispatch, parts and billing rules into configuration that technicians can trust at a customer site. The role fits when Field Service is live or in rollout, but nobody owns how it works for dispatchers and technicians. Typical signs:

Signs that the role fits

Dispatchers keep a side spreadsheet of skills, territories or customer promises, because the system does not hold them.
Technicians see blank screens or missing jobs when they lose signal, often after someone changed the offline profile.
Parts used from a truck do not reduce its stock, so the truck in the system no longer matches the real one.
Maintenance visits from an agreement create their own invoice, so customers are billed twice for one visit.
You are connecting Field Service to Business Central, and someone must own the Field Service settings and the field tests before go-live.

When another role or service fits better

The fix needs plug-ins, or offline JavaScript that runs on the device. That is work for a CRM (customer relationship management) developer.
Most of the work is building or repairing interfaces to other systems. An integration engineer or an integration project fits that work.
Years of work order and asset history must move from an old system. A data migration engineer owns that workstream.
You want one provider to answer for a whole Field Service rollout. That is a Field Service implementation project, not a hire.
Your open requests are about cases, queues and service levels, not field work. A Customer Service consultant fits better.
Your requests are mostly about the accounts, contacts and security that Field Service shares with Microsoft Dynamics 365 Sales or Customer Service. A CRM consultant owns that shared design, and a Field Service consultant can join for dispatch and mobile work.
Nobody on your side can decide dispatch rules, stock ownership or billing. A consultant can lay out the options, but your people must choose.

Work a Field Service consultant can own

Each row is an area that the consultant configures and tests. The last column names the decisions that stay with your people.

Field Service consultant work areas, what you receive and the decisions your team keeps
Area	What the consultant configures	What you receive	Decided by your team
Work orders and incident types	Work order types, and incident types that fill in service tasks, products, services, required skills and an estimated duration. Substatuses add detail without changing the system statuses.	An incident type specification for each common job	Your service manager: which jobs exist and what each one includes
Booking statuses	Booking statuses and the work order statuses they set, including a custom follow-up status with Status completes work order turned off. When a technician closes a work order's only booking with that status, the work order returns to Unscheduled for a return visit.	A status map with a test for each change of status	Your dispatch lead: what each status means to dispatchers and customers
Scheduling setup	Characteristics (skills) with rating levels, territories, working hours and schedule board settings for each dispatch team	A resource matrix: who can do which work, and where	Your dispatch lead: skills, territories and job priorities
Mobile app and offline profile	Technician forms and views, and changes to the default offline profile: tables, filters and sync intervals, moved between environments in a solution	A list of profile changes with a reason for each, and a device test plan	Your service manager: what technicians must see without signal
Parts and returns	A warehouse for each truck, linked to the technician's bookable resource so that used parts reduce the right truck. The Field Service Product Type of each part, because only Inventory products are tracked. Transfers, adjustments, purchase orders and returns through return merchandise authorizations (RMAs).	An inventory journal trace for each test transaction	Your inventory owner: which system owns stock
Customer assets	Asset categories, parent and child assets at functional locations, and which products become customer assets once a work order that used them is completed	An asset model and an import template	Your service manager and data owners: which equipment you track
Agreements	Booking setups that generate maintenance work orders, invoice setups, whether agreements copy each incident type's items, and the rule that bills each visit once	An agreement setup sheet with its billing rule	Your finance lead: which document bills the customer
Security roles	Copies of the standard roles Field Service - Dispatcher, Field Service - Resource and Field Service - Inventory Purchase, with the column security profiles each job needs. Technicians also need the Field Service - Resource column security profile to sign in to the mobile app.	A role and profile matrix that names the standard role behind each copy, with a schedule board or device test for each job	Your administrator assigns roles, and data owners approve access
The Field Service side of ERP interfaces	Settings, product types and warehouses that match the ERP design, and a written requirement for each interface	An ownership table and interface requirements	Your finance and system owners: the system of record for each item

Microsoft's guidance shapes three habits. Standard choice values, system statuses and security roles stay unchanged, because a customized layer hides Microsoft's later changes to that component. Offline work builds on the default offline profile, as Microsoft recommends. Profile changes start in development and move to other environments in a solution. Publishing a profile change creates an active solution layer. The consultant therefore agrees with your administrator which environments allow profile edits. Setting up those environments and the pipeline that moves solutions between them is work for your administrator or a technical consultant.

Microsoft also updates the default offline profile as part of Field Service updates. A sync filter that you edited no longer receives these updates. Updates to the other filters wait unpublished until an administrator applies them. The consultant therefore keeps a list of edited filters to check after each update.

The consultant tests each copied role where the job happens. A dispatcher's test user works on the schedule board, and a technician's test user works in the mobile app. Without the minimum schedule board privileges, a dispatcher might see errors or a blank schedule board. Access rules that Microsoft Dynamics 365 Sales and Customer Service share, such as who sees which accounts, belong to a CRM consultant.

Some work orders start from a case. When a dispatcher converts the case, its incident type becomes the work order's primary incident type. That incident type fills in the service tasks, products and services. The case process before that point belongs to a Customer Service consultant. The Field Service consultant owns the incident types and the work order that follows. If a CRM consultant designs the whole handoff across both apps, name in your role brief the one person who configures the incident types.

Microsoft's refreshed mobile experience does not currently support offline work. If your technicians lose signal, the consultant settles which mobile experience each group uses before rollout.

The role covers Field Service in the online service. Resource Scheduling Optimization, a separately licensed add-in for automated scheduling, is outside the standard role. If you use it, we confirm that experience for each candidate.

Can the consultant connect Field Service to Business Central or Microsoft Dynamics 365 Finance?

The consultant owns the Field Service side of the connection and prepares the decisions behind it. Microsoft provides integrations for Business Central and for Microsoft Dynamics 365 Finance and Supply Chain Management, and those are set up rather than built. Other ERP systems need a custom interface, which an integration engineer builds, monitors and reconciles. In both cases, the consultant first settles four questions with your finance and inventory owners:

Prices. Does Field Service or the ERP system price products and services?
Stock. Which system holds stock levels, including the stock on each truck?
Billing. Which document bills the customer for a visit: a work order invoice, an agreement invoice or an ERP invoice?
Failures. Who sees and fixes a visit that did not reach the ERP system, and how are the two systems reconciled?

The answers become an ownership table and a written requirement for each data flow. The consultant then tests one visit from booking to posting in the ERP system.

For a custom interface, MS Dynamics Guys can add the engineer to the same workstream: see integration engineers.

Business Central

Microsoft's Field Service Integration app for Business Central needs the Business Central connection to Dataverse and the integration with Microsoft Dynamics 365 Sales. Its Project option sends work order products and services to project journal lines in Business Central. Its Project and Service option also links work orders with service orders, and it needs the Business Central Premium experience.

In both options, Business Central prices and invoices the work. The setup turns off Calculate Price and Calculate Cost in Field Service and sets Work Order Invoice Creation to Never. It also clears Use of Products Out of Stock, so users get no out-of-stock warning for parts that Business Central still holds. The setup also decides when work order lines reach Business Central: when they are used, or when the work order is complete.

The Business Central Virtual Table app is optional. You need it only if technicians should see Business Central item availability in Field Service. Virtual tables also require Field Service and Business Central in the same tenant.

The Business Central side, such as projects, journals and posting setup, belongs to a Business Central consultant. MS Dynamics Guys can add one to the same team.

Microsoft Dynamics 365 Finance and Supply Chain Management

If you run Finance and Supply Chain Management, plan for a change. Microsoft's Field Service integration with finance and operations apps is unavailable after February 28, 2027. Since Field Service release 8.8.139.398, environments that do not already use it cannot install it. Environments that use it can keep it until that date.

The capability moves to the Field Service integration with Microsoft Dynamics 365 Project Operations. Each work order links to a project, which holds its costs, revenue and billing. Companies with Finance and Supply Chain Management can use it without working in the Project Operations app. Field Service includes a small set of Project Operations forms for them. Microsoft's setup still requires Project Operations in the environment, and the user who installs the integration needs a Project Operations license.

Microsoft's setup steps say to uninstall the old integration before you set up the new one. The two integrations therefore do not run side by side, so plan a cutover date before February 28, 2027.

The consultant owns the Field Service side of that move. That covers which work orders link to projects and how products and services are set up. The integration package also installs its own offline profiles. They are active even while the integration is turned off, and they override the default profiles. The consultant compares them with your profile changes, then runs field tests of used parts and time entries.

MS Dynamics Guys can add a consultant for the Project Operations side: see Project Operations consultants.

What experience matters for dispatch and mobile work?

Experience shows in how a consultant handles failure: a job nobody can take, a visit closed without signal, a part that comes back. Before you meet a candidate, a reviewer from MS Dynamics Guys gives them five written scenarios. The candidate explains each fix and the evidence behind it.

Field Service consultant assessment: the skill, the scenario and the evidence you receive
Skill	Scenario the candidate works through	Evidence you receive
Work order lifecycle	A work order moves from Unscheduled to Posted, and one visit needs a return trip	A status map and the follow-up booking status the candidate would add
Scheduling	An urgent job needs one skill in one territory, and the schedule assistant finds nobody	The corrected characteristic, territory or duration, with the reason
Mobile offline	After an offline profile change, a technician closes a visit without signal and reports blank screens	The profile defects found, and a test plan for real devices
Parts	A technician uses a part from truck stock, and the customer later returns it through an RMA	An inventory journal trace from use to return
ERP boundary	A maintenance visit from an agreement is posted while the ERP system also invoices the customer	An ownership table that names one invoice source

Before your interview, you receive the reviewer's written summary of the five scenarios. It notes what the candidate found in the offline profile, how they traced the returned part and which answers your dispatch lead should probe. How we assess specialists explains how reviewers score against written criteria, and what no scenario can show.

Our scenarios use an invented service company. Your interview tests the candidate on your own territories, parts and devices. Take one job that your dispatchers struggled to place last month, and remove customer names and addresses first. Ask the candidate why the schedule assistant could not place it, and which setting they would check first. Then let a technician describe a visit that failed without signal, and note whether the candidate asks about the offline profile.

Example first work package: preventive maintenance in one territory

Illustrative example: not a client case and not a delivery-time promise

A company services heating systems in commercial buildings. It wants preventive maintenance in one territory to run from Field Service agreements. Its technicians often work in basements without signal. It brings in one consultant for a bounded first package.

Scope. One territory, one maintenance agreement, the incident type for the inspection visit and the offline profile for that territory's technicians. All configuration happens outside production first.

Artifacts the consultant delivers:

Incident type specifications: service tasks, products, services, required skills and duration.
The agreement setup: visit recurrence, incident items and the billing rule that finance chose.
A booking status map, with a follow-up status for visits that need a return trip.
Offline profile changes in a solution, with each table and filter change listed.
Field scripts for dispatchers and technicians, and a defect log.

Acceptance. Technicians pass every script on their own devices in the test environment, including a visit closed without signal. Each test visit bills the customer exactly once. No standard status value or security role was changed. The dispatch lead signs the results.

The heating company is invented for this page. It describes no client and promises no duration. Planning similar work? Describe the Field Service role you need.

Engagement choice: who directs the consultant's work

Each model answers two questions differently: who plans the consultant's week, and who is accountable for the result.

Who plans a Field Service consultant's week, and who answers for the result, in each engagement model
Option	Who directs the work	What MS Dynamics Guys answers for	Fits when
One consultant in your service team (staff augmentation)	Your service manager, through your backlog and dispatch meetings	The consultant's skills and conduct, and continuity under the agreement	You can set priorities and accept changes, and one functional role is missing

Working hours, overlap with your dispatch day, notice, minimum term and replacement are set in the written agreement for each engagement. Staff augmentation versus project delivery compares the models by responsibility and pricing basis.

How work starts, from your brief to the first field test

We give no shortlist date or start date in advance. The search for candidates and their five scenarios take as long as the role requires. After an introduction, your interview, your access setup and your technicians' time for field tests set the pace.

Your role brief
List your Field Service licenses, including Resource Scheduling Optimization if you have it. Add your technicians' devices, your ERP system, the process that fails today and who will direct the work.
Fit review
We read your licenses, devices and the process that fails. We check which mobile experience your technicians use, and whether the fix needs configuration, code, interface work or a whole project. Before any introduction, we confirm in writing whether we can staff the role.
Assessed candidates, with consent
Profiles reach you only for candidates who passed the five field scenarios and agreed to share them. Give each reviewer's summary to your dispatch lead and to the technician who will join the interview.
Your interview
Your dispatch lead and one technician interview each candidate. Use the job and the failed visit described in the assessment section, with customer data removed. You decide who joins.
Agreement in writing
It sets responsibilities, hours, overlap, term, notice, replacement, confidentiality and ownership of configuration and documents. Field tests run on your technicians' devices, so it also names who provides the test devices and which data they may download. Access starts only after signature.
Access, test environment first
Your administrator gives the consultant a named account with only the Field Service roles the work needs. The consultant reads the current setup before changing anything.
First field-tested change
One small change, such as a corrected booking status. It is built outside production, run by a technician on a device and accepted by your dispatch lead.

Before the start date, we agree a written onboarding checklist with your lead. It names the accounts, the environments, the technicians and devices for field tests, and the first work item with its field script. If the consultant signs in as a guest, the guest account also needs a license and a security role from your tenant.

The onboarding checklist for external specialists lists every step, including exit.

What does a Field Service consultant from MS Dynamics Guys need from our dispatchers and technicians?

Four inputs from your side, agreed before the first task. Without them, a consultant can still configure, but nobody can prove that the result works in the field.

A test environment. It runs the same solutions as production, with test data that looks like a normal week: accounts, assets, products, resources and open work orders.
Dispatch rules. Your dispatch lead explains skills, territories, job priorities and promised time windows, in writing or in a short session.
Technicians with their devices. Two or three technicians run the field scenarios on the phones or tablets they use at work, including one session without signal.
ERP decisions. Your finance and inventory owners name the system that prices, the system that holds stock and the document that bills each visit.

Your administrator also sets up two test users in the test environment: a dispatcher, and a technician created as a frontline worker. Microsoft's setup form makes that technician a bookable resource and assigns the offline profile under test. The default profile downloads only a user's active bookings that start or end today or in the next seven days. Your dispatch lead schedules test bookings inside that window. Production rights follow only where your release process requires them.

What field acceptance looks like: four demonstration scripts you can check

This page shows no client names, reviews, case studies or consultant profiles.

You can check the method instead. How we assess specialists describes the review process and its limits. A buyer scorecard for Microsoft Dynamics 365 specialists lets you rate candidates from any provider against one rubric. The table below is an original demonstration written for this page. It shows the kind of field scripts a consultant writes with your dispatch lead.

Demonstration, not a client's tests: four field acceptance scripts for a maintenance visit
Script	What the tester does	Passes when
Visit closed without signal	A technician downloads the day's bookings, turns off the network, completes a visit and records a used part, then reconnects	After the sync, the booking and work order show the expected statuses, the truck shows one part less and the app reports no sync errors
Return visit	A technician completes the work order's only booking with the follow-up status, because a part is missing	The work order shows Unscheduled instead of Completed, and a dispatcher can book the return visit
Part returned	An inventory clerk creates an RMA for a faulty part, with return to warehouse, and records its receipt	The part is back in the chosen warehouse, and the inventory journals show both the use and the return
Agreement visit billed once	A back-office user posts a completed visit that a maintenance agreement generated	The customer is billed once, through the document finance chose; any work order invoice is zero or deactivated

The scripts describe no client system and no candidate's work. In the assessment, candidates explain checks like these. In your team, the consultant writes them for your own processes.

Field Service consultant questions from service managers

Do we need a Field Service consultant or a CRM developer?

Often both, with a written line between them. Field Service runs on Microsoft Dataverse, like Microsoft Dynamics 365 Sales and Customer Service. Much of it changes through configuration: incident types, booking statuses, offline filters and security roles. The consultant owns that work and tries standard features before anyone asks for code.

Logic that configuration cannot express goes to a developer. One example is a rule that must run on the device without signal. Microsoft recommends offline JavaScript for that, because Power Automate flows run only when the device is connected or at the next sync. The consultant hands the rule to the developer with its acceptance test: a field script that a technician runs on a device without signal.

MS Dynamics Guys can add that developer to the same backlog: see CRM developers.

How do you test offline work before technicians rely on it?

On real devices, before any release. The consultant writes field scripts with your dispatch lead, like the demonstration above. Your technicians run them on their own phones or tablets against a test environment. Before those runs, the consultant checks the profile itself:

Every lookup table that a profile filter uses is in the profile. A missing table makes the related data unavailable offline and can leave technicians with errors or blank screens.
Tables that cannot be used offline, such as purchase orders, agreements and RMAs, stay out of the profile. The people who handle them work online.
Filters download only the records that the coming days need, not all records, so each sync stays short.

Inventory validation does not run without a connection, so one script uses a part that the truck no longer holds. Your dispatch lead signs the results before the profile changes reach production in a managed solution.

Which decisions stay with our dispatchers and finance team?

Decisions that change how your business runs or what customers pay. Your dispatch lead decides skills, territories, job priorities and what each booking status means. Your finance and inventory owners decide which system prices, holds stock and bills each visit. Your service manager and finance lead decide who reviews a completed work order and sets it to Posted. Depending on your Field Service settings, that status creates the invoice for used products and services. When dispatch and finance want different rules, the consultant writes down both options and their effects. The owner named in your role brief decides, and the consultant configures and tests only that option.

Our technicians start before office hours. Can the consultant support them after a release?

Only for hours agreed in writing before the engagement starts. The first problems after a release often appear when technicians start their day. Name your dispatch hours, your time zone and any go-live dates in the role brief. The agreement then sets the consultant's working hours, the overlap with your team and any support at shift start. Plan each release for a time those hours cover, and name who on your side answers technicians' questions.

Who checks the offline profile after each Field Service update once the consultant has left?

Your administrator, with the change list that the consultant leaves in your workspace. Field Service updates can change the default offline profile. A sync filter that you edited receives no update. Updates to the filters you did not edit arrive unpublished, and an administrator decides whether to apply them. The change list names each edited table and filter, the reason for the change and the field script that proves it. After each update, your administrator reviews the waiting changes in the test environment. A technician then runs the script for a visit closed without signal before the changes reach production. Before a planned exit, the consultant runs this check once with your administrator. Ownership of configuration and documents, notice and replacement are set in the written agreement.

Do field tests and go-live support change what we pay?

They change the hours, and the hours drive the cost. The consultant's time is paid on a rate basis agreed in writing for each engagement, and this site publishes no rates. Workshops with dispatchers, field tests with technicians and any support at shift start all take agreed hours. Your technicians' time and their devices come from your side. Microsoft licenses are separate purchases. They include Field Service licenses for your users and a license for the consultant's account in your tenant. Resource Scheduling Optimization needs its own license, only if you choose that add-in.

Scope Field Service capacity

Tell us your Field Service licenses, your technicians' devices, your ERP system, the process that fails today and who will direct the work. Before any introduction, we reply with whether we can staff the role and what we need from your team.