FAQs
1)After importing the solution of DeDupeD from website all the Processes of DeDupeD is in a 'Draft/Deactivated' state. What to do?
Once the solution is imported, please follow the below steps to activate all the processes of DeDupeD.
Click on the gear icon --> Select Advanced Settings.
Next, select Processes.
From 'All Process' View activate the process shown in the below screenshot:
2) Which entity view should be modified to show up columns from a specific entity view when merging the duplicate records?
To view the columns of an entity view on the DeDupeD UI and Windows tool while merging the duplicate records. Select your desired view in the “Entity View” field within “Duplicate Matching Rule Settings”.
For instance, if you select the “All Contacts” view in the entity view field, then you will be able to see the columns of the “All Contacts” view on the DeDupeD app and tool, interface while merging duplicates.
DeDupeD UI: In the below screenshot, you can see how entity view columns appear on DeDupeD app UI.
DeDupeD Tool: In the below screenshot, you can see how entity view columns appear on DeDupeD Tool.
3) I want to check all the duplicates of my entity view records at once. How can I see them?
With DeDupeD’s windows tool, you can easily see all the duplicate records of an entity view at once.
To see all the duplicates of an entity view, follow the steps below:
Once logged into the tool, select any one of the configured entities.
Select the specific entity view for which you want to see the duplicates.
Click on “Find Duplicates” button.
Now you can see all the duplicate records of your selected entity view at once.
4) Can we restrict creating duplicate records while importing them from an Excel sheet?
Yes, with DeDupeD, you can restrict creation of duplicate records while importing data from an Excel sheet.
For this, you will need to enable the Server-Side DeDupeD Settings. Here, you need to select both ‘new record’ and ‘existing record’ plugins to prevent duplicates on events such as creation of new records and updating existing records.
If OOB Duplicate Detection is not disabled you will need to set Allow Duplicates toggle to ‘No’ while importing the Excel Sheet.
5) How to identify the number of users in my CRM that will be considered for licensing?
Step 1: Log in to CRM and open the Sales Hub App
Step 2: Click on the Advance Find Option present in the right top corner (shown below)
Step 3: In the search bar, search for “User” keyword. Select the User entity and click on the Continue button
Step 4: Once clicked, a side panel will show up containing default conditions. Clear the condition by selecting “Delete all Filters” and apply the below conditions in the filter section as shown below
a. Status Equal Enabled
b. Access mode Equal Read-Write
c. Restricted Access Mode Equal No
d. Primary Email address Does not Equal crmoln2@microsoft.com
e. User Licensed Equal yes
Step 5: Add a new related entity condition, where you will find the Security Role option under the Many to many sections as shown below
Step 6: By default, contains data Operator will be selected which will retrieve only those users who have a security role assigned.
Delete the related entity field condition as shown in the screenshot below and then click on the Apply button to provide you with the list of respective users.
6) We have done a sandbox copy of the production environment to a TEST environment and would like to work with the 'DeDupeD' solution in this new instance. What should we do?
For this, you need to delete the Inogic License Details record from your sandbox environment. After deleting, the next step would be to activate the license.
To delete the DeDupeD license follow the steps given below:
Click on the Gear icon and go to Advanced Settings.
Navigate to Advanced Find.
Select Inogic License Details in ‘Look for’ -> Click on Results button.
Select the DeDupeD record and delete it.
7) Unable to Configure the Application Due to Block Unmanaged Customizations in Dataverse?
When installing our solution, it's crucial to address certain prerequisites beforehand to ensure a smooth deployment process. One of these prerequisites involves disabling the "Block Unmanaged Customizations" feature within the Power Platform administrator settings.
Because while configuring our solution, certain required unmanaged customization takes place, for which this setting needs to be turned OFF.
Below are the steps for the same:
To disable this feature, navigate to Power Platform Admin Center and Log in to the Power Platform Admin Center using your administrator credentials.
Navigate to Environments: Select the environment for which you want to disable the setting from the list of available environments.
Access Environment Settings: Within the selected environment, navigate to the "Settings" tab to access environment-specific configurations.
Access to Customization Settings: Navigate to “Product” dropdown & Click on “Features”.
Disable "Block Unmanaged Customizations": Locate the "Customization Settings" section and toggle the "Block Unmanaged Customizations" option to the "Disabled" position.
Save Changes: Once you've disabled the setting, don't forget to save your changes to apply the configuration to the environment.
8) How does the product ensure data security, and does it transfer any data outside the environment where it's stored?
No, we do not store any data on our end. All data is sourced directly from Microsoft through the Out-of-the-Box (OOB) APIs. Our product operates based solely on this data to perform its logic and functions. Consequently, all data processing occurs within the original environment, ensuring that no data is transferred offshore or outside of that environment.
9) How can I set a customized status reason for merged records in DeDupeD?
In DeDupeD, when duplicate records are merged, subordinate records are automatically set to Inactive. If your organization uses custom status reasons—like Lost, Canceled, or Disqualified—this default behavior can cause errors or mismatched statuses. To prevent this, DeDupeD allows you to specify a preferred inactive status reason using the Merged Status Reason Value field.
To configure it:
Go to Advanced Settings → Customizations → Customize the System.
Open the Entity Configuration entity.
Under Forms, select the Main Form of Entity Configuration.
Locate the Merged Status Reason Value field and set its Visibility to Visible by Default.
Click Save and Publish All Customizations.
In your Entity Configuration record, enter the desired inactive status reason (e.g., Lost, Canceled, Disqualified).
Once set, all subordinate records merged into a master record will use your specified inactive status reason instead of the default. This ensures consistent CRM data, avoids status errors, and aligns with your organization’s customized workflow.
10) I am upgrading to v9.0.0.33 or above and have Fuzzy Matching configured. What do I need to do?
In versions below v9.0.0.33, DeDupeD used a single common field to store indexing data for all fuzzy matching conditions, regardless of the column or accuracy level used. So even if you had fuzzy matching set up on multiple columns or accuracy levels, everything was managed through this one shared field. From v9.0.0.33 onwards, DeDupeD creates a separate field for each fuzzy matching condition, based on the specific column and accuracy level configured. For example, First Name at High accuracy and First Name at Medium accuracy are now stored as two distinct fields instead of one shared field. Because of this change, fuzzy matching conditions configured in versions below v9.0.0.33 do not carry forward automatically after the upgrade. To continue using fuzzy matching without issues, follow these steps right after upgrading:
Delete your existing fuzzy matching conditions.
Recreate the same conditions again.
Run indexing for all existing records.
This ensures duplicate detection works correctly with the updated fuzzy matching structure. Note: If you are not using Fuzzy Matching, or if you are already on v9.0.0.33 or later, you can proceed with the upgrade directly, and this does not apply to you.
11) How do I grant the "Bypass Custom Business Logic" (prvBypassCustomBusinessLogic) privilege to a non-System Administrator user?
If you want a non-System Administrator user to perform operations that require bypassing custom business logic (such as custom plug-ins and workflows), you must grant the Bypass Custom Business Logic (prvBypassCustomBusinessLogic) privilege through a custom security role.
Note: This privilege is not available in the standard Security Role editor and must be added using the Dataverse Web API.
Step 1: Create a Custom Security Role
Log in to the Power Platform Admin Center.
Go to Settings → Users + permissions → Security roles.
Click New Role.
Give the role a name (for example, Bypass Plugins Role).
Save the role.
Step 2: Add the Bypass Custom Business Logic Privilege
Open your Model-driven app (for example, Sales Hub).
Press F12 and open the Console tab.
Replace "Bypass Plugins Role" in the script below with the exact name of the role you created.
Paste the following script into the browser console and press Enter.
(async function() {
const roleName = "Bypass Plugins Role"; // Update if required
const privilegeId = "0ea552b0-a491-4470-9a1b-82068deccf66";
try {
const xrmContext =
(typeof Xrm !== 'undefined') ? Xrm :
(typeof parent !== 'undefined' && typeof parent.Xrm !== 'undefined') ? parent.Xrm : null;
if (!xrmContext) {
throw new Error("Could not find Xrm. Please run this from a Model-driven App.");
}
const rootUrl = xrmContext.Utility.getGlobalContext().getClientUrl();
const roleRes = await fetch(
`${rootUrl}/api/data/v9.2/roles?$filter=name eq '${roleName}' and _parentroleid_value eq null&$select=roleid`,
{
headers: {
"Accept": "application/json",
"OData-MaxVersion": "4.0",
"OData-Version": "4.0"
}
});
if (!roleRes.ok) throw new Error(`HTTP ${roleRes.status}`);
const roleData = await roleRes.json();
if (!roleData.value.length) {
throw new Error(`Role "${roleName}" not found.`);
}
const roleId = roleData.value[0].roleid;
const addPrivRes = await fetch( `${rootUrl}/api/data/v9.2/roles(${roleId})/Microsoft.Dynamics.CRM.AddPrivilegesRole`,
{
method: "POST",
headers: {
"Content-Type": "application/json",
"Accept": "application/json",
"OData-MaxVersion": "4.0",
"OData-Version": "4.0"
},
body: JSON.stringify({
Privileges: [{
PrivilegeId: "0ea552b0-a491-4470-9a1b-82068deccf66",
Depth: "3"
}]
})
});
if (!addPrivRes.ok) {
const err = await addPrivRes.json();
throw new Error(err.error?.message || addPrivRes.statusText);
}
console.log("Privilege added successfully.");
}
catch (e) {
console.error(e);
}
})();
Step 3: Assign the Role
Return to Power Platform Admin Center → Users.
Select the user who requires the privilege.
Click Manage security roles.
Assign the custom security role you created.
Save the changes.
Once the role has been assigned, the user will have the Bypass Custom Business Logic privilege and can perform operations that require bypassing custom business logic without needing the System Administrator role.
12) How can I review trace logs for unexpected merge failures in DeDupeD?
If an unexpected merge failure occurs, you can review the relevant logs to identify the details of the merge operation and any errors recorded during execution.
The location of the logs depends on the merge method used.
DeDupeD Logs
Navigate to the DeDupeD application.
Open Logs.
Find the log generated around the time the merge failure occurred.
Open the relevant log and review the Message Block and Stack Trace details (if available).
DeDupeD Merge UI
Navigate to Advanced Settings → Plugin Trace Logs.
Find the trace generated at the time the merge operation was performed.
Filter records where Type Name contains MergeDuplicateProcess.
Open the relevant trace and review the Message Block and Stack Trace details (if available).
Auto Merge
Navigate to Advanced Settings → Plugin Trace Logs.
Find the trace generated at the time the merge operation was performed.
Filter records where Type Name contains AutoMergeProcess.
Open the relevant trace and review the Message Block and Stack Trace details (if available).
Scheduled Merge (CRM Scheduling)
Navigate to Advanced Settings → Plugin Trace Logs.
Filter records where Type Name contains ScheduleJobs.
Find the traces generated when the scheduled merge job was executed.
Review the traces for the following components:
Inogic.DeDupeD.Workflows.ValidateAndCreateScheduleJobs
Inogic.DeDupeD.Workflows.ProcessScheduleJobs
Open the relevant trace and review the Message Block and Stack Trace details (if available).
The scheduled merge execution date and time can help identify the relevant trace entries quickly.
Scheduled Merge (Windows Task Scheduler)
Open the Documents folder.
Open the DeDupeD_Logs folder.
Find the log file generated during the scheduled merge execution. The file name starts with SchedulerTrace_.
Open the log file and review the recorded error details.
DeDupeD Windows Tool
Open the Documents folder.
Open the DeDupeD_Logs folder.
Find the log file generated during the merge operation.
Open the log file and review the recorded error details.
The approximate date and time of the merge operation can help identify the required trace or log entry.
13) Why do I receive a "Duplicate key exists" error while merging records?
This error is generated by Microsoft Dynamics 365 / Dataverse and is not caused by DeDupeD. The error occurs when an entity has an Alternate Key (Unique Key) configured, and the merge operation attempts to update the master record with a value that already exists in another record.
During a merge, DeDupeD updates the master record with selected values from the duplicate record. If this update violates an Alternate Key constraint, Dynamics 365 prevents the update and returns the "Duplicate key exists" error.
How can I prevent this error?
Since Alternate Key fields must maintain unique values, updating them during a merge can cause duplicate key conflicts, add that field to Ignore Fields from Merge in DeDupeD.
When a field is added to Ignore Fields from Merge:
DeDupeD does not update that field during the merge.
The existing value on the master record is retained.
This prevents merge failures caused by duplicate Alternate Key values when the ignored field is responsible for the conflict. If the issue continues, review the Alternate Key configuration and record values in Microsoft Dynamics 365 before retrying the merge.
14) Why can't I merge records when the Master Case is resolved?
If the master Case selected for merging is in a Resolved or Canceled state, Microsoft Dynamics 365 restricts updates to most Case fields.
Since the merge process updates the master record, Dynamics 365 prevents the merge from completing.
Resolution
You can resolve this issue using one of the following options:
Reactivate the master Case, perform the merge, and then resolve the Case again if required.
Update the Service Configuration setting in Dynamics 365:
Navigate to Advanced Settings → Service Management → Service Configuration Settings.
Change Allow updates for from Don't allow updates to Resolved and canceled cases to the required setting.
After making the required changes, retry the merge. This is standard Microsoft Dynamics 365 behavior and is not a limitation of DeDupeD.
15) Why did my DeDupeD job complete successfully, but the email notification failed?
If you receive the following message after a DeDupeD scheduled job completes:
Job completed successfully but email notification could not be sent due to lack of permissions.
The DeDupeD job completed successfully, but DeDupeD was unable to send the email notification.
This occurs when the user configured for email notifications does not have permission to send emails on behalf of other users.
Resolution
To enable email notifications:
Navigate to Personalization Settings.
Open the Email tab.
Enable Allow other Microsoft Dynamics 365 users to send email on your behalf.
Save the changes.
After enabling this setting, run the scheduled job again. The email notification should be sent successfully.
The permission issue affects only email notifications. The DeDupeD scheduled job execution is not impacted.
16) What determines the execution time of a DeDupeD scheduled job?
DeDupeD scheduled jobs run based on the Dynamics 365 Personalization Settings of the user who creates or owns the scheduled job.
The scheduled job does not use the local system time of the user's computer or browser.
If your computer time zone and Dynamics 365 time zone are different, the job runs according to the time zone configured in Dynamics 365 Personalization Settings.
Example
Suppose:
Your computer time zone is UTC+1.
Your Dynamics 365 Personalization Settings are configured for UTC+5:30 (India Standard Time).
You schedule a DeDupeD job for 10:00 AM.
The scheduled job starts at 10:00 AM IST, based on your Dynamics 365 settings, regardless of your computer's local time.
How to ensure the job runs at the expected time
Before scheduling a DeDupeD job, verify that your Dynamics 365 Personalization Settings have the correct time zone configured.
DeDupeD always uses the time zone configured in Dynamics 365 Personalization Settings when executing scheduled jobs.
17) The Windows Task Scheduler is not executing my DeDupeD job. What should I check?
If the Windows Task Scheduler completes successfully but your DeDupeD Duplicate Detection Job is not executed, the issue is typically caused by an incorrect scheduler configuration, Azure Application Registration settings, Dynamics 365 application user permissions, or incorrect Task Scheduler arguments.
To troubleshoot the issue, review the following configuration areas in the order listed below.
1. Verify the Azure Application Registration
Ensure that the Azure Application Registration used by the DeDupeD Scheduler is configured correctly.
Verify the following:
The Application (Client) ID is correct and matches the Client ID configured in the Task Scheduler arguments.
The Directory (Tenant) ID is correct. The Tenant ID is required to verify that the App Registration belongs to the correct Microsoft Entra ID (Azure AD) tenant.
The Client Secret is valid and has not expired.
The Dynamics CRM API permission (user_impersonation) has been added.
Admin Consent has been granted for the required API permission.
The allowPublicClient property in the application Manifest is set to true.
All Azure App Registration changes have been saved successfully.
Note: If the Client Secret has expired or was not copied when it was created, generate a new Client Secret and update it in the DeDupeD Scheduler configuration.
2. Verify the Application User in Dynamics 365
Ensure that the Azure Application Registration has been added as an Application User in the same Dynamics 365 environment.
Verify that:
The Application User exists.
The Application User corresponds to the Azure Application Registration being used.
The System Administrator security role has been assigned.
The scheduler requires these permissions to authenticate and execute Duplicate Detection Jobs successfully.
3. Verify the Task Scheduler Arguments
Review the command-line arguments configured in the Windows Task Scheduler.
Verify that:
The CRM URL is correct.
The Client ID is correct.
The Client Secret is correct and has not expired.
The Duplicate Detection Job ID is correct.
The Job ID belongs to a Duplicate Detection Job where Run Scheduler via Tool is enabled.
All required parameters are provided.
There are no missing quotation marks, extra spaces, or formatting issues.
Example:
--crmUrl "https://xxxxxx.crmx.dynamics.com/" --clientId "f8abcdefcda3-d8af-4511-9898-333185daabb22" --clientSecret "qQ28P~nYtzfQsCGsyoJyJVMk~fWGW0JB7BPOhawk" --duplicateDetectionJobId "c81afd37-0f2c-f011-8c4d-7ced8d27d1b1
4. Verify the Scheduler Logs
After the scheduled task runs, verify whether scheduler log files have been generated.
Navigate to:
Documents → DeDupeD_Logs
Look for log files beginning with:
SchedulerTrace*
If log files are available:
Review the latest SchedulerTrace log for authentication, configuration, or execution errors.
Use the log details to identify the cause of the issue.
5. Check Windows Event Viewer
If no SchedulerTrace logs are generated:
Open Event Viewer.
Navigate to Windows Logs → Application.
Look for any errors related to DeDupeD.
Review the error details to identify any issues preventing the scheduler from executing.
If the issue persists after completing the above checks, contact the DeDupeD Support Team and share the latest SchedulerTrace log (if available) or any relevant Windows Event Viewer error details for further investigation.
18) Can I see who initiated the merge on the DeDupeD Job Run record?
Yes. You can identify the user who initiated the merge from the DeDupeD Job Run record.
A DeDupeD Job Run record is created for each merge operation to maintain the merge statistics and execution details. The Job Run record contains a reference to the user who initiated the merge.
To identify the user who initiated a merge:
Open the relevant DeDupeD Job Run record.
Locate the Merge Initiated By field.
The field displays the name of the user who initiated the merge.
Therefore, the DeDupeD Job Run record provides an audit reference for identifying who initiated the merge, regardless of whether the merge was performed directly by the user or through admin impersonation.
Last updated
Was this helpful?