Ellipse Gradient for Header
Dynamics 365 Field Service logo

Dynamics 365 Field Service Integration Guide

Integrate Dynamics 365 Field Service with enterprise systems through the Microsoft Dataverse Web API, OAuth 2.0, configured webhooks, change tracking, and workflow orchestration.

Dynamics 365 Field Service integration options at a glance

Dynamics 365 Field Service uses the Microsoft Dataverse Web API, an OData v4 REST interface, for transactional access to Work Orders, Bookable Resource Bookings, Customer Assets, Accounts, Contacts, Products, and related tables. Microsoft Entra ID OAuth 2.0 supports delegated and unattended application access. Dataverse also provides configured webhook notifications, change tracking for incremental synchronization, batch and selected bulk operations, and file or attachment APIs. A read-only TDS endpoint is available for analytics in supported environments, but not for transactional writes. Martini can consume these interfaces, expose APIs for upstream systems, orchestrate workflows, map relationships and business rules, and apply retry and monitoring controls.

Integration pointSupported by Dynamics 365 Field Service?Common use casesHow Martini supports it
Dataverse Web API / OData v4 REST APIsYesCreate, retrieve, update, delete, associate, and query Work Orders, Bookable Resource Bookings, Customer Assets, Accounts, Contacts, Products, Incidents, and related tables.Martini can consume the REST API from workflows, generate reusable integration assets from API definitions where applicable, map JSON payloads, and expose APIs for upstream systems.
AuthenticationYesAuthenticate delegated or unattended integrations with Microsoft Entra ID OAuth 2.0, application registrations, service principals, and Dataverse application users.Martini can store environment-specific credentials and secrets securely and use configured OAuth 2.0 API authentication for workflow calls.
Webhooks / outbound callbacksLimitedNotify an external HTTP endpoint when selected Dataverse table and pipeline events occur. Coverage depends on registered tables, messages, and configuration.Martini can receive webhook notifications, validate the request, retrieve the authoritative row through the Web API, and handle duplicate or failed deliveries.
Change trackingYesRetrieve changes to supported tables such as Work Orders, Customer Assets, Accounts, Contacts, Products, and Bookable Resource Bookings using a synchronization token or delta link.Martini can run scheduled workflows, persist synchronization state, process incremental changes, and initiate resynchronization when tokens expire.
Batch, bulk, and asynchronous operationsYesUse $batch requests, change sets, selected CreateMultiple, UpdateMultiple, and UpsertMultiple messages, and selected asynchronous platform operations.Martini can group independent API operations, coordinate transactional changes where appropriate, and apply bounded retries without assuming batching removes service protection limits.
File and attachment APIsYesExchange content stored in Dataverse file columns, Notes or Annotation records, ActivityMimeAttachment records, and related document structures.Martini can route files and metadata through workflows, but the implementation must first identify the specific Field Service table and storage model.
Database / analytics accessLimitedUse the read-only Dataverse TDS endpoint for SQL-style analytics in supported environments and configurations.Martini can connect to supported database or analytics endpoints where appropriate, while transactional Field Service writes remain on the Dataverse Web API.

How Dynamics 365 Field Service exposes data and business events

Dynamics 365 Field Service REST APIs

The Dataverse Web API is the primary integration interface for Dynamics 365 Field Service. It exposes OData v4 operations for querying and modifying Field Service and related Dataverse tables, including relationships, functions, actions, and alternate-key scenarios.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates with Microsoft Entra ID, calls the Dataverse Web API, follows pagination links, resolves related table references, maps the response into a canonical model, and writes the result to downstream systems or returns it through a Martini API.

Implementation sequence

Authenticate with Microsoft Entra ID OAuth 2.0
Receive or retrieve the source payload
Query Dataverse metadata and related references where required
Create, update, associate, or retrieve the Field Service row
Map the result to the target system
Persist identifiers and processing status

Dynamics 365 Field Service Webhooks

Dataverse supports webhook registrations that send HTTP POST notifications for selected table and pipeline events. These notifications provide configured event coverage rather than a universal stream of every Field Service action.

Martini implementation pattern

Martini implementation pattern: expose a receiving endpoint or workflow trigger, validate the incoming notification, identify the changed table and row, retrieve the current authoritative data through the Dataverse Web API, and process repeated or failed notifications safely.

Implementation sequence

Receive the Dataverse webhook notification
Validate the request and identify the changed row
Retrieve the current row from the Web API
Apply business rules and map related data
Write the downstream result
Record completion or route the failure for retry

Dynamics 365 Field Service Change Tracking

Dataverse change tracking can return changes since a prior synchronization token for supported tables. This is useful for incremental synchronization of Work Orders, Customer Assets, Accounts, Contacts, Products, and Bookable Resource Bookings.

Martini implementation pattern

Martini implementation pattern: run a scheduled workflow that submits the stored token or delta link, processes each page of changes, handles creates, updates, and deletes according to business rules, and commits the new synchronization state only after successful processing.

Implementation sequence

Start the scheduled synchronization workflow
Submit the stored change-tracking token
Follow returned pagination links
Map and process each change
Handle deletes and inactive records
Persist the new token after successful completion

Dynamics 365 Field Service Batch and File APIs

Dataverse supports batch requests, change sets, selected bulk operations, file columns, Notes, and activity attachments. The applicable operation depends on the table, column, message, and storage model.

Martini implementation pattern

Martini implementation pattern: classify each operation, construct the appropriate Dataverse request, use batch or bulk processing for compatible workloads, stream or map file content through the correct endpoint, and handle partial failures at the operation level.

Implementation sequence

Classify the target operation and storage model
Build the batch, bulk, or file request
Submit the request through the Web API
Inspect individual operation results
Retry transient failures within bounded limits
Record successful identifiers and unresolved errors

Common Dynamics 365 Field Service integration patterns

Pattern 1: Synchronize Work Orders with an ERP

When to use this pattern

Use this pattern when an ERP or service-management application creates service requests that must become Dynamics 365 Field Service Work Orders. The flow should resolve customer, asset, product, and Incident references before writing the Work Order and should remain safe when the source retries a request.

Integration direction
ERP
Martini
Dynamics 365 Field Service
Example Mapping
Dynamics 365 Field Service FieldCanonical FieldTarget Field
sourceWorkOrderNumberserviceOrder.externalIdmsdyn_workorder.source identifier
customerIdcustomer.externalIdmsdyn_workorder.msdyn_serviceaccount
assetSerialNumberasset.serialNumbermsdyn_workorder.msdyn_customerasset
requestedServiceDateservice.requestedStartmsdyn_workorder.msdyn_datewindowstart
Martini implementation pattern

Martini receives an API request or scheduled source record, looks up related Dataverse rows, applies validation and status rules, then performs an idempotent create or update. It returns the Dataverse identifier and routes throttling, relationship, or validation failures through bounded retries and operational logging.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • business rules
  • error handling

Pattern 2: Synchronize scheduling and resource bookings

When to use this pattern

Use this pattern when Field Service scheduling must be coordinated with a workforce, dispatch, or external mobile application. Bookings should be processed together with their Work Order, Resource Requirement, resource, status, and time-zone context rather than as standalone rows.

Integration direction
Dynamics 365 Field Service
Martini
Workforce scheduling application
Example Mapping
Dynamics 365 Field Service FieldCanonical FieldTarget Field
bookingStatusassignment.statusexternalBooking.status
scheduledStartassignment.startTimeexternalBooking.start
scheduledEndassignment.endTimeexternalBooking.end
resourceassignment.resourceIdexternalBooking.technicianId
Martini implementation pattern

A webhook or scheduled workflow retrieves the current booking and related requirements, normalizes timestamps, maps the assignment to the target application, and synchronizes status changes in the required direction. Martini stores source identifiers and applies duplicate prevention when a booking is retried.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • business rules
  • error handling

Pattern 3: Synchronize Customer Assets and installed equipment

When to use this pattern

Use this pattern when an ERP, manufacturing platform, or asset-management application owns installed-equipment data that must be available to Field Service technicians. It is suitable for initial loads and incremental updates.

Integration direction
Asset management system
Martini
Dynamics 365 Field Service
Example Mapping
Dynamics 365 Field Service FieldCanonical FieldTarget Field
equipmentNumberasset.externalIdmsdyn_customerasset.asset identifier
serialNumberasset.serialNumbermsdyn_customerasset.msdyn_serialnumber
productCodeasset.productIdmsdyn_customerasset.msdyn_product
customerNumberasset.accountIdmsdyn_customerasset.msdyn_account
Martini implementation pattern

Martini consumes source asset data, resolves the Account and Product, maps serial number and location information, and upserts the Customer Asset using an alternate key or source identifier where configured. Failed relationship resolution is held for retry rather than creating incomplete assets.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • business rules
  • error handling

Pattern 4: Process selected Work Order events

When to use this pattern

Use this pattern when downstream systems need timely notification of selected Work Order, Booking, or Customer Asset changes. It is appropriate when Dataverse webhook registrations can cover the required table and pipeline events.

Integration direction
Dynamics 365 Field Service
Martini
ServiceNow
Example Mapping
Dynamics 365 Field Service FieldCanonical FieldTarget Field
msdyn_workorderidserviceOrder.idincident.externalReference
msdyn_systemstatusserviceOrder.statusincident.state
msdyn_customerassetasset.idconfigurationItem.externalReference
msdyn_priorityserviceOrder.priorityincident.priority
Martini implementation pattern

Martini receives the lightweight Dataverse notification, validates it, retrieves the current row and related data, and maps the authoritative state to the downstream system. It treats delivery as repeatable, records event identifiers, and retries transient downstream failures without assuming webhook coverage for every Field Service event.

Martini capabilities used
  • API exposure
  • webhook consumption
  • workflows
  • data mapping
  • business rules
  • error handling

Applications commonly integrated with Dynamics 365 Field Service

Dynamics 365 Field Service is commonly connected with Microsoft business applications, operational platforms, ERP systems, and analytics services. Martini can coordinate these flows through the Dataverse Web API, configured notifications, scheduled workflows, and reusable mappings while preserving relationships between service, customer, asset, product, and scheduling data.

Application Scenario Direction Martini Pattern
Dynamics 365 Sales Synchronize Accounts, Contacts, customer relationships, opportunities, and service context between sales and field operations. Dynamics 365 Sales → Martini → Dynamics 365 Field Service Use Dataverse API workflows to resolve shared Accounts and Contacts, map sales context to Field Service tables, and return service status or history to Sales. Apply upsert and relationship validation rules.
Dynamics 365 Customer Service Coordinate cases, entitlements, customer communications, and Work Orders created from service requests. Dynamics 365 Customer Service → Martini → Dynamics 365 Field Service Receive or schedule case-related data, resolve the customer and Incident references, create or update Work Orders, and synchronize completion or status information back through Dataverse APIs.
Dynamics 365 Finance Exchange customers, products, inventory, pricing, billing, and financial status associated with completed service work. Dynamics 365 Finance → Martini → Dynamics 365 Field Service Orchestrate master-data and service-completion workflows, map product and customer identifiers, validate related Dataverse rows, and route failures for retry or review.
Dynamics 365 Supply Chain Management Synchronize parts availability, warehouses, inventory transactions, and replenishment for field technicians. Dynamics 365 Supply Chain Management → Martini → Dynamics 365 Field Service Use scheduled or API-triggered workflows to exchange product and inventory data, map part references, and apply business rules before updating Field Service-related records.
Azure IoT Hub Convert equipment telemetry or IoT alerts into service incidents or Work Orders and return service status to operational monitoring. Azure IoT Hub → Martini → Dynamics 365 Field Service Receive IoT-originated requests through an API, identify the Account and Customer Asset, classify the issue through an Incident, and create or update a Work Order with duplicate detection.
SAP S/4HANA Exchange customer, product, equipment, inventory, and service-completion information with a non-Microsoft ERP. SAP S/4HANA → Martini → Dynamics 365 Field Service Consume the relevant SAP APIs and Dataverse endpoints in a Martini workflow, maintain canonical identifiers, resolve lookups, and use bounded retries for transient failures.
ServiceNow Coordinate incidents, requests, asset information, and field-service execution across IT and operational service teams. ServiceNow → Martini → Dynamics 365 Field Service Use ServiceNow API requests or notifications to initiate workflows, map incidents and assets to Field Service Work Orders and Customer Assets, and synchronize status changes with idempotent updates.
Power BI Analyze Work Orders, Bookings, Customer Assets, technician activity, and service outcomes. Dynamics 365 Field Service → Martini → Power BI Use scheduled extraction through Dataverse APIs or supported analytics access, shape service data into a reporting model, and publish validated datasets or downstream API payloads.

How to build a Dynamics 365 Field Service integration in Martini

Objective

Establish access to the appropriate Dataverse environment using Microsoft Entra ID OAuth 2.0 and an application user or delegated identity with the required table privileges.

Instructions in Martini

  • Configure the environment-specific Dataverse resource URL.
  • Store client credentials and tokens in Martini secrets.
  • Use a service principal and Dataverse application user for unattended processing.
  • Validate create, read, write, delete, append, and append-to privileges required by the workflow.

Objective

Select the trigger that matches the integration requirement: an exposed Martini API, a configured Dataverse webhook, or a scheduled workflow using change tracking or regular queries.

Instructions in Martini

  • Use an API trigger for synchronous submissions.
  • Use a webhook trigger only for registered Dataverse events.
  • Use a scheduler for incremental or reconciliation workflows.
  • Define the expected event, polling, and replay behavior.

Objective

Retrieve authoritative Dataverse data, including related rows and pages of results, rather than relying on a lightweight notification or a single response page.

Instructions in Martini

  • Follow @odata.nextLink values.
  • Use filtered queries and $select where practical.
  • Resolve Account, Contact, Customer Asset, Product, Incident, Resource Requirement, and resource references.
  • Persist change-tracking tokens or delta links after successful processing.

Objective

Coordinate API calls, relationship resolution, transformations, business rules, target writes, and response handling in a maintainable Martini workflow.

Instructions in Martini

  • Separate retrieval, validation, mapping, and target-writing stages.
  • Use reusable services or workflows for common Dataverse lookups.
  • Handle synchronous and asynchronous operations according to business requirements.
  • Keep environment-specific identifiers outside core workflow logic.

Objective

Convert Dataverse JSON, choice values, lookup references, timestamps, and file metadata into the target system's canonical model.

Instructions in Martini

  • Map actual Field Service table and attribute names.
  • Normalize scheduling timestamps and time-zone semantics.
  • Translate status and choice values using configured mappings.
  • Handle file columns, Notes, and activity attachments according to their storage model.

Objective

Validate relationships, ownership, status transitions, required fields, duplicate controls, and source-system identifiers before writing data.

Instructions in Martini

  • Use alternate keys or lookup-based upsert patterns where appropriate.
  • Reject or hold incomplete relationships for controlled retry.
  • Account for Dataverse plug-ins, business rules, calculated values, and server-side workflows.
  • Define explicit handling for inactive, cancelled, retired, and deleted records.

Common Dynamics 365 Field Service data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
Work OrdersRepresent service work to be performed for a customer, asset, or location.ERP, Dynamics 365 Customer Service, ServiceNow, mobile workforce applications, reporting platformsMartini resolves related Accounts, Contacts, Customer Assets, Incidents, Products, and Resource Requirements before creating or updating the Work Order. It applies source identifiers, upsert rules, validation, and retry handling.
Bookable Resource BookingsRepresent scheduled assignments of resources to Work Orders or other schedulable requirements.Workforce scheduling platforms, mobile applications, dispatch systems, reporting platformsMartini maps resource, requirement, status, and time fields, preserves relationships to Work Orders and resources, normalizes time zones, and prevents duplicate bookings.
Customer AssetsRepresent equipment or assets installed at a customer location and serviced by the organization.ERP, asset-management platforms, Azure IoT Hub, Dynamics 365 Sales, reporting platformsMartini synchronizes product, serial-number, location, account, contact, and status data using alternate keys or source identifiers where available.
IncidentsRepresent standardized service issue types or work-order templates used to classify and generate work.Dynamics 365 Customer Service, IoT platforms, service portals, reporting platformsMartini maps source issue classifications to valid Incident references, validates active values, and uses the selected Incident when creating or enriching Work Orders.
AccountsRepresent commercial customers or organizations associated with service activity.Dynamics 365 Sales, Dynamics 365 Finance, SAP S/4HANA, ServiceNowMartini uses account identifiers and alternate keys where configured, resolves lookup relationships, and applies duplicate-detection and ownership rules.
ProductsRepresent parts, materials, or services used in Field Service processes.Dynamics 365 Finance, Dynamics 365 Supply Chain Management, SAP S/4HANA, inventory systemsMartini synchronizes product identifiers and attributes, validates references before Work Order processing, and coordinates inventory-related mappings.

Authentication and security considerations

Microsoft Entra ID OAuth 2.0

Dynamics 365 Field Service data is generally accessed through the Dataverse Web API with Microsoft Entra ID OAuth 2.0. Delegated authorization is suitable for user-context scenarios, while client credentials with a service principal and Dataverse application user is commonly used for unattended workflows.

Dataverse privileges

Access is also controlled by Dataverse security roles, business units, teams, users, and table privileges. The application identity should receive only the create, read, write, delete, append, and append-to permissions required by the integration.

Martini configuration

Martini can keep client credentials, environment URLs, scopes, and other sensitive configuration in secrets and environment-specific settings. API exposure should be protected with the authentication and authorization controls appropriate to the receiving workflow.

Operational considerations for Dynamics 365 Field Service integrations

Throttling and pagination

Dataverse applies service protection limits and paginates list responses. Workflows should follow next links, use filtered queries and selective columns, respect HTTP 429 responses and retry-after information, and apply bounded exponential backoff.

Idempotency and relationships

Retries can create duplicate Work Orders, Bookings, or Customer Assets unless source identifiers, alternate keys, lookup checks, or upsert patterns are used. Related Accounts, Contacts, Products, Incidents, resources, and requirements should be resolved before writes.

Schema and server-side behavior

Dataverse solutions can change tables, columns, choices, relationships, plug-ins, business rules, and calculated values. Validate metadata and mappings across environments, and test the complete server-side behavior rather than assuming an update affects only submitted fields.

Events, files, and scheduling

Webhook notifications are selected event signals and may be repeated or followed by a changed or deleted row. File columns, Notes, and activity attachments use different API patterns. Scheduling integrations should preserve time-zone semantics, daylight-saving behavior, cancellations, and inactive records.

Why use Martini instead of scripts or point-to-point integrations?

Orchestrate more than an API call

Point-to-point scripts often combine authentication, pagination, lookup resolution, transformation, retries, and monitoring in code that is difficult to reuse. Martini organizes these concerns into workflows and APIs that can be maintained as integration assets.

Keep business logic explicit

Martini can apply validation, relationship resolution, canonical mappings, duplicate controls, status rules, and conditional routing between Dataverse and enterprise applications. Custom logic can be added when a standard transformation is insufficient.

Improve operational reliability

Reusable error handling, bounded retries, logging, scheduled reconciliation, webhook processing, and environment-specific secrets help integrations remain observable and manageable as Field Service customizations evolve.

Frequently asked questions

How can Dynamics 365 Field Service be integrated with enterprise systems?

Dynamics 365 Field Service is integrated primarily through the Microsoft Dataverse Web API, an OData v4 REST API. Enterprise workflows can create, query, update, associate, and synchronize Work Orders, Bookable Resource Bookings, Customer Assets, Accounts, Contacts, Products, and related tables. Dataverse also supports configured webhook notifications, change tracking, batch operations, and file or attachment APIs.

Can Martini integrate with Dynamics 365 Field Service?

Yes. Martini can consume the Dynamics 365 Field Service Dataverse REST API using Microsoft Entra ID OAuth 2.0, receive configured Dataverse webhook notifications, run scheduled change-tracking workflows, map related Dataverse tables, and expose APIs for systems that need to submit or query Field Service data.

Do I need a connector to integrate Dynamics 365 Field Service with Martini?

No. A dedicated Dynamics 365 Field Service connector is not required. Martini can integrate using the vendor's confirmed native mechanisms, including the Dataverse Web API, Microsoft Entra ID OAuth 2.0, configured webhooks, change tracking, batch operations, and file or attachment APIs.

Is there any extra Lonti cost to integrate Dynamics 365 Field Service with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Dynamics 365 Field Service. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Microsoft, Dataverse, Azure, infrastructure, or other third-party systems depending on licensing, API usage, and deployment model.

Which API should Martini use for Dynamics 365 Field Service?

The recommended interface is the Microsoft Dataverse Web API used by Dynamics 365 Field Service. It is an OData v4 REST API for table operations, relationships, queries, functions, actions, and selected bulk scenarios. The read-only Dataverse TDS endpoint is intended for analytics rather than transactional integration.

Are webhooks or events available for Dynamics 365 Field Service?

Dataverse supports webhook registrations for selected table and pipeline events. Martini can receive these HTTP notifications, but coverage depends on the registered table, message, and environment configuration; they should not be treated as a universal stream of every Field Service event. The notification should normally be followed by a Web API retrieval.

How does Martini synchronize changed Field Service data?

Where change tracking is enabled and supported, a Martini scheduled workflow can submit a stored synchronization token or delta link and process only changes to tables such as Work Orders, Customer Assets, Accounts, Contacts, Products, and Bookable Resource Bookings. The workflow should follow pagination, handle deletes, and resynchronize when a token expires.

How does Martini handle mapping, duplicates, and failures?

Martini can map Dataverse JSON, lookups, choices, files, and timestamps into a canonical or target model and apply validation and business rules before writing. Idempotency can use source identifiers, alternate keys, upsert patterns, and processed event identifiers. Workflows can handle pagination, throttling, bounded exponential backoff, retries, logging, and operational escalation.

Related Martini documentation

API Integration

Triggers

Workflows

Security

Operations

Plan your Dynamics 365 Field Service integration

Use Martini to connect Dynamics 365 Field Service with enterprise applications through Dataverse APIs, configured events, scheduled synchronization, reusable mappings, and reliable workflow orchestration.

EXPLORE MARTINI
BOOK A DEMO