.png)
Dynamics 365 Customer Service Integration Guide
Integrate Dynamics 365 Customer Service with enterprise systems through the Dataverse Web API, selected webhook events, batch operations, and secure Microsoft Entra ID authentication.
Dynamics 365 Customer Service integration options at a glance
Dynamics 365 Customer Service uses the Microsoft Dataverse Web API, an OData v4 REST API for querying, creating, updating, deleting, and relating Customer Service data. Martini can consume this API through OAuth 2.0 with Microsoft Entra ID and orchestrate case, customer, queue, activity, knowledge, and attachment workflows. Dataverse also supports selected webhook-style notifications, batch and asynchronous operations, file columns, and attachment tables. Scheduled synchronization can follow OData pagination and incremental modification filters, while read-oriented analytics access may use TDS where enabled. Legacy SOAP Organization Service integrations remain possible for compatibility, but REST is the recommended interface for new integrations.
| Integration point | Supported by Dynamics 365 Customer Service? | Common use cases | How Martini supports it |
|---|---|---|---|
| Dataverse Web API / OData v4 REST | Yes | Query, create, update, delete, associate, and disassociate Incidents, Accounts, Contacts, Activities, Queues, KnowledgeArticles, and related Dataverse tables. OData filters, expands, ordering, selection, and pagination support targeted synchronization. | Martini can consume the Dataverse REST API from workflows, map OData payloads, call functions or actions, and expose reusable APIs around Customer Service operations. |
| Webhooks / outbound callbacks | Limited | Dataverse can notify external services for selected table messages and pipeline stages such as create, update, or delete. Coverage depends on configured event registrations and is not universal for all Customer Service events. | Martini can expose an API to receive configured notifications, validate and acknowledge the request, retrieve the current Dataverse resource, and process it asynchronously. |
| Bulk / async / batch APIs | Yes | Use OData $batch, ExecuteMultiple, CreateMultiple, UpdateMultiple, and selected asynchronous operations for grouped or higher-volume processing. Availability varies by operation and table. | Martini workflows can construct batch requests, partition workloads, evaluate operation-specific responses, and retry failed units without assuming every table supports every bulk message. |
| File / attachment APIs | Yes | Handle Annotation notes and attachments, ActivityMimeAttachment content, file columns, and selected knowledge content. Binary data may require separate requests or chunked upload patterns. | Martini can retrieve, validate, transform, route, and upload binary content as part of a workflow while applying size, content-type, and retry policies. |
| Authentication | Yes | OAuth 2.0 through Microsoft Entra ID supports delegated and application-only access using confidential clients, client secrets, certificates, or applicable managed identities. Dataverse application users and security roles authorize operations. | Martini can use secured environment configuration for tenant, client, secret or certificate, and organization URL values, keeping credentials out of mappings and payloads. |
| SOAP Organization Service | Legacy | The Dataverse Organization Service provides SOAP-based capabilities for legacy SDK and organization-service integrations. It is not the preferred interface for new development. | Martini can consume SOAP services where compatibility requires it, but new Customer Service workflows should generally use the Dataverse Web API. |
| Database / analytics access | Limited | Read-oriented analytics access may use the Dataverse TDS endpoint or Azure-oriented export capabilities when enabled and permitted. These interfaces are not the transactional write path. | Martini can connect to supported SQL or analytics endpoints for reporting-oriented flows, while using the Dataverse Web API for transactional writes and relationship changes. |
How Dynamics 365 Customer Service exposes data and business events
Dynamics 365 Customer Service REST APIs
The Dataverse Web API is the primary integration surface for Dynamics 365 Customer Service. It exposes OData v4 operations for querying, creating, updating, deleting, associating, and disassociating tables such as Incident, Account, Contact, Activity, Queue, and KnowledgeArticle.
Martini implementation pattern
Martini implementation pattern: configure secure OAuth 2.0 access to the Dataverse environment, invoke the required Web API operation from a workflow, follow OData continuation links, map the response to a canonical model, and write the result to the target system or return it through a Martini API.
Implementation sequence
Dynamics 365 Customer Service Webhooks
Dataverse supports webhook-style notifications for selected table messages and stages, including configured create, update, or delete events. Notifications are configuration-dependent and do not represent a universal stream of every Customer Service event.
Martini implementation pattern
Martini implementation pattern: expose a controlled API endpoint, validate the incoming Dataverse notification, acknowledge it according to the configured contract, and use the event as a trigger to retrieve the current Incident or related resource before applying business logic. A scheduled reconciliation flow can cover missed or unsupported events.
Implementation sequence
Dynamics 365 Customer Service Batch Operations
Dataverse provides $batch, ExecuteMultiple, selected CreateMultiple and UpdateMultiple messages, and asynchronous operations for suitable high-volume workloads. Availability depends on the operation, table, and API version.
Martini implementation pattern
Martini implementation pattern: partition a workload, construct an operation-appropriate batch, submit it through the Web API, inspect individual responses, and retry only transient or failed units. The workflow should retain item-level correlation and observe Dataverse service-protection limits.
Implementation sequence
Dynamics 365 Customer Service Attachments
Customer Service integrations may handle Annotation attachments, ActivityMimeAttachment content, file columns, and knowledge-related content. File data may require separate binary requests or chunked upload patterns rather than being returned with the parent Incident.
Martini implementation pattern
Martini implementation pattern: retrieve or receive attachment metadata, validate content and size, obtain binary data through the appropriate Dataverse operation, and transfer or store it in the target system with a link to the parent case. The workflow should make copy, reference, and exclusion behavior explicit.
Implementation sequence
Dynamics 365 Customer Service SOAP
The Dataverse Organization Service exposes SOAP-based capabilities for legacy SDK and organization-service integrations. Microsoft positions the Web API as the modern interface for new cross-platform integrations.
Martini implementation pattern
Martini implementation pattern: use Martini SOAP API consumption only where an existing Organization Service dependency requires compatibility, isolate the legacy contract behind a reusable workflow, and keep new Customer Service operations on the Dataverse Web API.
Implementation sequence
Common Dynamics 365 Customer Service integration patterns
Pattern 1: Synchronize cases with an external CRM
When to use this pattern
Use this pattern when Dynamics 365 Customer Service and another customer platform must share case status, customer context, and selected service interactions. Scheduled incremental synchronization provides a reconciliation path even when webhook coverage is incomplete.
Integration direction
Example Mapping
| Dynamics 365 Customer Service Field | Canonical Field | Target Field |
|---|---|---|
| incident.ticketnumber | case.externalNumber | Case.CaseNumber |
| incident.title | case.subject | Case.Subject |
| incident.prioritycode | case.priority | Case.Priority |
| incident.modifiedon | case.lastModifiedAt | Case.LastModifiedDate |
Martini implementation pattern
A scheduled Martini workflow filters Incident by modifiedon with an overlap window, follows @odata.nextLink, resolves Account and Contact references, and upserts the target case using a stable Dataverse ID or external correlation key. It applies field and status rules, limits concurrency, and retries throttled or transient requests without creating duplicates.
Martini capabilities used
- workflows
- API consumption
- scheduling
- data mapping
- business rules
- pagination handling
- error handling
Pattern 2: Create cases from a support portal
When to use this pattern
Use this pattern when a customer portal needs to submit service requests while Dynamics 365 Customer Service remains the case-management system. The integration can return a Dynamics case number after validating the request and resolving the customer context.
Integration direction
Example Mapping
| Dynamics 365 Customer Service Field | Canonical Field | Target Field |
|---|---|---|
| request.customerEmail | customer.email | contact.emailaddress1 |
| request.subject | case.subject | incident.title |
| request.category | case.category | subject |
| request.externalId | case.sourceReference | incident.new_externalreference |
Martini implementation pattern
A Martini API receives and validates the portal payload, finds or creates the Contact and Account, maps category values to Subject, sets priority and origin, assigns the Incident to a Queue, and optionally adds notes or attachments. The workflow checks the external reference before creation and returns a controlled response with the Dataverse case identifier.
Martini capabilities used
- APIs
- OAuth security
- workflows
- validation
- data mapping
- business rules
- idempotency
- attachment handling
Pattern 3: Process selected case events
When to use this pattern
Use this pattern when selected Incident create or update messages should trigger enrichment, escalation, publication, or downstream work without waiting for a full scheduled synchronization cycle.
Integration direction
Example Mapping
| Dynamics 365 Customer Service Field | Canonical Field | Target Field |
|---|---|---|
| incident.incidentid | case.id | Issue.externalCaseId |
| incident.title | case.subject | Issue.summary |
| incident.prioritycode | case.priority | Issue.priority |
| incident.statecode | case.status | Issue.status |
Martini implementation pattern
A configured Dataverse webhook invokes a Martini API for selected events. Martini validates the notification, retrieves the current Incident and related customer data, applies escalation rules, and creates or updates the target issue. It records the event identifier and uses a scheduled reconciliation workflow when event coverage or delivery confidence is insufficient.
Martini capabilities used
- API exposure
- webhook consumption
- workflow orchestration
- data enrichment
- business rules
- correlation
- retry handling
Pattern 4: Synchronize queues and assignments
When to use this pattern
Use this pattern when queue, team, user, or assignment information must be aligned with a service-operations or workforce-management application. It is suitable for controlled scheduled synchronization and routing updates.
Integration direction
Example Mapping
| Dynamics 365 Customer Service Field | Canonical Field | Target Field |
|---|---|---|
| queue.queueid | workQueue.id | AssignmentGroup.externalId |
| queue.name | workQueue.name | AssignmentGroup.name |
| incident.ownerid | case.owner | Incident.assignmentGroup |
| incident.queueid | case.queue | Incident.queueReference |
Martini implementation pattern
A Martini workflow retrieves Queue and relevant Incident assignment data, resolves Dataverse user and team references, applies routing and ownership rules, and updates the target assignment model. It validates security permissions, preserves source identifiers, and isolates failed assignments for retry rather than failing the entire synchronization.
Martini capabilities used
- scheduled workflows
- API consumption
- relationship mapping
- business rules
- partial-failure handling
- monitoring
Applications commonly integrated with Dynamics 365 Customer Service
Organizations can connect Dynamics 365 Customer Service with adjacent business applications to synchronize customers, cases, operational context, escalations, and service outcomes. These relationships are implementation choices rather than claims of built-in Microsoft connections; Martini can orchestrate them through each system's documented APIs, webhooks, files, or other supported interfaces.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize accounts, contacts, service cases, and customer interaction data when an organization operates both customer platforms. | Dynamics 365 Customer Service → Martini → Salesforce | Use Dataverse incremental queries or selected webhook notifications to trigger a Martini workflow, normalize Account, Contact, and Incident data, apply system-of-record rules, and upsert corresponding Salesforce objects with correlation IDs and retry handling. |
| ServiceNow | Exchange customer-impacting issues, assignments, and resolution information between customer service and service operations. | Dynamics 365 Customer Service → Martini → ServiceNow | Route Incident events or scheduled changes through Martini, map case and assignment fields to ServiceNow records, apply escalation rules, and return status or resolution updates through the relevant APIs. |
| SAP S/4HANA | Provide service agents with customer, order, delivery, or entitlement-related operational context and return service outcomes where required. | SAP S/4HANA → Martini → Dynamics 365 Customer Service | Consume SAP and Dataverse APIs in a Martini orchestration workflow, correlate customer and order identifiers, enrich Incidents with validated operational data, and handle partial failures through durable retries. |
| Oracle NetSuite | Connect customer service cases with billing, subscription, order, and account information. | Oracle NetSuite → Martini → Dynamics 365 Customer Service | Use scheduled or event-driven workflows to retrieve NetSuite reference data, resolve Dataverse Account and Contact lookups, and create or update Incidents while preserving external identifiers. |
| Shopify | Associate ecommerce customers and orders with Dynamics 365 Customer Service incidents and agent interactions. | Shopify → Martini → Dynamics 365 Customer Service | Receive or retrieve Shopify customer and order data, validate the payload in Martini, resolve Dataverse customer references, and create or enrich Incidents with selected order context. |
| Zendesk | Support coexistence, migration, or consolidation of support tickets, customer profiles, and historical service information. | Zendesk → Martini → Dynamics 365 Customer Service | Extract Zendesk tickets and users, map them to Incident, Contact, and Account models, preserve source ticket identifiers, and use idempotent upserts during migration or dual-platform operation. |
| Jira Service Management | Link customer-reported cases with engineering or product-support work items and synchronize escalation status. | Dynamics 365 Customer Service → Martini → Jira Service Management | Trigger a Martini workflow from selected Incident changes, create or update Jira Service Management work items, and process status callbacks to update the originating case with correlation and duplicate controls. |
| Workday | Synchronize employee, organizational, or support-agent information when Workday is the authoritative HR system. | Workday → Martini → Dynamics 365 Customer Service | Run a controlled scheduled workflow that retrieves Workday changes, maps users, teams, or organizational attributes to Dataverse structures, validates security-sensitive fields, and records reconciliation results. |
How to build a Dynamics 365 Customer Service integration in Martini
Objective
Establish a controlled connection to the Dataverse environment using Microsoft Entra ID and the appropriate application user and security roles.
Instructions in Martini
- Configure the Dataverse organization URL as an environment value
- Use OAuth 2.0 with a confidential client, certificate, secret, or applicable managed identity
- Store tenant and credential values in secure Martini configuration
- Verify Dataverse roles and privileges for each operation
Objective
Select the trigger that matches the required timeliness and event coverage, while retaining scheduled reconciliation for reliability.
Instructions in Martini
- Use a Martini API for portal requests or configured Dataverse webhook notifications
- Use a scheduler for incremental synchronization and reconciliation
- Use a queue or asynchronous workflow where downstream processing should be decoupled
- Document which Dataverse messages and tables are covered by event registrations
Objective
Read the required Dataverse tables and related data without assuming that a single response contains the complete result set.
Instructions in Martini
- Use OData $select, $filter, $expand, and $orderby deliberately
- Follow @odata.nextLink for every paged collection
- Retrieve related Account, Contact, Queue, Activity, or attachment data as needed
- Persist a high-water mark and overlap window for incremental flows
Objective
Coordinate API calls, lookups, enrichment, routing, and target writes as an explicit Martini workflow with controlled failure boundaries.
Instructions in Martini
- Resolve Dataverse GUIDs and navigation properties before relationship updates
- Separate validation, enrichment, transformation, and persistence stages
- Use bounded concurrency and batch operations only where supported
- Maintain correlation identifiers across every external call
Objective
Convert Dataverse table structures, choice values, polymorphic lookups, dates, and binary content into the target system's canonical model.
Instructions in Martini
- Map Incident, Account, Contact, Activity, Queue, and KnowledgeArticle fields explicitly
- Translate numeric choice values using environment-aware configuration
- Normalize time zones and preserve source timestamps
- Handle attachments through separate binary processing when required
Objective
Enforce customer matching, case deduplication, routing, ownership, priority, and system-of-record decisions before writing data.
Instructions in Martini
- Check external references before creating Incidents
- Apply account, contact, queue, team, and user resolution rules
- Validate required fields and target-specific constraints
- Account for Dataverse plugins, flows, SLAs, routing rules, and security behavior
Common Dynamics 365 Customer Service data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Incident | Represents a customer service case, including status, priority, origin, customer lookup, subject, ownership, and resolution information. | ServiceNow, Salesforce, Zendesk, Jira Service Management, customer portals | Martini queries or receives selected Incident changes, resolves lookups, applies case and routing rules, and performs idempotent create or update operations through the Web API. |
| Account | Represents a business or organization receiving service and provides a customer context for cases and contacts. | Salesforce, SAP S/4HANA, Oracle NetSuite, Shopify | Martini synchronizes identifiers and selected attributes, resolves account GUIDs, and uses external correlation keys to prevent duplicate customer creation. |
| Contact | Represents an individual associated with a customer, case, or service interaction. | Salesforce, Zendesk, Shopify, customer portals | Martini validates contact data, matches by stable identifiers, creates or updates Contacts, and sets Incident customer lookups using Dataverse GUIDs. |
| Activity | Represents customer-service work such as email, phone calls, tasks, appointments, and related interactions. | Salesforce, ServiceNow, Jira Service Management, reporting platforms | Martini maps activity types and timestamps, follows related navigation properties, and routes activity updates according to synchronization rules. |
| Queue | Organizes and routes cases or activities for service teams and operational work management. | ServiceNow, workforce-management applications, service operations platforms | Martini reads queue identifiers and attributes, applies routing rules, and updates Incident ownership or queue relationships where the application user has permission. |
| KnowledgeArticle | Stores knowledge content used by agents and customers to resolve service issues. | Customer portals, knowledge platforms, search and content systems | Martini can extract selected article content and metadata, transform formats, and publish or synchronize content through target APIs while respecting configured content scope. |
Authentication and security considerations
Microsoft Entra ID and OAuth 2.0
Dynamics 365 Customer Service access is secured through the Dataverse environment and OAuth 2.0 with Microsoft Entra ID. Martini can use delegated access or an application-only service-principal pattern, with client secrets, certificates, or applicable managed identities.
Dataverse authorization
Authentication does not by itself grant access. The application must be represented as a Dataverse application user and assigned suitable security roles. Business units, teams, ownership, field security, and record-level privileges can affect each operation.
Secure configuration
- Store tenant, organization URL, client credentials, and certificates in secure environment configuration.
- Keep credentials out of mappings, source payloads, and workflow logs.
- Use separate configuration for development, test, and production environments.
- Limit API permissions and Dataverse roles to the operations required by each workflow.
Operational considerations for Dynamics 365 Customer Service integrations
Service protection and pagination
Dataverse applies service-protection limits and can return throttling responses. Martini workflows should limit concurrency, honor retry guidance, use exponential backoff, and follow @odata.nextLink until collections are complete.
Idempotency and relationships
Use stable external references and persisted correlation state to prevent duplicate Incidents after timeouts. Account, Contact, Queue, user, team, and polymorphic customer lookups require GUIDs, navigation properties, and carefully tested associate or disassociate operations.
Schema and server-side behavior
Customer Service environments may contain custom tables, columns, choice values, plugins, flows, SLAs, routing rules, and business rules. Test the complete server-side processing chain, manage API version changes, and obtain metadata where necessary.
Attachments and testing
Attachments may require separate binary or chunked requests. Define size and content rules, test retry behavior, and decide whether files are copied, referenced, or excluded. Monitor failed items and periodically reconcile event-driven flows with scheduled synchronization.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate more than one API call
Scripts often embed authentication, pagination, lookup resolution, mappings, and retry behavior in one codebase. Martini separates these concerns into reusable workflows and APIs that can coordinate Dataverse with portals, CRMs, service platforms, files, databases, and messaging systems.
Make integration behavior explicit
Martini provides a structured place to apply validation, business rules, transformations, idempotency, partial-failure handling, and reconciliation. This is important when Dataverse plugins, security roles, routing rules, or service-protection limits influence outcomes.
Support maintainable delivery
- Keep environment URLs and credentials configurable across deployments.
- Reuse mappings and service logic across case, customer, assignment, and attachment workflows.
- Expose a controlled API façade instead of coupling every client directly to Dataverse.
- Use workflow logging, monitoring, retries, and testing to troubleshoot production behavior.
Frequently asked questions
Dynamics 365 Customer Service is commonly integrated through the Dataverse Web API, an OData v4 REST API that supports querying, creating, updating, deleting, and relating Customer Service data. Selected Dataverse events can produce webhook-style notifications, while batch operations, file and attachment interfaces, scheduled synchronization, and legacy SOAP services support additional scenarios. OAuth 2.0 through Microsoft Entra ID is the standard authentication model.
Yes. Martini can integrate with Dynamics 365 Customer Service by consuming the Dataverse Web API, using Microsoft Entra ID authentication, orchestrating workflows, handling pagination and batch responses, and exposing an API for configured Dataverse webhook notifications. No native Martini connector is documented in the supplied sources.
No. A dedicated Dynamics 365 Customer Service connector is not required. Martini can use the vendor's native Dataverse REST API, OAuth 2.0 authentication, selected webhook-style notifications, batch operations, file and attachment interfaces, or legacy SOAP services where compatibility requires them.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Dynamics 365 Customer Service with Martini. Integration execution is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Microsoft, Dataverse, Azure, infrastructure, or other third-party systems according to their licensing, usage, and deployment models.
The Dataverse Web API is the recommended general-purpose interface for new integrations. It supports OData queries, relationships, functions, actions, pagination, and transactional writes. Selected webhook events and batch or bulk operations can supplement REST workflows, while SOAP Organization Service should generally be reserved for legacy compatibility.
Dataverse supports webhook-style notifications for selected table messages and pipeline stages, such as configured Incident create, update, or delete events. Coverage depends on event registration and is not universal for every Customer Service event. Martini can receive configured notifications through an exposed API, with scheduled incremental synchronization used for reconciliation or unsupported events.
Martini can use modifiedon filters, overlap windows, persisted high-water marks, and @odata.nextLink pagination for incremental synchronization. For suitable operations, Dataverse batch or bulk messages can improve throughput. Stable Dataverse IDs or external correlation keys, idempotent upserts, and item-level retry handling help prevent duplicate Incidents and make recovery safer.
Yes. Martini can expose a controlled API that accepts portal or enterprise requests, validates and transforms them, resolves Account and Contact references, creates or updates Incidents through the Dataverse Web API, and returns a simplified response. This façade can centralize security, business rules, correlation, error handling, and versioning without exposing Dataverse details directly.
Related Martini documentation
APIs
Transformation
Operations
Connect Dynamics 365 Customer Service with Martini
Use Martini to build secure, maintainable workflows around the Dataverse Web API, selected Customer Service events, and enterprise applications.