Action Duplicates
Overview
- Define what happens to each duplicate pair once processing is complete.
- Configure automatic merges and outbound webhooks.
How Actions Work
When DeDuplica finds a duplicate, it always adds a row to your Duplicates list. What happens next depends on your settings:
- Save Detected Duplicate pair in Deduplica (always on): Every match is saved for your review and records.
- Add to Pending Duplicates table: If you tick this, the duplicate will wait for your approval before any further actions (like merging or webhooks) happen.
- Merge Dynamics/Dataverse records: If you use Dynamics/Dataverse and allow automatic merging, DeDuplica will merge all subordinate records in the cluster into the base record. It determines the base record and then loops through each subordinate sequentially, merging each one into the base following your rules from the Process Duplicates tab. You can decide, for each field, which value to keep or how to combine them. See Process Duplicates for details.
- Invoke webhook: If enabled, DeDuplica will send the merge result to your chosen system or script, so you can automate follow-up actions. See Webhooks Guide for details.
Webhook Action Payload
When a webhook action fires, the payload body contains the cluster-based structure. Key fields relevant to the action:
| Field | Description |
|---|---|
duplicateId | Unique identifier of the duplicate cluster |
baseRecordId | Identifier of the base (master) record |
subordinateRecordIds | Array of identifiers for all subordinate records in the cluster |
mergeOutputJson | The pre-built merge JSON produced by the Process Duplicates configuration |
In short:
- If you want to review every found duplicate, use Pending Duplicates.
- If you want things handled automatically, leave it unticked and DeDuplica will merge and notify as soon as a duplicate is found.
What Does Dynamics/Dataverse “Merge” Actually Support?
Merging in Dynamics/Dataverse is powerful, but there are some important details to know. DeDuplica makes sure only safe, supported data is merged—so you never have to worry about silent errors or data loss.
Supported but Intentionally Skipped
Some fields exist in your data but are managed by the system or not safe to write. DeDuplica will skip these during merge:
| Type | Why Skipped |
|---|---|
| Uniqueidentifier | System-managed |
| PrimaryKey | Not writable |
| CreatedOn, ModifiedOn | System-managed |
| CreatedBy, ModifiedBy | System-managed |
| VersionNumber | Read-only |
| Helper field only | |
| Calculated fields | Not writable |
| Rollup fields | Not writable |
Not Supported (by Design)
Some data types can’t be safely merged through the Dataverse API. DeDuplica will not attempt to merge these, to protect your data:
| Type | Reason |
|---|---|
| Image | Needs separate upload |
| File | Needs chunked upload |
| Virtual | Computed, not stored |
| EntityName | Internal |
| ManagedProperty | Metadata only |
| PartyList | Needs special logic |
| Relationship | Not field data |
✔ Not merging these prevents errors and keeps your data safe.
🧠 How the Merge Works
- Only writable, regular fields are merged.
- Unsupported fields are ignored (not throwing an error).
- The following are not merged: files, images, N:N relationships, activity parties.
- DeDuplica prevents invalid writes, so you don’t get failures from Dataverse for unsupported attributes.
🧪 Edge Cases
Some rare situations can still cause errors, but these are normal and should be visible:
| Edge Case | What Happens |
|---|---|
| OptionSet label passed | ❌ Not supported |
| Lookup GUID not existing | ❌ API failure |
| Wrong ObjectTypeCode | ✔ Fallback |
| Business rule violation | ❌ API failure |
| Plugin throws exception | ❌ API failure |
If something can’t be merged, you’ll see an error in logs—so you always know what’s happening.