When implementing Microsoft Dynamics 365 Contact Center, one of the most valuable user experience improvements is phone matching. This accurate and dynamic customer identification is especially important when handling voice calls. Out of the box, D365 only checks a limited set of fields (e.g., telephone1), which can lead to missed matches if a number is stored in another field such as mobilephone or telephone2. Fortunately, you can customize this behavior to check multiple phone number fields using record identification rules.

In this post, I’ll walk you through the why and how of updating phone call matching logic in D365 Contact Center, based on Microsoft’s guidance and a working JSON sample used in real-world deployments.

Why You Should Expand Phone Matching Logic

• Customers often have home, work, and mobile numbers. Limiting identification to a single field limits match success.
• Reducing the time to identify callers results in faster issue resolution.
• Accurate identification enables agents to pull up the correct record immediately.
• Proper identification can tie calls to active cases, accounts, or contacts automatically.

Updating Phone Matching Logic

Understand the Matching Rule Structure

Dynamics 365 uses a record identification rule set defined in XML wrapped in a JSON attribute (msdyn_recordidentificationrule). This fetch-based logic lets you define which entities and fields should be used to find a match for incoming interactions.

Example fields :

• mobilephone
• telephone1
• telephone2
• telephone3

From JSON:

<condition attribute="mobilephone" operator="eq" ... value="${msdyn_fromphone}" />
<condition attribute="telephone1" operator="eq" ... value="${msdyn_fromphone}" />
<condition attribute="telephone2" operator="eq" ... value="${msdyn_fromphone}" />
<condition attribute="telephone3" operator="eq" ... value="${msdyn_fromphone}" />

Modify the Rule Set in D365

1. Navigate to the Customer Service admin center.
2. Go to Workstream Settings > Record identification rules.
3. Locate the rule you want to update or create a new one.
4. Paste in your updated XML logic (like above).
5. Include multiple <condition> entries in the <filter type="or"> block to allow flexible matching.

Use ${msdyn_fromphone} as the dynamic value pulled from the incoming call.

Test With Postman (Optional but Recommended)

To simulate and test your custom API or logic:

• Follow the Postman tutorial from Dynatecon’s blog (linked below).
• Authenticate via Azure AD with Client ID/Secret.
• Use the test call JSON body to validate the identification rules return the expected records.

Example JSON for Matching

Here’s a snippet of the identification rule to match across all key phone fields:


<filter type=”or”>
<condition attribute=”mobilephone” operator=”eq” value=”${msdyn_fromphone}”/>
<condition attribute=”telephone1″ operator=”eq” value=”${msdyn_fromphone}”/>
<condition attribute=”telephone2″ operator=”eq” value=”${msdyn_fromphone}”/>
<condition attribute=”telephone3″ operator=”eq” value=”${msdyn_fromphone}”/>
</filter>

Repeat similar logic for both the contacts and accounts entities, as shown in your JSON payload.

Summary

By extending the phone matching logic in Dynamics 365 Contact Center, you ensure every phone call, regardless of which field the number is stored, has the highest chance of being correctly matched. This improves agent experience, boosts customer satisfaction, and makes your implementation far more robust.

If you’re configuring voice in a multichannel setup or using cases and contacts in parallel, it’s worth spending the time on this update.

Reference Links:

• D365 Contact Center – Custom Field Matching Docs
• Calling a Custom API with Postman (Dynatecon)