Dual-Write Async: Faster transactions, different failure risks

I have worked on projects where we have implemented dual-write synchronously. Microsoft has released dual-write async and having gone through the articles from Microsoft, I believe there are important design considerations to make before you use one-way or another.

Here I document:

1. What these models are.
2. When to consider one over the other.
3. CRUD operation behavior of dual-write async.

Dual-write is normally expected to move data between finance and operations apps and Dataverse almost immediately.

That near-real-time behaviour is valuable, but it also connects the source transaction to the availability, validation rules and processing limits of the receiving application.

For high-volume transactions, this can become a problem.

A transaction containing one header and hundreds of lines might fail because of timeouts, transaction-size limits or the time required to validate every related record.

Dual-write async changes that behaviour by moving the data through an internal background-processing queue.

This can reduce pressure on the live transaction, but it introduces a different consistency and failure model.

It is not simply a faster version of dual-write.

Important: Always check Microsoft still documents dual-write async as a preview feature. Preview features are not intended for production use and might have restricted functionality.

Synchronous and asynchronous dual-write are different models

Standard dual-write provides tightly coupled, bidirectional and near-real-time integration between finance and operations apps and Dataverse.

With synchronous dual-write, the receiving application participates in the live transaction.

If a business validation fails in the receiving system, the originating transaction can also fail.

With dual-write async, the originating transaction and the integration transaction are separated.

Synchronous dual-write	Dual-write async
Data is transferred as part of the live transaction	Data movement is processed in the background
The originating user might wait for the receiving system	The originating transaction is decoupled
Errors can immediately block the transaction	Errors might appear after the source transaction is committed
Both applications are expected to be consistent immediately	The applications become consistent after processing
Suitable when immediate cross-system consistency is required	Suitable when a short synchronisation delay is acceptable

Async can improve the source-user experience, but it does so by accepting eventual consistency.

What eventual consistency means

Eventual consistency means the two applications might temporarily contain different information.

A record can be committed in Finance and Operations before the related record or update becomes available in Dataverse—or the other way around.

The background process then sequences and transfers the information.

This delay is acceptable only if the business process can continue safely while the two applications are temporarily different.

The correct question is therefore not:

Can this table use dual-write async?

It is:

Can the complete business transaction tolerate delayed consistency?

When dual-write async can be appropriate

Microsoft recommends considering entities that:

• Belong to one grouped transaction
• Have high transaction volumes
• Contain header-and-line relationships
• Regularly encounter synchronous transaction, timeout or size limits
• Do not require the receiving application to respond before the source transaction completes

When delayed synchronisation is not acceptable

Dual-write async is a poor fit when the next business step depends on the other application already having the latest information.

Examples include:

• A user creates an account in Dynamics 365 Sales and immediately creates a transaction in Finance and Operations
• Dataverse requires an F&O-generated identifier before continuing
• Credit validation depends on the latest customer balance
• Pricing relies on the most recent product, trade agreement or currency information
• Inventory availability must be accurate before confirming an order
• A Field Service process immediately consumes an item in Supply Chain Management
• An approval requires data written by the previous step
• Automation in the receiving system must execute before the user continues

Do not mix synchronous and asynchronous entities in one transaction

This is one of the most important design rules.

If a business transaction contains a mixture of:

• Entities configured for live synchronisation
• Entities configured for dual-write async

the transaction fails.

Microsoft states that a transaction should contain either:

• All asynchronous entities, or
• All synchronous entities

The error identifies the entities that are incorrectly configured.

This means async should not be enabled one table at a time without understanding the complete transaction boundary.

Consider a transaction containing:

• Order header
• Order lines
• Customer details
• Delivery address
• Charges

If the header and lines use async while another participating entity remains synchronous, the complete transaction can fail.

The design must follow the business transaction—not the individual map.

Deletes behave differently

Dual-write async currently supports only:

• Create
• Update

Delete operations do not use the async pipeline.

If a transaction contains a delete, the delete is processed through live synchronisation.

Microsoft treats deletes differently because removing dependent records under eventual consistency creates a greater risk of relationship and referential-integrity failures.

A solution architect should not assume that every operation for an async-enabled entity follows the same route.

Not every error can be retried

A common assumption is that anything processed asynchronously can simply be retried.

Dual-write async has several failure categories, and they behave differently.

Failure type	Meaning	Retry behaviour
Application failure	A business validation or logical rule rejected the transaction	The underlying data or configuration must be corrected
System failure	An unresolvable system or platform issue interrupted processing	The system can retry it
Concurrency failure	The queued record is no longer the latest version	The record is skipped and cannot be retried
Conflict failure	The same record was changed in both applications	The configured primary system determines the winner

For a system failure, the retry processes the record only if its version is still the latest.

If newer changes exist, replaying an older version could overwrite more recent data. The platform therefore uses record versions to protect the current state.

Why concurrency failures are not retried

Imagine the following sequence:

1. A customer record is updated in Finance and Operations.
2. Version 1 is added to the async processing queue.
3. Before version 1 is processed, the record is updated again.
4. Version 2 becomes the latest version.
5. The background process reaches version 1.

Processing version 1 could temporarily overwrite newer information.

The platform therefore skips the outdated version and categorises it as a concurrency failure.

This behaviour prevents phantom or out-of-sequence updates, but it also means that “retry everything” is not a valid operational procedure.

Support teams need to understand the failure category before deciding what action to take.

How conflicts are resolved

A conflict can occur when the same record is edited in both applications before the queued update is processed.

Dual-write async uses the primary for conflict detection configuration to decide which side wins.

For example, if Finance and Operations is configured as primary:

• The Finance and Operations version overrides the Dataverse version.
• The update from Dataverse to Finance and Operations is rejected.

Conflict detection is based on a snapshot of the record state—not simply on the time shown in a record’s modified date.

Microsoft notes that record timestamps cannot be relied upon because:

• Not every record has an appropriate time field.
• The clocks in both systems might not be coordinated.

Conflict failures also require special monitoring because Microsoft states that they are not shown in the normal synchronisation-errors experience. They are visible in a back-end table.

Entity sequencing still matters

Entities within an async group are processed using a defined sequence.

A lower sequence number receives a higher execution priority.

This is necessary for referential integrity.

For example:

1. Customer
2. Order header
3. Order line

Processing the line before the header—or the header before the required customer—could cause the transaction to fail.

Async removes the requirement to process everything as part of the user’s live transaction. It does not remove entity dependencies.

The dependency graph and sequence must reflect the actual data relationships.

The queue does not contain a copy of the data

Dual-write async does not use the Data Import/Export Framework to export and import the records.

Its internal queues contain references used to manage and sequence data movement. They do not hold a separate copy of the business data.

This is another reason why record versions matter.

By the time the queue reference is processed, the underlying record might have changed again.

Note: Dual-write async is event-driven and not scheduled driven, even though the data movement happens in the background.

A practical architecture example

Consider an order-entry process with one order header and 300 lines.

With synchronous dual-write:

1. The user saves the order.
2. All related records are transferred during the live transaction.
3. Dataverse validations and platform limits participate in the save.
4. A timeout or validation error can reject the source transaction.

With async dual-write:

1. The user saves the order.
2. The source transaction commits.
3. References to the header and lines enter the processing queue.
4. The background process applies sequencing and dependencies.
5. Dataverse receives the records after the source transaction has completed.

The user might experience a faster save.

However, the order might not immediately be available to a Dataverse-based customer-service process. If one line fails a business validation, the support team must manage that failure after the user’s original transaction has already succeeded.

The performance benefit therefore comes with an operational cost.

Final thoughts

The most important design rule is simple:

Do not enable async because an individual table is slow. Enable it only when the complete business transaction can safely operate with eventual consistency.

For a process that depends on immediate cross-application validation, async can replace a performance problem with a consistency problem.

Official documentation:

• Dual-write async FAQ
• Dual-write overview

 

Dynamics 365 is slow: Find the bottleneck with Live Monitor and Application Insights

“Adding one sales-order line takes 20 seconds.”

That description tells us there is a problem, but it does not tell us where the problem is.

That's the consequence, but not the cause.

Those 20 seconds could be consumed by:

• Form JavaScript
• A browser or network delay
• A Dataverse request
• A synchronous plug-in
• Repeated SDK operations
• An external service called by a plug-in
• Several individually small operations adding up

Without evidence, different teams can spend days investigating their own components without identifying the real bottleneck.

I am not a technical person, but I read through webpages of articles from Microsoft and understood how to go step-by-step into identifying the cause. Here's a simplified process you can start from and go as deep as you wish.

Dynamics 365 and Power Platform provide two tools that help turn a general performance complaint into a traceable investigation:

• Live Monitor for reproducing and examining an individual session
• Application Insights for analysing correlated telemetry across users, operations and time

They serve different purposes, but they are most useful when used together.

Live Monitor and Application Insights are not interchangeable

Tool	Best used for
Live Monitor	Reproducing a problem and watching events from one session in real time
Application Insights	Analysing performance trends, failures and server-side processing across many sessions
Both together	Following a user action from the model-driven app into Dataverse, plug-ins and external dependencies

Live Monitor helps answer:

What happened when this user performed this action?

Application Insights helps answer:

Does this happen repeatedly, who is affected, and which server-side operation is consuming the time?

That distinction provides a useful investigation sequence.

Start with a reproducible scenario

“Dynamics is slow” is too broad to investigate effectively.

Before opening either tool, define a specific action:

• Opening an opportunity form
• Saving a work order
• Adding a sales-order line
• Loading a dashboard
• Running a command
• Changing a field that triggers JavaScript
• Completing an action that invokes a plug-in or external integration

Record the following information:

• Environment and application
• User experiencing the issue
• Table and form
• Record used for testing
• Exact action performed
• Approximate start time
• Expected response time
• Actual response time
• Whether the issue happens constantly or intermittently
• Whether other users experience the same behaviour

This information allows the same test to be repeated and makes telemetry much easier to find.

Where possible, compare:

• Affected and unaffected users
• Different forms for the same table
• Different records
• Different browsers or devices
• Different geographical locations
• Customised and minimally customised forms

The comparison often reveals whether the problem is user-specific, data-specific, network-related or linked to a particular customisation.

Step 1: Reproduce the problem with Live Monitor

From Power Apps, select the model-driven app and choose Live Monitor from the command bar. You can then launch the app from the monitoring session and reproduce the problem.

Another option is to add &monitor=true to the model-driven app URL and start the monitoring session from the command bar.

Live Monitor records important application activity, including:

• Page navigation
• Form loads and saves
• Command execution
• Network requests
• Script errors
• Form events
• Performance warnings

Avoid clicking through several unrelated processes during the recording. Start the session, reproduce the specific problem and stop. A focused trace is considerably easier to interpret.

Investigating a slow form load

For page navigation, the FullLoad event represents the complete load of the page. It waits for relevant network requests and rendering to finish before the page is considered ready.

The event includes useful properties such as:

• Total load duration
• Form ID
• Load type
• Time spent running custom JavaScript
• Attribution details for custom scripts

The attribution details can identify the publisher, solution, web resource and method associated with JavaScript execution.

This is particularly valuable when a form contains scripts from several solutions. Instead of concluding that “JavaScript is slow,” you can identify which web resource or method is contributing to the delay.

The loadType value also provides context:

• 0 – First visit to a page type
• 1 – First visit to a particular configuration
• 2 – First visit to a particular record
• 3 – The exact record URL has already been visited

This matters because the first load can behave differently from a previously visited form. Performance comparisons should use similar load conditions.

Investigating network requests

Live Monitor also displays the network requests made while the app is running.

Review the requests around the slow action and look for:

• One request with an unusually long duration
• Several sequential requests
• Repeated calls retrieving the same information
• Failed requests followed by retries
• Large responses
• Requests to external services
• Synchronous requests that block the interface

A 20-second user experience does not necessarily mean that one server request took 20 seconds.

For example:

Observation	Likely investigation area
Long custom script time	Client-side JavaScript
Fast server response but slow overall request	Network, browser queue or download
One slow Dataverse request	Server-side processing
Several repeated SDK calls	Plug-in or integration design
Slow external dependency	External API or network route
High duration only for certain users	Location, device or connectivity
Slow duration for every user	Shared customisation or server-side process

The objective is to identify where the delay begins—not to assign ownership prematurely.

Step 2: Capture the correlation identifier

A Live Monitor event can provide an activity or correlation identifier for the operation.

This identifier is the bridge between the user’s monitored session and the telemetry in Application Insights.

Once you identify the slow request, record:

• Activity ID
• Timestamp
• User
• Table
• Operation
• Duration
• Any related request or error details

In Application Insights, the following query can be used to find telemetry associated with the activity:

union *
| where operation_Id contains "[ActivityIdHere]"
| order by timestamp asc

This can reconstruct the path through the application and server rather than treating each event as an unrelated log entry.

Step 3: Analyse broader telemetry in Application Insights

Power Platform can export model-driven app and Dataverse telemetry to Application Insights without requiring custom instrumentation code.

The built-in integration can provide telemetry for:

• Model-driven app page loads
• Unified Interface outbound requests
• Dataverse API requests
• Plug-in executions
• Dataverse SDK operations
• Exceptions
• External dependencies called by plug-ins

An environment or tenant administrator configures the connection through the Power Platform admin centre. Microsoft currently limits this capability to tenants with paid or premium Dataverse licences.

Find slow model-driven app pages

Model-driven app page-load information is stored in the pageViews table.

A useful starting query is:

pageViews
| project
    timestamp,
    name,
    duration,
    user_Id,
    session_Id,
    appModule = tostring(customDimensions.appModule),
    entityName = tostring(customDimensions.entityName),
    formId = tostring(customDimensions.formId),
    hostType = tostring(customDimensions.hostType),
    warmLatency = toint(customDimensions.warmLatency),
    warmThroughput = toint(customDimensions.warmThroughput)
| order by duration desc

This helps identify:

• The slowest pages
• Forms with recurring performance problems
• Users experiencing longer load times
• Differences between browser, mobile and embedded clients
• Possible network latency or throughput problems

Microsoft notes that only page loads whose duration can be measured reliably are included.

Separate network time from server time

A request can feel slow even when Dataverse processes it quickly.

Application Insights exposes network-related information such as:

• Network latency
• User location
• VPN routing
• Proxy or security inspection
• Browser processing
• Response size
• Client connectivity

This can prevent unnecessary changes to plug-ins or forms when the server is not responsible for most of the delay.

Find slow plug-ins

Dataverse plug-in executions are recorded in the dependencies table with the type Plugin.

A simple query can identify the plug-ins with the highest average duration:

dependencies
| where type == "Plugin"
| summarize
    executions = count(),
    averageDuration = avg(duration),
    maximumDuration = max(duration)
    by name
| order by averageDuration desc

Plug-in telemetry can include:

• Plug-in name and type
• Version
• Execution stage
• Table
• Step name
• Depth
• Duration
• Isolation type

Look beyond the plug-in itself

A plug-in may appear slow because it is waiting for something else.

Consider a plug-in that takes eight seconds to complete. The plug-in code might perform very little processing itself but wait seven seconds for an external pricing service.

Optimising the internal code would have little effect. The architecture might instead need:

• A shorter external timeout
• Better error handling
• Caching
• Reduced payloads
• An asynchronous pattern
• Removal of the external call from the user’s synchronous transaction

The end-to-end transaction view is therefore more useful than looking only at the top-level plug-in duration.

Turn the evidence into an action plan

Once the bottleneck has been identified, assign it to the team that can act on it.

That is far more actionable than saying that Dynamics 365 is slow.

A practical investigation sequence

When a user reports that Dynamics 365 is slow:

1. Define one precise, repeatable action.
2. Record the environment, user, record and time.
3. Reproduce the action using Live Monitor.
4. Identify whether the delay is in client processing, network activity or a Dataverse request.
5. Capture the activity or correlation identifier.
6. Find the correlated operation in Application Insights.
7. Review plug-ins, SDK calls and external dependencies.
8. Compare the result across users and time.
9. Assign the finding to the appropriate owner.
10. Repeat the same test after remediation.

Final thoughts

Performance troubleshooting becomes inefficient when every team starts with an assumption.

Live Monitor and Application Insights provide a more disciplined approach.

Live Monitor shows what happened during the user’s session.

Application Insights shows how that operation behaved across the application, Dataverse and its dependencies.

Official documentation:

• Debug a model-driven app with Live Monitor
• Analyse model-driven apps and Dataverse telemetry with Application Insights
• Telemetry events for model-driven apps
• Telemetry events for Microsoft Dataverse
• Troubleshoot form issues in model-driven apps

 

Field Service–F&O integration ends in 2027: What customers must prepare for

For many organizations, the integration between Dynamics 365 Field Service and finance and operations applications sits quietly in the background—moving work order costs, products, services and inventory transactions into the financial system.

That integration is now approaching retirement.

Field Service pricing and costing controls for the Project Operations integration. Source: Microsoft Learn.

Microsoft has confirmed that the existing Field Service integration with finance and operations applications will no longer be available after February 28, 2027.

This does not mean Field Service will stop integrating with Finance and Supply Chain Management. It means the architecture is changing.

Customers need to move towards the newer Field Service and Project Operations integration, where Project Operations provides the financial connection between field execution and finance and operations.

With roughly six months remaining, this should now be treated as an active migration project—not a future roadmap item.

What is happening to the existing integration?

Beginning with Field Service version 8.8.139.398, the Install Finance and Operations option is no longer available in environments where the integration was not already installed and configured.

Existing customers can continue using an enabled integration until its retirement date.

The current integration connects Field Service work order transactions with finance and operations through dual-write and asynchronous processing.

Depending on the transaction type, work order activity can create:

• Item journals for inventory products
• Expense journals for non-inventory products
• Hour journals for services
• Inventory and financial updates in finance and operations

This model is being replaced by an architecture centred on Project Operations.

What replaces it?

Under the new model, Field Service remains responsible for work order execution, scheduling and technician activity.

Project Operations becomes the financial interpretation layer.

Area	Existing integration	Replacement architecture
Field execution	Field Service work orders	Field Service work orders
Financial container	Finance projects and journals	Project Operations projects and contract lines
Material consumption	Work order products create journals	Material Usage Logs become project journals and actuals
Labour	Work order services create hour journals	Approved time entries generate project actuals
Billing	Processed through finance and operations	Project Operations prepares financial actuals and invoices before downstream posting
Finance connection	Direct Field Service integration using dual-write	Project Operations integration journals transfer approved financial data to Finance
Inventory ownership	Supply Chain Management when integration is enabled	Depends on the Project Operations deployment model

A work order is linked to a Project Operations project or project task.

Estimated products and services create project estimate lines. When a technician marks an item as Used, Field Service creates a Material Usage Log. Project Operations converts that usage into project journals and, after approval, financial actuals.

Those actuals can then support project billing, margin reporting and downstream posting into Dynamics 365 Finance.

Microsoft’s intention is that technicians continue working in Field Service. Most of the change takes place behind the operational experience—but it is a significant change for solution architecture, financial processing and administration.

Why Field Service inventory is being suppressed

Customers using Field Service and finance and operations frequently encounter two possible inventory models:

• Native Field Service inventory
• Supply Chain Management inventory

Allowing both systems to appear authoritative creates confusion over stock levels, transfers, adjustments, returns and purchase transactions.

With the existing finance integration enabled, Supply Chain Management becomes the inventory system of record. Field Service inventory navigation and functionality—including inventory adjustments, transfers, RMAs and returns to vendor—is suppressed.

Recent Field Service releases have strengthened this behaviour by hiding Field Service inventory capabilities in environments using the finance and operations dual-write integration.

This does not mean inventory is disappearing.

It means inventory ownership is moving clearly to one system.

Under the new Field Service–Project Operations architecture:

• Project Operations Core without Finance: Field Service remains the inventory system of record.
• Integrated Project Operations with Finance: Finance and Supply Chain Management become the systems of record for inventory and accounting, and Field Service inventory is disabled.

The deployment model therefore needs to be an explicit architecture decision—not simply an installation choice.

This is not just a technical upgrade

The replacement package requires the legacy Field Service–finance and operations integration to be uninstalled.

That makes this a migration rather than something customers should assume will be an automatic in-place upgrade.

The financial processing model also changes.

In the existing integration, Field Service transactions generate finance and operations project journals. In the replacement model, transactions first move through Project Operations estimates, Material Usage Logs, approvals, actuals and invoicing processes.

Any customisations, integrations or reports built around the existing journals and transaction-status records must be assessed.

What customers should review now

1. Identify whether the legacy integration is enabled

Confirm which environments and legal entities currently use the integration.

Do not rely only on the presence of dual-write. Document the actual Field Service transactions flowing into finance and operations, including products, services, journals, pricing, costs and inventory.

2. Review custom dependencies

Look for plugins, Power Automate flows, integrations and reports that depend on:

• Finance and operations transaction records
• Item, expense or hour journals
• Work order product posting
• Project and subproject creation
• Transaction status or retry processing
• Field Service inventory tables
• Custom billing or reconciliation logic

These dependencies might need to be redesigned around Project Operations estimates, Material Usage Logs and actuals.

3. Choose the future deployment model

Decide whether the organisation requires:

• Field Service with Project Operations Core
• Field Service, Project Operations, Finance and Supply Chain Management
• Field Service with Project Operations and another ERP system

This decision determines where inventory, pricing, costing, invoicing and accounting will be controlled.

4. Validate licensing and prerequisites

Microsoft’s current setup guidance requires:

• Field Service version 8.8.142.0 or later
• Project Operations version 4.162.0.0 or later
• A Project Operations licence for the user installing the integration
• Appropriate licensing for the recurring Power Automate flow installed with the package

Even customers that do not intend to use the full Project Operations application should review the licensing requirement.

5. Test company and legal-entity alignment

The service account’s company determines the company used by the work order and its transactions.

Products, services, warehouses and related records must belong to the correct company. Transactions do not synchronise when company values are misaligned.

Multi-company organisations should give this area particular attention during testing.

6. Revisit pricing, costing and approvals

The replacement integration can use either Field Service or Project Operations to calculate prices and costs.

Customers must also decide whether Material Usage Logs should be automatically approved or reviewed before they generate financial actuals.

These are business-process decisions, not simply configuration settings.

7. Test mobile and offline scenarios

The integration installs mobile offline profiles that can override the standard Field Service profiles.

Any existing mobile customisations, offline tables, filters and technician processes should be regression tested before production rollout.

Final thoughts

The retirement of the existing Field Service–finance and operations integration is more than a connector change.

Field Service remains the operational application, but Project Operations becomes the bridge between work performed in the field and its financial outcome.

The biggest questions for customers are:

• Which system owns inventory?
• Where are pricing and costs calculated?
• How will work order usage become financial actuals?
• Which existing customisations depend on the legacy transaction model?

Organisations that answer these questions now will have time to test the new architecture properly.

Official documentation:

• Field Service integration with finance and operations applications
• Field Service integration with Project Operations overview
• Set up Field Service integration with Project Operations
• Deployment models and inventory

 

 

Copy Opportunities in Dynamics 365 Sales: What gets copied—and what does not?

 

Copy opportunity in Dynamics 365 Sales. Source: Microsoft Learn.

Over the course of my career I have customized this functionality across Opportunities, Quotes and even Orders. Good to see this introduced as a standard in D365.

Repeat opportunities are common in sales.

A customer renews the same service every year. A distributor places a similar seasonal order. An existing customer starts another project with almost identical products and stakeholders.

Previously, sellers either recreated the opportunity manually or organisations developed custom cloning solutions. Dynamics 365 Sales now provides a standard Copy opportunity feature.

The feature became generally available on August 6, 2026.

How to copy an opportunity

Open an existing opportunity—or select one from the opportunity view—and choose Copy opportunity from the command bar.

Dynamics 365 creates a new opportunity for review. Products and stakeholders are added after the new opportunity is saved.

The button is available when:

• The user has Create permission for opportunities.
• The administrator has not disabled the feature.

What gets copied?

Category	What happens
Customer details	Account, primary contact and currency are copied
Opportunity details	Estimated value, budget, description, purchase timeframe and ratings are copied
Products	Product lines, quantities and pricing are copied after saving
Stakeholders	Connections, roles and descriptions are copied after saving
Custom fields	All custom fields are copied—including hidden fields and fields not present on the form

That last point deserves attention.

A hidden custom field may contain an internal classification, integration reference or information that should not carry forward to another deal. Administrators should review such fields before enabling this feature across the organisation.

What gets reset?

The copied opportunity is still treated as a new deal. Therefore:

• Status is set to Open.
• The business process returns to its first stage.
• Ownership changes to the user copying the opportunity.
• Created and modified timestamps use the current date and time.
• Actual close date and actual revenue are cleared.
• The competitor is cleared when copying a lost opportunity.

What does not get copied?

Dynamics 365 does not copy:

• Activities
• Notes and attachments
• Quotes
• Orders
• Invoices
• Timeline history

Inactive products are also excluded. Dynamics 365 records skipped products and other copy details in the timeline summary.

This means the feature copies the commercial starting point—not the complete history of the original deal.

A practical example

Suppose a customer purchases the same maintenance package every year.

The salesperson can copy last year’s opportunity, retain the customer, products, pricing and stakeholders, and then update the expected closing date and commercial details.

However, last year’s emails, meeting activities, quotation and invoice will not move to the new opportunity. This keeps the new sales cycle separate from the previous one.

What administrators should check

Before rolling this out, I recommend checking three things:

1. Review custom fields
   Identify fields that should not automatically carry forward, particularly hidden integration, approval and reporting fields.
2. Test automation
   The copied opportunity and its related product records are new records. Test any create-triggered plugins, workflows or Power Automate flows in a sandbox.
3. Define seller responsibility
   Sellers should review dates, pricing, owner, forecast category, territory and other deal-specific information before saving or progressing the opportunity.

The feature is enabled by default. Administrators can hide it from:

App Settings → Lead + Opportunity management → Opportunity management → Show “Copy opportunity” button

Final thoughts

Copy Opportunity is a small but genuinely useful addition to Dynamics 365 Sales.

It reduces repetitive data entry without mixing the history of two different deals. The important part is understanding that it is not a complete clone: some information is copied, some is reset, and transactional history stays behind.

Used with the right controls, it can replace many custom opportunity-cloning requirements with standard functionality.

Official documentation: Copy an opportunity

Case Management Agent in Dynamics 365 Customer Service: Assisted vs Autonomous

The Case Management Agent in Dynamics 365 Customer Service can automate the complete case lifecycle—from creation and updates to resolution, follow-up and closure.

The important functional decision is not simply whether to enable it. It is deciding where a customer service representative must remain in control and where the agent may act autonomously.

What is the Case Management Agent?

The Case Management Agent processes customer interactions and case information using configurable flows. Microsoft divides its capabilities into three areas:

• Case creation and update: Creates cases from conversations and predicts or updates configured fields using available context.
• Case resolution: Identifies intent, gathers information, uses organisational knowledge and drafts customer responses.
• Follow-up and closure: Manages follow-up emails and closes cases when configured conditions are met.

Configure Case Management Agent – Microsoft Learn

Assisted vs autonomous processing

Capability	Representative confirmation	Full automation
Case creation and field updates	The representative reviews suggested values before saving.	The agent creates or updates the case when sufficient context is available.
Customer response	The agent drafts the email; the representative reviews and sends it.	The agent sends the email through the configured application user and shared mailbox.
Resolution	The agent suggests a resolution for human review.	The agent can resolve the case when the intent and required information are clear.
Follow-up and closure	The representative reviews follow-ups and closes the case.	The agent sends follow-ups and closes the case using configured rules and wait times.
Best suited for	New, sensitive or complex processes.	Stable, repeatable and low-risk case types.

For case resolution, Microsoft also provides Shadow mode, which predicts actions on live cases without sending emails or changing records. Disabled mode stops the agent from drafting responses.

Case resolution configuration – Microsoft Learn

Example business scenario

Consider a manufacturer receiving service emails about equipment faults.

A customer reports that a machine repeatedly stops during operation and includes the serial number. The Case Management Agent could:

1. Create or update the case from the incoming interaction.
2. Predict fields such as product, issue category, priority and serial number.
3. Identify the customer’s intent and check the configured knowledge sources.
4. Draft troubleshooting instructions or request missing information.
5. Send follow-ups if the customer does not respond.
6. Resolve the case or escalate it to a representative.

During an initial rollout, the business may require a representative to review every message. Once accuracy and exception handling are proven for a specific case category, that category could move to full automation.

Prerequisites to consider

The exact prerequisites depend on the capabilities being enabled. The documented requirements include:

• Enable AI agents for the environment in Power Platform admin center.
• An active Azure subscription and the required administrator or customer-service roles.
• Consumption-based billing where the underlying agent capability requires pay-as-you-go usage.
• Customer Intent Agent for intent-based case resolution.
• AI form-fill assistance and automatic record-creation rules for relevant creation scenarios.
• Configured channels, authenticated chat, workstreams, queues and voice transcription where applicable.
• An application user and shared mailbox for fully autonomous case resolution and outbound communication.
• Dataverse auditing and suitable permissions so AI-generated updates can be reviewed.

Case creation and update prerequisites – Microsoft Learn

Important functional decisions

Before configuration, agree on:

• Which case types and lines of business the agent may process.
• Which fields the agent can predict or update.
• Whether AI updates may overwrite fields edited by a representative.
• Which intents, knowledge sources and email templates are approved.
• What triggers case resolution and follow-up.
• The number and timing of follow-up emails.
• Supported communication languages and fallback behaviour.
• When the agent must escalate to a representative.
• How supervisors will monitor agent actions, exceptions and feedback.

The overwrite decision is especially important. Microsoft allows administrators to decide whether autonomous updates may replace values previously entered by a representative.

How should it be tested?

Start with a limited line of business and representative confirmation.

Validate:

• Case creation only occurs when sufficient context is available.
• Predicted fields are accurate, including lookup values.
• Intent classification and knowledge grounding are reliable.
• Email tone, templates and language are appropriate.
• Missing information produces the correct clarification request.
• Negative, unclear and unsupported requests are escalated.
• Follow-up rules, wait periods and closure conditions work as expected.
• Audit history and supervisor monitoring provide enough traceability.

Microsoft provides simulations for field prediction, resolution and follow-up scenarios. Depending on the capability, simulations can use selected organisational records or an Excel file and can process up to 100 records. Simulations and Shadow mode consume Copilot or AI credits.

Agent Feed and Agent Supervisor views can help supervisors review agent actions, communications, processing status, fallback reasons and escalations.

Configure autonomous agent monitoring – Microsoft Learn

Recommended rollout approach

1. Define: Select one high-volume, low-risk case category.
2. Simulate: Test historical and controlled sample cases.
3. Observe: Use representative confirmation or Shadow mode.
4. Measure: Review prediction accuracy, response quality, escalations and credit consumption.
5. Automate: Enable full automation only for proven scenarios.
6. Expand: Add further case categories gradually.

Frequently asked questions

Can the Case Management Agent create cases automatically?

Yes. It can create cases from supported conversations when enough context exists to populate the configured fields. It can also update cases using conversation or incoming-email context.

Does fully autonomous processing require a shared mailbox?

A dedicated application user and shared mailbox are required for fully autonomous case resolution and automated outbound emails.

Can the agent overwrite changes made by a representative?

Yes, but only when the administrator enables the option that permits autonomous updates to overwrite human edits. This should be agreed and tested carefully.

How are follow-ups triggered?

Follow-up can be triggered by customer-email context or a configured case status reason. Rules also define conditions, follow-up count, wait times and templates.

Is every capability generally available?

No. Availability and preview status vary by capability and region. For example, simulations and Shadow mode are documented as preview features, and autonomous follow-up has specific preview terms. Check Microsoft Learn before production deployment.

Final takeaway

The Case Management Agent is not a single automation switch. It is a set of configurable capabilities covering the case lifecycle.

For most organisations, the safest approach is to begin with representative confirmation, prove the rules and data quality, monitor results, and then grant full autonomy only to predictable, low-risk scenarios.

Automation provides speed. Clear functional boundaries provide control.

Responsible AI FAQ for AI agents – Microsoft Learn

The Case Management Agent in Dynamics 365 Customer Service can automate the complete case lifecycle—from creation and updates to resolution, follow-up and closure.

The important functional decision is not simply whether to enable it. It is deciding where a customer service representative must remain in control and where the agent may act autonomously.

What is the Case Management Agent?

The Case Management Agent processes customer interactions and case information using configurable flows. Microsoft divides its capabilities into three areas:

• Case creation and update: Creates cases from conversations and predicts or updates configured fields using available context.
• Case resolution: Identifies intent, gathers information, uses organisational knowledge and drafts customer responses.
• Follow-up and closure: Manages follow-up emails and closes cases when configured conditions are met.

Configure Case Management Agent – Microsoft Learn

Assisted vs autonomous processing

Capability	Representative confirmation	Full automation
Case creation and field updates	The representative reviews suggested values before saving.	The agent creates or updates the case when sufficient context is available.
Customer response	The agent drafts the email; the representative reviews and sends it.	The agent sends the email through the configured application user and shared mailbox.
Resolution	The agent suggests a resolution for human review.	The agent can resolve the case when the intent and required information are clear.
Follow-up and closure	The representative reviews follow-ups and closes the case.	The agent sends follow-ups and closes the case using configured rules and wait times.
Best suited for	New, sensitive or complex processes.	Stable, repeatable and low-risk case types.

For case resolution, Microsoft also provides Shadow mode, which predicts actions on live cases without sending emails or changing records. Disabled mode stops the agent from drafting responses.

Case resolution configuration – Microsoft Learn

Example business scenario

Consider a manufacturer receiving service emails about equipment faults.

A customer reports that a machine repeatedly stops during operation and includes the serial number. The Case Management Agent could:

1. Create or update the case from the incoming interaction.
2. Predict fields such as product, issue category, priority and serial number.
3. Identify the customer’s intent and check the configured knowledge sources.
4. Draft troubleshooting instructions or request missing information.
5. Send follow-ups if the customer does not respond.
6. Resolve the case or escalate it to a representative.

During an initial rollout, the business may require a representative to review every message. Once accuracy and exception handling are proven for a specific case category, that category could move to full automation.

Prerequisites to consider

The exact prerequisites depend on the capabilities being enabled. The documented requirements include:

• Enable AI agents for the environment in Power Platform admin center.
• An active Azure subscription and the required administrator or customer-service roles.
• Consumption-based billing where the underlying agent capability requires pay-as-you-go usage.
• Customer Intent Agent for intent-based case resolution.
• AI form-fill assistance and automatic record-creation rules for relevant creation scenarios.
• Configured channels, authenticated chat, workstreams, queues and voice transcription where applicable.
• An application user and shared mailbox for fully autonomous case resolution and outbound communication.
• Dataverse auditing and suitable permissions so AI-generated updates can be reviewed.

Case creation and update prerequisites – Microsoft Learn

Important functional decisions

Before configuration, agree on:

• Which case types and lines of business the agent may process.
• Which fields the agent can predict or update.
• Whether AI updates may overwrite fields edited by a representative.
• Which intents, knowledge sources and email templates are approved.
• What triggers case resolution and follow-up.
• The number and timing of follow-up emails.
• Supported communication languages and fallback behaviour.
• When the agent must escalate to a representative.
• How supervisors will monitor agent actions, exceptions and feedback.

The overwrite decision is especially important. Microsoft allows administrators to decide whether autonomous updates may replace values previously entered by a representative.

How should it be tested?

Start with a limited line of business and representative confirmation.

Validate:

• Case creation only occurs when sufficient context is available.
• Predicted fields are accurate, including lookup values.
• Intent classification and knowledge grounding are reliable.
• Email tone, templates and language are appropriate.
• Missing information produces the correct clarification request.
• Negative, unclear and unsupported requests are escalated.
• Follow-up rules, wait periods and closure conditions work as expected.
• Audit history and supervisor monitoring provide enough traceability.

Microsoft provides simulations for field prediction, resolution and follow-up scenarios. Depending on the capability, simulations can use selected organisational records or an Excel file and can process up to 100 records. Simulations and Shadow mode consume Copilot or AI credits.

Agent Feed and Agent Supervisor views can help supervisors review agent actions, communications, processing status, fallback reasons and escalations.

Configure autonomous agent monitoring – Microsoft Learn

Recommended rollout approach

1. Define: Select one high-volume, low-risk case category.
2. Simulate: Test historical and controlled sample cases.
3. Observe: Use representative confirmation or Shadow mode.
4. Measure: Review prediction accuracy, response quality, escalations and credit consumption.
5. Automate: Enable full automation only for proven scenarios.
6. Expand: Add further case categories gradually.

Frequently asked questions

Can the Case Management Agent create cases automatically?

Yes. It can create cases from supported conversations when enough context exists to populate the configured fields. It can also update cases using conversation or incoming-email context.

Does fully autonomous processing require a shared mailbox?

A dedicated application user and shared mailbox are required for fully autonomous case resolution and automated outbound emails.

Can the agent overwrite changes made by a representative?

Yes, but only when the administrator enables the option that permits autonomous updates to overwrite human edits. This should be agreed and tested carefully.

How are follow-ups triggered?

Follow-up can be triggered by customer-email context or a configured case status reason. Rules also define conditions, follow-up count, wait times and templates.

Is every capability generally available?

No. Availability and preview status vary by capability and region. For example, simulations and Shadow mode are documented as preview features, and autonomous follow-up has specific preview terms. Check Microsoft Learn before production deployment.

Final takeaway

The Case Management Agent is not a single automation switch. It is a set of configurable capabilities covering the case lifecycle.

For most organisations, the safest approach is to begin with representative confirmation, prove the rules and data quality, monitor results, and then grant full autonomy only to predictable, low-risk scenarios.

Automation provides speed. Clear functional boundaries provide control.

Responsible AI FAQ for AI agents – Microsoft Learn