We had this exact problem last year. Here’s what worked for us - we implemented proper error handling in the integration that distinguishes between duplicate detection errors and other failures.
For your HR sync scenario, I recommend using the MSCRM.SuppressDuplicateDetection header as Raj suggested. However, implement it with proper validation logic:
// Power Automate HTTP action configuration
Headers:
MSCRM.SuppressDuplicateDetection: true
Prefer: return=representation
This suppresses duplicate detection only for these automated operations while keeping it active for manual entry.
But here’s the critical part - you need to address ALL the integration aspects:
1. Dataverse Duplicate Detection Handling:
The duplicate detection runs before alternate key resolution. By adding the suppression header, you’re telling Dataverse to trust your alternate key logic. Since you’re using employeeid as the alternate key, you already have a reliable unique identifier from your HR system.
2. Power Apps Integration Layer:
Ensure your Power Apps connector or custom connector includes the suppression header in all upsert operations. If you’re using Power Automate, add it to your HTTP action headers. The header is request-specific, so it won’t affect other operations.
3. Alternate Key Upsert Optimization:
Verify your alternate key is properly configured and published:
- Navigate to Power Apps > Tables > Contact > Keys
- Confirm employeeid alternate key status is ‘Active’
- Check the key hasn’t failed indexing (common issue after bulk imports)
If the key status shows ‘Pending’ or ‘Failed’, you’ll need to reactivate it. This might explain why upsert isn’t working as expected.
4. Web API Error Handling:
Implement proper error handling to distinguish between different failure types:
// Error handling logic
if (statusCode == 412) {
// Duplicate detection - log and retry with suppression
} else if (statusCode == 404) {
// Alternate key not found - create new record
}
For your specific error message, the ‘conflictingrecordid’ indicates Dataverse found a match. Since you’re doing an upsert with alternate key, this should actually succeed (updating the matching record), but duplicate detection is blocking it prematurely.
Additional Recommendations:
-
Audit your duplicate detection rules: Review the conditions in your contact duplicate detection rules. You might want to modify them to exclude matches where employeeid values are identical, since that indicates it’s the same logical entity.
-
Implement pre-validation: Before calling the Web API, query Dataverse to check if a record with that employeeid already exists. If it does, use a PATCH operation with the record GUID instead of upsert with alternate key. This bypasses duplicate detection entirely since you’re explicitly updating a known record.
-
Consider batch operations: If you’re syncing multiple contacts, use batch requests with the suppression header. This is more efficient than individual requests and reduces the chance of throttling.
-
Monitor alternate key performance: Large volumes of upsert operations can sometimes cause alternate key index fragmentation. Schedule periodic index maintenance if you’re processing thousands of contacts daily.
The combination of suppression header plus proper alternate key configuration should resolve your onboarding blockage. The key insight is that duplicate detection and alternate key upserts serve different purposes - detection prevents manual data quality issues, while alternate keys enable reliable automated synchronization. They can coexist when you use the suppression header for your integration scenarios.
This draft is based on general Microsoft Dynamics 365 Sales knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.