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

Dynamics 365 Sales Product Relationships: Substitute vs Cross-Sell Explained

Product relationships in Dynamics 365 Sales help sellers discover alternatives and complementary products while working on opportunities, quotes, orders and invoices. The most common confusion is between Substitute and Cross-sell—and whether selecting a substitute automatically replaces the original product.

Quick answer: A substitute is an alternative to the original product, while a cross-sell is an additional related product. In the standard Dynamics 365 Sales experience, both appear as suggestions. Selecting a substitute adds it to the transaction; it does not automatically remove or replace the original line.

What are product relationships?

Dynamics 365 Sales supports four relationship types: Accessory, Cross-sell, Substitute and Up-sell. Microsoft describes these relationships as suggestions shown to sellers during opportunity or order management. A relationship can be created for a product or product bundle, but not for a product family. See Microsoft Learn: Define related products.

Substitute vs cross-sell vs up-sell vs accessory

Relationship	Functional meaning	Example	Expected seller action
Substitute	An alternative when the original product is unavailable or unsuitable.	Filter Model B instead of discontinued Filter Model A.	Add the substitute and remove the original if replacement is intended.
Cross-sell	A related product sold in addition to the selected product.	Add a maintenance kit with a machine.	Keep the original and add the related product.
Up-sell	A higher-value alternative to the selected product.	Offer a premium machine model instead of the standard model.	Discuss the higher-value option with the customer.
Accessory	A supporting item used with the main product.	Add a mounting bracket for the selected equipment.	Add the accessory when required.

It also supports relationship direction. Cross-sell and Substitute can be unidirectional or bidirectional, while Accessory and Up-sell are unidirectional. This matters when deciding whether Product A should suggest Product B only, or whether each product should suggest the other.

How to configure product relationships

1. Open the Sales Hub app.
2. Select Change area and open App Settings.
3. Under Product Catalog, select Families and products.
4. Open the product for which suggestions should be configured.
5. Open the Related tab and select Product Relationships.
6. Select New Product Relationship.
7. Select the related product, relationship type and direction.
8. Save and close the relationship.

The product being configured can be in Draft, Active or Under Revision state.

How sellers use Suggestions

On an opportunity

1. Open the opportunity and go to the product grid.
2. Select the existing product.
3. Select Suggestions.
4. Choose one or more related products and select OK.

On a quote, order or invoice

1. Open the transaction and locate the Products section.
2. Select a product and choose More commands > Suggestions.
3. Select the related products to add and select OK.

The process is the same for quotes, orders and invoices. See Add products to quotes, orders or invoices.

Why does a substitute not replace the original product?

This is standard behaviour. Microsoft’s documented action is to select related products from the Suggestions pane and add them to the transaction. The relationship classifies the recommendation; it does not execute replacement logic.

Therefore, if the seller intends to replace Product A with Product B, the functional process is:

1. Add Product B from Suggestions.
2. Confirm its unit, quantity, price and other line details.
3. Remove Product A manually.

If the business requires one-click replacement, that would be a custom solution—for example, a command that creates the substitute line, copies approved values and removes the original only after validation. Ensure that the design also account for quantities, pricing, discounts, bundles, tax, inventory, integrations and approvals.

Practical functional example

Assume a spare-parts business sells Pump Model A.

• Pump Model B is configured as a bidirectional substitute because either model can serve as the alternative.
• Maintenance Kit is configured as a cross-sell because it is sold in addition to the pump.
• Premium Pump Model C is configured as a unidirectional up-sell from Model A.
• Mounting Bracket is configured as a unidirectional accessory.

When Model A is selected, the seller can review all four options in Suggestions and decide what matches the customer’s need. Dynamics 365 assists the decision but does not make it on the seller’s behalf.

Frequently asked questions

Does Substitute automatically replace a product?

No. It appears as a suggestion and is added when selected. The original line must be removed separately in the standard experience.

Can relationships be defined on product families?

No. Microsoft states that related products can be added to a product or product bundle, but not to product families.

Where are product relationships stored in Dataverse?

They are represented by the Product Relationship (ProductSubstitute) table, which stores the relationship type between two products. See Product catalog tables.

D365 Sales Product Relationships vs F&O

If your organization uses both Dynamics 365 Sales and Dynamics 365 Supply Chain Management, an obvious question arises: If substitute, cross-sell or alternative products are already maintained in F&O, can Dynamics 365 Sales automatically use those relationships?

The short answer is: Not out of the box.

Dynamics 365 F&O has its own concepts for alternative products, cross-selling and up-selling. However, Microsoft does not currently provide a standard Dual-write map that automatically converts F&O product relationships into Dynamics 365 Sales Product Relationships..

Have you implemented product relationships in your Dynamics 365 Sales solution? Share your experience or questions in the comments.

 

Find what’s hiding a field in Dynamics 365: Step-by-Step with PowerApps Live Monitor

A Little Background

A field (msdyn_customergroupid / Customer Group) exists in Dataverse for the Account table, but it is not showing on the Account form in a Dynamics 365 model-driven app. Our requirement was to show this on the form and I know that we had made it visible on the Account form.

However, after a deployment we noticed that it wasn't the case. Now it could be because on various reasons:

• The field is hidden on the form level.
• Column security profile was implemented.
• There is a business rule, due to which it was hidden.
• There is a script, due to which the field was hidden.

Our Approach

The easiest way to rule out the problem is to start with the simplest reason and work your way up.

Step 1 - To check if field was hidden on the form

We checked if the field was hidden on the form? It wasn't. That was easy.

Now, to check Business Rules and Script was a hard road for us because we had 20+ rules and many functions written on form load.

Step 2 - Run quick form-runtime checks (console logic)

We used simple client checks to classify the problem.

This is the fastest way to know whether you’re dealing with design-time vs runtime.

Click F12 > Console and run these commands:

Xrm.Page.getControl("msdyn_customergroupid")

If the call returns null, the field is not on the form. For us, tt returned the Control means something must be hiding it.

Xrm.Page.getControl("msdyn_customergroupid").getVisible()

If it returns a control, something must be hiding it. We ran the below command to confirm:

It returned FALSE.

Step 3 - Use PowerApps Live monitor to capture the visibility change

When I opened the PowerApps Live Monitor and performed the steps within the App, I captured a Live monitor event:

• dataSource: Forms.FormChecker.ControlStateChange
• controlName: msdyn_customergroupid
• visible before: true
• visible after: false

And the call stack included:

• M.setVisible(...)
• pbl_c3f86e4e73b7ed1183ff6045bd8c93df(...)
• Mscrm.BusinessRulesScript.Initialize(...)

Key Finding:

The field was initially visible, then explicitly hidden at runtime by a business rule script.

This pattern indicates the visibility change came from a Business Rule (Power Apps compiles business rules into runtime scripts, commonly visible as pbl_<guid> style functions).

So we could say with confidence:

✅ A Business Rule running on the Account form hid Customer Group by calling setVisible(false).

✅ Not JavaScript web resources. Not security. Not form XML missing. Not personalization.

✅ Focused our attention to look at all the business rules and we could find the culprit.

Hope this helps!

All about Addresses in Dynamics 365

We had a requirement regarding addresses that had to be addressed in Dynamics 365 CE. I thought to share it.

Requirements

• To be able to select the following fields as a dropdown, preferably a lookup. Fields: District, City and Country because the District and City list may continue to expand in the future.
• To be able to add multiple addresses against the Account. 2 or more.
• In case we need to update an address, there must be a provision in the Address table to select the District, City and Country as well. i.e., these fields must be available in the Address table as lookup fields.

These requirements sound simple to implement, however the address entity lacks flexibility due to which we had to think of a workaround.

Things I have learnt about Addresses

1. On the Account we can add maximum 2 addresses. Address 1 and Address 2. Let's call this embedded address. If we need to add a 3rd address related to an account, we need to create a new address record (in the related system Address table).
2. While the Country and State fields are available, these are text fields in the embedded address and related system address table.
3. The related address table is non-customizable. We cannot add additional lookup fields in that entity.
4. When an Account or Contact record is created, blank Address records are automatically created and linked to the Account (or Contact). These are associated with the embedded address records and are numbered as "addressnumber" 1 and 2. addressnumber 1 represents invoice address and 2 represents delivery address by default.
5. The system Address tables don't have lookup to Account or Contact. The relationship is identified by 2 fields namely, "objecttypecode" and "parentid". objecttypecode recoginzes if this related address is linked to "Account" or "Contact" and parentid is the actual GUID value of the Account or Contact.

Workaround to address the limitations

Since the system Address entity is linked and tightly integrated in Dynamics 365 CE, we couldn't replace the system Address table with new custom Address table. I am saying this because, system Address primarily linked to Account and Contact, but when we update the address on Lead and qualify it, the embedded Address and correspondingly the system Address records are also updated. Also, indirectly linked with Opportunities, Quotes and beyond. If you're considering dual write integration with Dynamics 365 F&O, these are again tightly integrated there.

Having analyzed this, we went ahead with a custom Address entity but ensured we are keeping the system Address entity records in sync as well.

What did we do?

1. We created 3 custom lookup fields called District, City and Country on the Lead, Account and Contact tables for easy data entry from users perspective. When the user selects these fields, we populate the OOB District, State and Country text fields and those are automatically updated in the related system address records.
2. We introduced a custom address entity and ensured the user uses this for their data entry and viewing. When the user updates the embedded address, we also need to create custom address records related to Account.
3. When the custom address records are updated, we need to update the related system address entity records.
4. When a new custom address is created, we create a related system address entity record and link it with the respect Account by updating the objecttypecode and parentid.
5. When the custom address is deleted, we need to also delete the related system address record and update the embedded addresses if the addressnumber matches. By update I mean we had to clear the values in the embedded address fields on the Account record.
6. For the most part we can treat system Addresses as a target only, as they are a copy of the custom Address entity data. We can set up a business process and data entry process in such a way that system addresses are not updated, however, if some process we don’t know about updates a system Address, it needs to get reflected up to the custom Address as well.

Hope that helps!

Unable to update Order Product using Workflows in D365 CE

Here is a note for y'all, something to keep in mind when working with workflows in Dynamics 365 Customer Engagement (D365 CE).

You can create a workflow (i.e., initiate a workflow) on the following tables:

• Opportunity Product
• Quote Product
• Order Product

But when you add a step to Update record within the workflow, you'll notice that you cannot update the above mentioned tables (entities). You can however update any of the related tables linked with these tables.

Add Price List Items too into the above mix. Can create a workflow based on this table, but cannot update Price List Item record using a workflow step.

I believe the workaround would be to use Power Automate flows instead of Workflows. I haven't tried this as yet, but I believe it is possible.

Hope it helps!

Dual-Write | Unable to create Order from Quote in D365 CE Sales

While converting a Quote into an Order in D365 CE Sales, I was receiving an error message that went like:

Dual Write core application error-Dual Write core application error-Unable to write to Finance and Operations apps due to following error(s): {"Write failed for entity CDS sales order lines V2 with unknown exception - Inventory dimension Site is mandatory and must consequently be specified.\nUpdate has been canceled."} Please rectify your data and try again. If issue persists after multiple retries, please contact your system administrator.

Since dual write is seamless integration and data synchronization across D365CE and D365FO and as the default shipping site and warehouse is required while creating the Order in F&O, we need to ensure that the value is populated prior to creating the Sakes Order. 

Solution

While encountering an error can be frustrating, the good news is that there is a solution.

In this case, the remedy involves performing relationship mapping between the Quote and Order entities. Relationship mapping essentially defines how data is transferred between related entities.

Steps:

• Open the solution in D365 Sales App. Ensure you've added the following components:
• Quote and Order tables
• 1:N relationship between Quote and Order
• Open the relationship and click on Relationship Mapping
• Add a new Map and select Default Shipping Site and Default Shipping Warehouse.
• Now try to convert the Quote into an Order.

It should be smooth sailing now.

Hope that helps!

Error when qualifying Lead into Opportunity | D365 Sales

There could be many reasons and most of it could be found when you perform an online search, but none of those suggestions fixed my issue. When I was qualifying the Lead into an Opportunity, it is showing the following error:

OrganizationServiceFault

And that is it. No other details about the error. No error log, not description of the error, no error code. Nothing!

Resolution

My user didn't have system administrator, but a custom role was assigned to the user. I took some help from my technical team who did a little bit of digging and came across this below message.

Entered Microsoft.Dynamics.SCMExtended.Plugins.Plugins.LeadPrimaryContactPostCreate.Execute(), Correlation Id: 021c0dc2-3e1e-46e5-81c0-b1524ae09ed2, Initiating User: e7925424-1da4-ed11-aad1-002248a13b63

Exception: System.ServiceModel.FaultException`1[Microsoft.Xrm.Sdk.OrganizationServiceFault]: Principal user (Id=xxxx5424-xxxx-ed11-xxxx-002248a1xxxx, type=8, roleCount=4, privilegeCount=1064, accessMode=0, MetadataCachePrivilegesCount=9751, businessUnitId=0b2c4b59-0e31-ee11-bdf4-000d3aba3d29), is missing prvReadSolution privilege (Id=b64e92c8-5d2a-4052-a026-1b73eff9cebf) on OTC=7100 for entity 'solution' (LocalizedName='Solution').

I provided a Read privilege to Solution table under; relevant Security Role > Customization > Solution, and it worked.

Hope it helps!

Dual-Write | Unable to delete Postal Address Collections in D365 Sales

If you're unable to delete Postal Address Collection records in Dynamics 365 Customer Engagement Sales App, most likely the reason is there is related Postal Address records under that.

When I try to delete Postal Address records using Advanced find, I couldn't find the Delete button on it. If I open the record (for Postal Address), still couldn't see the delete button.

I used Bulk Record Deletion job to delete Postal Addresses and then I could go ahead and delete Postal Address Collections.

What are these tables you ask? These are added when you implement dual-write and install GAB solution in the dataverse. If the 2 environments are in sync, it is best to delete these records in F&O and let dual-write handle the deletion in D365 CE Sales.

We were in a situation where the F&O environment wasn't in sync with CE and we had to remove these records manually in CE only.

Hope it helps!

Dual-Write | Privileges required for Initial Sync and other considerations

Recently we were doing an initial sync for tables between Dynamics 365 Finance & Operations apps and Dataverse (Dynamics 365 Customer Engagement), and we received an error that read:

Reason: Bad Request, Header x-ms-client-request-id 8aef8aa3-2a01-493e-a0d7-347ce560e50d, Principal team (Id=b7e1929e-xxxx-xxxx-aad0-xxxx489fxxxx, type=9, teamType=0, privilegeCount=0, MetadataCachePrivilegesCount=9751, businessUnitId=b5e1929e-xxxx-xxxx-aad0-xxxx489fxxxx), is missing prvReadmsdyn_globalproduct privilege (Id=539cf392-xxxx-xxxx-b258-xxxx719b7d93) on OTC=10835 for entity 'msdyn_globalproduct' (LocalizedName='Global Product') in Business Unit: unqxxxx (Id=b5e1929e-xxxx-xxxx-aad0-xxxx489fxxxx). context.Caller=691e1af2-xxxx-xxxx-aad1-xxxx489axxxx

Sometimes when you're excited and hurrying into the action, you miss the fine details and here are the fine details.

Security role that is required

Every user in a customer engagement organization with dual-write must be given Dual-Write Runtime User role. Without this role, users will be unable to create any rows in tables in customer engagement organization.

Company and currency exchange tables are global in nature and all dual-write users require read access to these 2 tables. To provide access, all dual-write users must be given Dual-Write App User security role. If a user does not have this security role assigned to them, they will not be able to read tables that contain Company and Currency.

Also access is required to entities (tables in dataverse) that are in scope of dual-write. However which privilege is required is not very clear. What you can do is to create a custom role and provide the relevant privilege to the tables in scope of your dual-write integration. We had provided Create, Read and Write which worked for us.

PS: I do believe Read privilege should be enough. Comment down below if you have an experience regarding the exact privilege required.

Here is the link to other considerations before performing initial sync & setup dual-write security roles and permissions.

Hope this helps!

Dual-write | Unable to create a Quote in Dynamics 365 Sales

We have enabled Dual-write in one of our environment's and we have the Quote table in running status for dual-write sync however, when we try to create a Quote in D365 Sales, for some reason it was failing and the error message was like below.

"Write failed for entity CDS sales quotation header with unknown exception - BOX API can't be used from non-interactive sessions."

To approach this, we ensured that we have followed and setup the prerequisites mentioned in Microsoft's documentation about Quote-to-cash in dual-write

Also we were using Trade Agreements pricing engine and the setup for that is mentioned here: Sync on-demand with SCM pricing engine

Resolution

What we did was, we went to form "Sales and marketing parameters" in Finance and Operations to check if the field "Create opportunity for sales quotation" is set to Prompt.

If it is set to Prompt, you need change to another value based on your requirement. We changed this to No and tried creating the quote. It worked!

There could be many reason's for this failing and this is what has helped up. Let me know in the comments below if it was different for you and how did you resolve it.

Hope it helps!

2 Lesser known facts about Dynamics 365 CE (CRM Sales)

 While exploring the default forms and views for Dynamics 365 Sales I understood few facts. It is strange how even after years of experience on the product there are still some things that you have never explored.

I guess the main reason is that these don't impact any implementation in a major way, hence you tend to ignore them, and only find out by accident, like I did. So here are the facts.

1. Discount List forms and views cannot be customized

That's right. When you try to add form and view components for the Discount List table, you'll see that there are no components to be found here. 😲

2. Cannot add some fields on Price List Item views 

When I was expanding the default price list item view to show certain columns like Created By, Created On, Price List (Lookup), Modified By, Modified On. These fields are not available to add on the view, or even on the form.

Did you know?

Comment down below if there is something you discovered that was strange to you.

Set a view as a default view in D365 CE [System User]

With the recent and frequent updates on D365 CE, there are many subtle changes that go un-noticed. The one that I noticed was to be able to setup a view as a default view by a business or system user rather than system admin.

Here are the steps:

• Suppose this is my default Accounts view (Active Accounts) and I want to change it to "My Active Accounts" view.

• Select "My Active Accounts" View.

• Scroll down to the bottom of the list of views and select "Set current view as my default"

• Now there would be a mention of "Default" near "My Active Accounts" view.

Hope that helps!

Contains Data action using Microsoft Flow

A lot has changed in the way Dynamics 365 workflows are created and this is the first of many posts to follow. One of the most common actions that we perform on using Workflows in Dynamics 365 for Customer Engagement is to check a condition, if a record field "Contains Data" or "Does Not Contain Data", which is not available when you create the workflow using Microsoft Flow.

So the question arises, is this even possible? Yes, it is. This is how you do it - step by step.

1. Create a Built-in Condition step.
2. Add your dynamics field (like "Created On"), in the "Choose a Value" box.
3. Select the option "is equal to" in the next box.
4. In the last box "Choose a Value", select Expression
5. Type "null" in the fx (function) box, and select OK.
6. In the "If no" branch, perform your "contains data" action.
7. In the "If yes" branch, perform your "does not contain data" action.

Leave your comments down below, if you found this helpful. Share the post within your social family. Appreciate your support.