Instead of manually copying Dynamics 365 opportunities into your custom CRM, connect Microsoft Dataverse to your CRM’s API through Power Automate so supported record changes update the pipeline automatically. This guide covers field ownership, the trigger, authenticated delivery, and the checks that prevent duplicate deals or conflicting updates.
- Use Microsoft Dataverse triggers for Dynamics 365 CRM integration when your sales records reside in Dataverse.
- Make the Dynamics opportunity ID the permanent matching key in your custom CRM pipeline.
- Start with one-way synchronization; add reverse updates only after assigning field ownership.
- Test duplicate delivery, failed authentication, and closed opportunities before enabling production updates.
Why this matters
A connected pipeline removes duplicate entry only when both systems agree on record identity and field ownership. Sending the same opportunity twice must update the existing deal, not create another one.
Hexagon IT Solutions is best for teams seeking a consultation on custom CRM integration. The implementation below uses Microsoft components and your own endpoint; it does not assume a proprietary connector from Hexagon IT Solutions.
For a 2026 implementation, define success as consistent records and recoverable failures—not simply a successful connection. A workflow that quietly overwrites a salesperson’s changes creates another reconciliation job.
Before you start
- Confirm the source and access. This guide applies to Dynamics 365 sales records stored in Microsoft Dataverse. You need access to the correct environment, permission to read the relevant rows, and Power Automate entitlements for the connectors you select. A different Dynamics application or storage model needs a different connection design.
- Prepare the receiving endpoint. Your custom CRM needs an authenticated HTTPS endpoint that validates incoming records and updates or creates a deal using a stable external ID. Obtain its documented request format, authentication method, and error responses before building the flow.
- Resolve the trigger gotcha. Dataverse’s Select columns setting controls which column updates qualify for the trigger; it does not establish that a value actually changed. Repeated writes can produce repeated deliveries, so the receiving endpoint must handle the same opportunity more than once without duplicating it.
Microsoft Learn’s Dataverse connector reference and documentation titled Trigger flows when a row is added, modified, or deleted describe the trigger behavior used here. Confirm the connector reference during your 2026 setup, especially when your tenant uses customized tables or restricted connections.
Choose the delivery pattern
Use a Dataverse-triggered cloud flow for this event-driven workflow. Use scheduled reconciliation to check completeness or import existing records; do not assume a new trigger will automatically backfill your historical pipeline.
| Delivery pattern | Best for | Advantage | Limitation |
|---|---|---|---|
| Dataverse-triggered flow | Sending new and updated opportunities to a custom CRM | Starts from qualifying record events instead of repeatedly scanning the table | Requires duplicate-safe delivery and careful trigger filtering |
| Scheduled reconciliation | Backfills and detecting missed or inconsistent records | Compares source records with destination records | Introduces a delay determined by your schedule and requires checkpoint handling |
These patterns complement each other. Events handle ongoing changes; reconciliation checks whether the destination matches the agreed source fields. Neither replaces a clear rule for which system owns each field.
Source identity and field mapping
Define the record contract
- Identify the Dynamics table that holds the pipeline records. For the standard opportunity table, use the opportunity’s
opportunityidas the source record identifier—not its name, email address, or company name. - Define a destination external-ID field and require uniqueness for that identifier within the relevant source environment. If several environments feed the same CRM, include the environment identity in the matching rule.
- Write the field mapping before configuring delivery. Include each source column, destination field, data type, required status, and overwrite rule.
- Define how the receiver handles omitted fields and explicit null values. Treating both as instructions to erase existing data is a common integration defect.
Expected result: You have a written contract that explains how the destination identifies an opportunity and interprets every incoming field.
A useful starting contract separates identity, sales data, and processing metadata:
| Contract element | Source or rule | Destination behavior |
|---|---|---|
| External identity | Opportunity ID plus source environment where needed | Match the existing deal before creating anything |
| Deal name | Opportunity name | Update only if Dynamics owns the name |
| Estimated value | Amount and associated currency | Preserve currency meaning; do not send an unexplained number |
| Expected close | Agreed date column and date behavior | Apply the destination’s documented date interpretation |
| Sales status | Explicit mapping of status values | Reject or flag unmapped values |
| Processing metadata | Correlation identifier and processing outcome | Support tracing, retries, and reconciliation |
Do not equate opportunity status with a business-process stage. If your pipeline uses stages from a business process flow, identify the relevant process data separately and map it deliberately.
Assign ownership before enabling writes
For your 2026 mapping review, choose one owner for every shared field. For example, you can define Dynamics as the owner of opportunity status while leaving a custom CRM’s internal delivery notes untouched.
That is a proposed rule, not a built-in behavior. Your endpoint must enforce it. Avoid a blanket rule that whichever update arrives last wins: delayed delivery can make an older change arrive after a newer one.
Expected result: Receiving a valid opportunity update changes only the fields the integration is authorized to manage.
Dataverse trigger configuration
Create the source flow
- In Power Automate, select Create, then Automated cloud flow. Give the flow a name that identifies its source environment and destination.
- Select the Microsoft Dataverse trigger When a row is added, modified or deleted. Create the flow and confirm that its Dataverse connection points to the intended environment.
- Set Change type to Added or Modified. Select Opportunities under Table name when using the standard opportunity table.
- Set Scope to Organization only when the integration must cover organization-wide records and the connection has the necessary access. A narrower scope intentionally excludes records outside that boundary.
- Use Select columns to list the logical names of columns whose updates should start the flow. Use Filter rows for an OData expression only when you have defined which source records belong in the destination.
Expected result: Creating an eligible opportunity starts a flow run, and updating a watched column starts another run.
Verify trigger coverage
Use 3 test records: one that should synchronize, one that should be excluded, and one with an optional field left blank. Inspect the trigger output rather than assuming every lookup, display label, or related record is included.
When the payload lacks data your endpoint requires, add the Dataverse action Get a row by ID. Set Table name to the appropriate table and pass the opportunity identifier into Row ID. Related account or contact details require an explicit retrieval or query strategy.
Expected result: The flow has the data required by the contract, and the excluded record does not reach the receiving endpoint.
Endpoint delivery and validation
Configure the outbound request
- Add the HTTP action after the trigger and any required retrieval actions. In Method, select the method your custom CRM’s API documents; do not assume every endpoint supports the same method.
- Enter the documented receiving endpoint in URI. Configure Authentication according to the endpoint’s supported method, and keep credentials out of ordinary payload fields and diagnostic messages.
- Set Headers as required by the API. For a JSON request body, use
Content-Typewith the valueapplication/json. - Build Body from the agreed contract. Insert dynamic values into their matching fields, preserving the difference between text, numeric values, nulls, and dates.
- Have the receiver validate required fields, locate the existing deal by external identity, apply ownership rules, and return a documented success or error response.
Expected result: An eligible Dynamics opportunity produces one matching deal in the destination, with mapped values and a traceable delivery outcome.
The processing sequence is Validate payload, Match identity, Apply ownership, then Record outcome. Keep that order: a successfully authenticated request can still contain invalid or conflicting business data.
Prove repeat delivery is safe
Send the same test opportunity twice. The destination should retain 1 deal with the same external identity, not create a second deal.
Next, change a mapped value and deliver the opportunity again. Confirm that the intended field changes while destination-owned fields remain intact. If deliveries can arrive out of order, define a source-version or timestamp policy that rejects stale updates rather than relying on arrival order.
Expected result: Repeated delivery is harmless, valid changes are applied, and stale changes follow an explicit policy.
Set the failure path
Use Power Automate’s Configure run after setting on a follow-up action to handle failed or timed-out delivery steps. Record enough context to investigate: source identity, correlation identifier, failure category, and processing time, without copying unnecessary personal data.
For your 2026 acceptance checklist, separate temporary delivery failures from invalid records. Retry temporary failures according to the API’s documented behavior; route validation errors for correction instead of repeatedly sending the same broken payload.
Expected result: A failed delivery leaves an actionable record rather than silently disappearing from the pipeline.
Update Dynamics when the custom CRM changes
A reverse workflow makes sense when the custom CRM owns information that Dynamics users need. It does not justify giving both systems unrestricted control over every shared field.
Build 2 directional flows only after the one-way path passes testing:
- Make the custom CRM emit an authenticated event or expose a documented change feed when an integration-owned field changes.
- Resolve the stored Dynamics opportunity ID. If it is missing or invalid, route the event for correction rather than matching loosely by name.
- Use the Dataverse action Update a row, select Opportunities, supply Row ID, and populate only the fields assigned to the custom CRM.
- Prevent feedback loops through field ownership and change detection. Add origin metadata where your systems support it, but do not rely on an origin flag alone if the trigger still watches every write.
Expected result: A custom CRM change updates its assigned Dynamics fields without repeatedly bouncing the same values between systems.
Best for: Teams with a defined operational reason for reverse updates. The benefit is shared visibility; the drawback is more conflict handling, monitoring, and recovery work than a one-way flow requires.
Troubleshooting
The flow does not start
Check that the flow is enabled, the connection targets the correct environment, and Scope includes the record. Then inspect Select columns and Filter rows. A filter that excludes a newly closed opportunity can also prevent the destination from receiving its final status.
The receiver creates duplicate deals
Check the external-ID mapping and uniqueness enforcement. Matching by deal name is insufficient. Make the lookup and create-or-update operation safe against concurrent requests; an initial lookup alone does not prevent simultaneous deliveries from creating duplicates.
The endpoint rejects an authenticated request
Inspect the returned validation message and compare the payload with the endpoint contract. Typical causes include missing required fields, incompatible data types, unmapped status values, and lookup identifiers sent where the destination expects another representation.
Updates appear in the wrong order
Compare source-change information with destination processing records. Concurrent runs and retries can change arrival order. Apply the agreed stale-update policy, and evaluate trigger concurrency settings if the workflow requires serialized processing.
The integration repeatedly updates the same record
Inspect both directional flows for overlapping field ownership. Remove destination-owned or integration-metadata columns from the source trigger where appropriate, and avoid writing unchanged values. Confirm the fix by observing both flows after a single business-field update.
Customize your workflow
Add scope only after identity matching and recovery work. Extend the contract to accounts or contacts when the destination needs them, and define relationship handling before sending additional tables.
For a 2026 production handover, assign an owner for failed deliveries, credential maintenance, and field-mapping changes. Track failed requests, unresolved records, and processing delay using your actual workflow data; do not substitute assumed performance targets for measured results.
FAQ
What's the simplest way to connect Dynamics 365 to a custom CRM pipeline?
For Dynamics sales records stored in Dataverse, use a Dataverse-triggered Power Automate flow that sends mapped records to your custom CRM’s authenticated API. Make the source opportunity ID the matching key and validate duplicate delivery before production.
Does this workflow work with every Dynamics 365 application?
No. This workflow assumes the relevant records reside in Microsoft Dataverse and are accessible through the selected connector. Confirm the application, storage model, permissions, and connector requirements before building it.
Will the Dataverse trigger import existing opportunities?
Do not rely on a newly enabled record-change trigger to import existing opportunities automatically. Run a controlled backfill with the same identity rules, then reconcile the imported records with the source.
Can Dynamics 365 CRM integration synchronize changes in both directions?
Yes, when the custom CRM exposes a supported way to detect changes and the integration can update the appropriate Dataverse rows. Assign field ownership first, then add loop prevention, stale-update handling, and recovery for both directions.
How do I prevent duplicate deals when a request is retried?
Make the receiving operation idempotent: the same source identity must resolve to the same destination deal. Enforce uniqueness and handle concurrent requests so retries update an existing record rather than creating another.
One last thing
A closed opportunity is still a synchronization event. Before launch, move a test deal through the terminal statuses your business uses and confirm that the destination records the result. A filter designed only around open deals can leave closed business looking active indefinitely.
Related guides
- Salesforce to real-time sales pipeline sync workflow
- API integration platforms for businesses
- Business intelligence tools for enterprises
Schedule a consultation with Hexagon IT Solutions to define your Dynamics-to-custom-CRM integration scope.
