Over the past few months, Copilot has become one of the most talked-about features in the Microsoft ecosystem. But one thing still confuses many people:

There are actually two different Copilot experiences available in Microsoft 365.

• Microsoft 365 Copilot – the paid add-on
• Copilot Chat – the free chat experience included with Microsoft 365

At first glance, they look almost identical. Both allow you to type prompts and get responses from AI.

However, when you try to use them in a real business scenario, especially inside CRM, the difference becomes very clear.

Recently, I experimented with both tools using a practical Dynamics 365 CRM scenario, and the results made the distinction crystal clear.

If you work in Sales, Customer Service, Consulting, or Project Delivery, this comparison will help you understand which Copilot actually makes a difference.

The Problem: AI That Can’t See Your Work

In most organizations, information about a customer is spread across multiple systems.

For example, in a typical CRM workflow you might have:

• Customer emails in Outlook
• Meeting notes from calendar events
• CRM notes and activities
• Service cases
• Tasks and follow-ups
• Internal discussions
• Documents and attachments

When you ask AI to summarize a customer opportunity or identify risks, it needs access to all of this context.

But not every Copilot has that visibility.

To understand the difference, I created a simple real-world test scenario inside CRM.

What Is the Difference Between Copilot Chat and Microsoft 365 Copilot?

Copilot Chat is a general-purpose AI assistant that works only with user-provided prompts.

Microsoft 365 Copilot, on the other hand, integrates with Microsoft Graph to access organizational data such as emails, meetings, documents, and CRM records allowing it to generate context-aware insights.

The Use Case: A Real CRM Opportunity

To test both Copilot experiences, I recreated a realistic opportunity inside CRM.

Here’s the setup:

• Account: Contoso Retail Group
• Primary Contact: Sarah Thompson
• Opportunity: Contoso POS Upgrade Project

To simulate a real project, I added different pieces of information across the system:

• Email conversations with the engineering team discussing migration constraints
• Opportunity notes describing the migration strategy and potential risks
• Meeting notes covering API readiness and dashboard activation timelines
• Tasks related to preparing proposals and scheduling pilot migrations
• A service case linked to the account about previous POS downtime

In short, this was a normal customer project scenario where information exists in many places.

The Prompt I Asked Both Copilots

Once everything was ready, I asked both copilots the exact same question:

“Summarize the Contoso POS Upgrade Opportunity using emails, notes, meeting notes, case details, and tasks. Include customer concerns, risks, and next steps.”

What Happened with Copilot Chat

When I asked Copilot Chat, the response was polite but limited.

It replied that Sorry, I don’t know that one yet, but I’m always learning.

 In simple terms, Copilot Chat had no visibility into the opportunity context.

Copilot Chat is still useful for tasks like:

• Writing content
• Brainstorming ideas
• Creating templates or plans
• Explaining general concepts

But when it comes to understanding your day-to-day work inside business systems, it simply doesn’t have access to the necessary information.

What Happened with Microsoft 365 Copilot

Next, I ran the same prompt using Microsoft 365 Copilot.

The difference was immediate.

In simple terms, Microsoft 365 Copilot understands your work context by connecting to organizational data across the Microsoft ecosystem through Microsoft Graph. This allows it to automatically gather insights from emails, meetings, documents, notes, tasks, files, and conversations within the Microsoft 365 environment. Using this connected context, Copilot was able to generate a much richer and more meaningful summary of the opportunity.

The output included insights such as:

From Emails

• Planned migration downtime window
• Deployment approach using store batches
• Customer concerns about weekend disruptions

From CRM Notes

• Engineering feedback on legacy scripts
• Risk related to unsynced transactions
• Offline billing requirements

From Meeting Notes

• API integration readiness
• Estimated dashboard activation time

From Tasks

• Preparing customer update communication
• Scheduling pilot migration
• Updating proposal documentation

From the Service Case

• Previous POS downtime incidents
• Early signs of customer frustration

The summary felt less like a chatbot response and more like something a project analyst might prepare before a stakeholder meeting.

Copilot Chat vs Microsoft 365 Copilot: Key Differences

Feature	Copilot Chat	Microsoft 365 Copilot
Access to CRM Data	No	Yes
Microsoft Graph Integration	No	Yes
Context Awareness	Primarily in‑chat only	High
Data Sources	Manual input only	Emails, meetings, CRM, tasks
Best Use Case	Writing & brainstorming	Business workflows & decision-making

Why This Matters for CRM Professionals:

CRM work rarely lives in a single record.

Important information about a customer often exists across:

• emails
• meetings
• internal discussions
• notes
• cases
• tasks

To truly understand the situation, you need to connect all those pieces together.

That’s exactly what Microsoft 365 Copilot is designed to do.

Instead of analyzing one piece of information at a time, it can combine insights from multiple sources and provide a complete picture of the situation.

Copilot Chat, on the other hand, only understands the information you manually paste into the chat window.

Final Thoughts

Copilot Chat and Microsoft 365 Copilot may look similar, but they serve very different purposes.

Copilot Chat is great for general AI assistance like writing, brainstorming, and answering questions.

Microsoft 365 Copilot, on the other hand, connects directly to your organization’s data and understands the context of your work.

For professionals working in sales, consulting, customer service, or project delivery, that difference can dramatically improve productivity.

Instead of manually gathering information from multiple systems, Microsoft 365 Copilot helps you see the full picture and act faster.

And in customer-facing roles, having that complete context can make all the difference.

FAQ: Copilot Chat vs Microsoft 365 Copilot

Q: Can Copilot Chat access Dynamics 365 CRM data?
No, Copilot Chat cannot access CRM data unless you manually provide it in the prompt.

Q: What makes Microsoft 365 Copilot different?
Microsoft 365 Copilot integrates with Microsoft Graph to access emails, meetings, documents, and CRM data, enabling context-aware insights.

Q: Is Microsoft 365 Copilot worth it for CRM users?
Yes, especially for sales, service, and consulting teams who rely on insights across multiple systems.

The post Microsoft 365 Copilot vs Copilot Chat: Key Differences for Dynamics 365 CRM Users first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

Integrating Dynamics 365 CRM with SharePoint is essential for modern document management. But most organizations overlook a critical issue until it’s too late:

Your CRM security model does not extend to SharePoint.

When you use the out-of-the-box Dynamics 365 SharePoint integration, ALL users can see ALL documents in SharePoint, regardless of the security roles you have carefully configured in Dynamics 365 CRM. Your CRM permissions simply do not carry over. A salesperson restricted to their own account records in CRM can freely browse other accounts’ documents in SharePoint. In other words, your document security becomes disconnected from your CRM security model.

This is not a theoretical risk. It is a real data security and compliance issue that affects businesses worldwide, especially those dealing with sensitive customer data, financial records, legal documents, or GDPR-regulated information.

Key Takeaways

• Native Dynamics 365–SharePoint integration does not carry over CRM security permissions.
• This creates a serious data exposure risk, where users can access documents they shouldn’t.
• Microsoft’s native setup enables integration, but does not solve the security gap.
• SharePoint Security Sync automatically replicates CRM roles and permissions into SharePoint.
• Any changes in CRM (roles, ownership, teams) are reflected in SharePoint in real time.
• The result: a secure, unified document management experience with zero manual effort.

In this guide, you’ll learn:

1. How to set up the native Dynamics 365 CRM and SharePoint integration step by step
2. How to replicate your CRM security roles and permissions directly into SharePoint, closing the permissions gap permanently

Part 1: Setting Up the Native Dynamics 365 and SharePoint Integration

This section covers the baseline Microsoft server-based SharePoint integration.

Step 1: Enable Server-Based SharePoint Integration

Step 1.1: Navigate to Document Management Settings
In Dynamics 365, go to Settings (the gear icon at the top right) → Advanced Settings → System → Document Management → Configure Server-Based SharePoint Integration.

Step 1.2: Select SharePoint Online
In the integration wizard, choose Online when prompted for your SharePoint location.
Note: The On-premises option is intended for Dynamics 365 On-Premises environments and will be disabled if you are using Dynamics 365 Online.

Step 1.3: Enter and Validate Your SharePoint Site URL
Paste the URL of your SharePoint site (e.g., https://yourcompany.sharepoint.com/sites/CRM). Click Next, and the wizard will validate the URL automatically.

Step 1.4: Complete the Wizard
Once validation passes, click Finish to enable the server-based integration. Important: Once server-based integration is enabled, you cannot revert to client-side integration.

Step 2: Configure Document Management Settings
After enabling the integration, you need to define which CRM entities will store documents in SharePoint and configure the folder structure.

Step 2.1: Open Document Management Settings
Return to the Document Management screen and click Document Management Settings. A wizard will open where you can select which entities (e.g., Account, Contact, Opportunity, Case) will have SharePoint document storage enabled.

Step 2.2: Select Entities

Check all entities for which you want to store documents in SharePoint. You can follow the defaults suggested by the wizard or customize based on your business processes. Click Next when ready.

Step 2.3: Validate the SharePoint URL Again

Re-enter and validate your SharePoint site URL. Once marked as valid, proceed to the next step.

Step 2.4: Define Folder Structure
Choose how folders will be organized in SharePoint.

Step 2.5: Finish
Click Finish. The wizard creates document libraries in SharePoint for your selected entities. You will see a Documents tab appear on those entity records in Dynamics 365.

Your integration is now live, but your data is still exposed.
SharePoint does not respect your Dynamics 365 security model.

This builds urgency to continue reading.

Part 2: Configuring SharePoint with Dynamics 365 CRM to Replicate CRM Permissions

To close this security gap, you need a solution that synchronizes CRM security with SharePoint in real time.
SharePoint Security Sync by Inogic is a purpose-built Dynamics 365 app that automatically syncs CRM security privileges with SharePoint without any additional cost to purchase a VM machine or Azure credits.
Any change to a user’s security role in Dynamics 365 is automatically reflected in SharePoint, with no manual work required.

Step 1: Connector Configuration — Connecting to Your SharePoint Site
The Connector is the link between Dynamics 365 and your SharePoint site. SharePoint Security Sync supports multiple connectors, allowing you to connect to multiple SharePoint sites (e.g., SharePoint_1, SharePoint_2, SharePoint_3), each pointing to a different SharePoint site URL.

Step 1.1: Create a New Connector
Navigate to the SharePoint Security Sync App in Dynamics 365. Click on the Connectors entity in the left navigation, then click New to create a new Connector record.

Step 1.2: Fill in Connector Fields
Populate the following required fields:

• Name: Give your connector a clear name (e.g., SharePoint_Primary)
• Connector Type: Select SharePoint from the dropdown
• Default Connector: Enable this checkbox if this is your primary connector
• SharePoint Site: Select the valid SharePoint site URL where files will be stored

Note: Each connector must point to a unique SharePoint site. You cannot reuse the same SharePoint site across multiple connectors.

Step 1.3: Select Authentication Type

• App (Azure AD App Registration): Authentication via Azure Active Directory app. When any action is performed, the logged-in user’s name appears, providing true user-level audit trails.

Step 1.4: Authenticate the Connector
Once the Connector record is saved, click the Authenticate button on the command bar.

This button is only visible to users with System Administrator or SharePoint Security Sync Administrator roles.

Once authenticated, it will show a pop-up for successful authentication.

Step 2: Configuration for Mapping CRM Entities to SharePoint

Entity Configuration defines which Dynamics 365 entities (Account, Contact, Opportunity, Case, etc.) are connected to SharePoint through a specific connector, and how their documents are handled.

Step 2.1: Navigate to Entity Configurations
Go to SharePoint Security Sync → Entity Configurations, and click New. Alternatively, open your Connector record and click on the Entity Configuration tab, then click + New.

Step 2.2: Fill in the General Tab
Populate these fields:

• Connector: Select the connector you created in Step 1
• Entity Name: Choose the CRM entity (e.g., Account, Opportunity)
• Attachment Action:
  – Copy: Attachment is copied to SharePoint; the original remains in CRM
  – Move: Attachment is migrated out of CRM to SharePoint permanently
  – None Selected: Attachments stay in CRM, but the Attach2Dynamics document UI is still available
• Override Files: If enabled, uploading a file with the same name replaces the existing file. If disabled, a new versioned copy is created.
• Auto Create Folder: Set to Yes to automatically create a SharePoint folder for each new record in this entity.

Step 2.3: Configure Custom Folder Structure (Optional)
SharePoint Security Sync allows you to define exactly how document libraries and record folders are organized in SharePoint. In the Create Custom Folder Structure tab:  Library Structure options:

• By Period: Libraries created based on date periods (Monthly, Quarterly, Yearly, or custom X Month / X Year inter

• By Starting Character: Libraries named based on the first character of a chosen field
• Custom: Libraries named based on the full value of any chosen field (text, option set, or lookup). Record Folder Format: Use any combination of field logical names in curly braces and static text.

For example: {name} Documents would create a folder named after the record’s name, followed by the word ‘Documents’.

Step 2.4: Save the Entity Configuration
Click Save. The security privilege synchronization for this entity will begin automatically the next time a user accesses the Files tab or clicks the Attach2Dynamics button on a record of this entity type.

Step 3: Configuring Hierarchy-Based Folder Structure (Optional)

If you want documents from related entities (e.g., Opportunities linked to an Account) to be stored in a hierarchical folder structure in SharePoint, you can configure this through Dynamics 365 Document Management Settings.

Step 3.1: Set Up Hierarchy in CRM
In Dynamics 365, go to Advanced Settings → Settings → Document Management Settings. Select the entities, enter your SharePoint URL, enable the ‘Based on Entity’ checkbox, and choose Account or Contact as the parent entity. Click Next and then Finish.

Step 3.2: Configure Entity Configuration for Hierarchy
In SharePoint Security Sync, create or edit an Entity Configuration for the related entity (e.g., Opportunity). In the Folder Structure Fields field, which appears when hierarchy is configured, select the parent entity (Account or Contact). Click Save.

Conclusion

Without security synchronization, SharePoint becomes a blind spot in your CRM architecture.
With the right setup, it becomes a secure extension of your Dynamics 365 environment.

Integrating Dynamics 365 CRM with SharePoint is one of the most impactful steps you can take to improve document management, reduce CRM storage costs, and enhance team collaboration. The native Microsoft integration makes this connection easy to establish, but it leaves a critical security gap that puts your sensitive data at risk.

SharePoint Security Sync by Inogic closes that gap permanently by automatically replicating your CRM security roles, business unit structures, and record-level access controls into SharePoint.

The good news is, you don’t need to purchase any Azure credits or additional VMs.

The result is a secure, unified environment where what users can see in CRM exactly matches what they can access in SharePoint, automatically, in real time, with no manual administration overhead.

Learn More & Get Started

Explore the full SharePoint Security Sync tool from the Inogic Website or Microsoft Marketplace. For enterprise licensing, demos, or technical queries, reach out to the Inogic team at crm@inogic.com.

The post How to Integrate Dynamics 365 to Replicate CRM Security Permissions with SharePoint first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

Organizations frequently receive employee requests for training programs, certifications, or skill-development courses. Traditionally, these requests go through manual review and approval processes which can delay decision making and create administrative overhead.

With Advanced Approvals in Microsoft Copilot Studio, it is possible to automate such decisions using AI. Instead of relying on human approval stages, AI can evaluate the request details and decide whether the request should be approved or rejected based on predefined criteria.

In this article, we will build a Training Request Approval System where:

• A user creates a training request record in Dataverse
• An AI approval stage evaluates the request
• The AI automatically approves or rejects the request

This implementation demonstrates how AI-driven approvals can automate business decisions without human intervention.

Prerequisites

Before starting, ensure the following are available:

• Access to Microsoft Copilot Studio
• A Power Platform environment with Dataverse enabled
• Basic knowledge of Dataverse tables and Copilot Studio agent flows

Solution Overview

The workflow implemented in this article follows a simple structure.

1. Employee submits a training request
2. The request is stored in Dataverse
3. AI evaluates the request
4. The system updates the approval status

This removes the need for manual manager approvals and allows faster decision making.

Step 1: Create a Dataverse Table for Training Requests

First, create a Dataverse table that will store the training requests.

Example table: Training Requests

Suggested columns:

This table will be used by the AI flow to read and update request details.

Step 2: Create an Agent Flow in Copilot Studio

Navigate to Copilot Studio → Agent Flows and create a new flow.

Agent flows allow you to automate processes using AI and actions connected to data sources like Dataverse.

In this implementation, the agent flow will:

• Retrieve the training request
• Evaluate the request using AI
• Update the request status.

Agent Flow creation screen in Copilot Studio

Step 3: Configure the Multistage Approval Step

Add the Run a multistage approval action in the flow.

This feature allows AI to evaluate requests based on specific instructions.

Since this implementation focuses on AI-only approval, no manual stages are added.

The flow will only contain the Evaluate Request AI stage.

Run a multistage approval (preview) configuration screen

Step 4: Define AI Evaluation Instructions

Inside the Evaluate Request step, define clear instructions for the AI model so it knows how to evaluate the request.

Example instructions:

Evaluate the employee training request and decide whether it should be Approved or Rejected.

APPROVE the request if ALL of the following are true :

– The trainingCost <= 1000.00

– trainingStartDate is after the date the course is purchased (i.e. coursePurchaseDate)

– The request contains all required details including employeeName, courseName, trainingCost, and trainingStartDate.

REJECT the request if any of the above are false.

Note: Here trainingCost, trainingStartDate, employeeName, courseName, coursePurchaseDate are dynamic fields as shown below in the image

These instructions guide the AI model to consistently evaluate each training request.

AI instruction configuration inside the Evaluate Request stage

Step 5: Update the Dataverse Record

After the AI evaluates the request, configure the next step in the flow to update the Dataverse record.

Based on the AI decision:

• If Approved → Update Approval Status to Approved
• If Rejected → Update Approval Status to Rejected

This ensures the final decision is stored directly in Dataverse.

Dataverse Update Row action in the flow

Testing the AI Approval Process

Once the flow is configured:

1. Create a new training request record
2. Trigger the agent flow
3. Observe the AI evaluation
4. Verify that the Approval Status updates automatically

This demonstrates how AI can independently make approval decisions based on defined rules.

Dataverse Update Row action flow when all conditions are met / true

Dataverse Update Row action flow when all conditions are not met / false

Example training request record before and after AI evaluation

Challenges You May Encounter

While implementing AI approvals in Copilot Studio, you may encounter some configuration challenges.

1.Writing Effective AI Instructions

The AI model relies heavily on the instructions provided. If instructions are vague, the decision may be inconsistent.

To avoid this:

• Clearly define approval and rejection conditions
• Keep the logic simple and structured.

2.Mapping Dataverse Fields

Incorrect field mapping between the agent flow and Dataverse may prevent the AI from reading request data correctly.

Always verify:

• Column names
• Data types
• Input parameters passed to the AI stage.

3.Understanding AI Decision Outputs

The AI stage returns structured output which must be correctly interpreted when updating Dataverse records. Improper condition checks may cause incorrect status updates.

4.Preview Feature Limitations

The Multistage Approval feature is currently in preview, so some UI elements or configurations may change over time.

Benefits of AI-Driven Approvals

Implementing AI-based approvals provides several advantages:

• Faster decision making
• Reduced dependency on manual approvals
• Scalable automation
• Consistent evaluation logic
• Seamless integration with Dataverse

Conclusion

Advanced approvals in Microsoft Copilot Studio open new possibilities for automating decision-based workflows. In this example, we built a Training Request Approval System where AI evaluates each request and determines whether it should be approved or rejected.

FAQs: Automating Training Request Approvals with AI in Microsoft Copilot Studio

• What is AI-driven approval in Microsoft Copilot Studio?
  AI-driven approval in Microsoft Copilot Studio automates the decision-making process for requests, such as employee training requests. Instead of waiting for human manager approval, AI evaluates the request based on predefined rules and updates the approval status automatically in Dataverse.
• How does the training request approval system work?
  The system works in a few steps:

1. An employee submits a training request in Dataverse.
2. The AI agent flow in Copilot Studio retrieves the request.
3. The AI evaluates the request against predefined approval criteria.
4. The AI updates the request status as Approved or Rejected.

• What are the prerequisites for setting up AI approval in Copilot Studio?
  To implement AI-based training approvals, you need:

1. Access to Microsoft Copilot Studio.
2. A Power Platform environment with Dataverse enabled.
3. Basic knowledge of Dataverse tables and Copilot Studio agent flows.

• Can AI completely replace human approval for training requests?
  Yes, AI can handle approval entirely if the evaluation logic is clearly defined. AI ensures faster, consistent, and scalable approvals, reducing administrative overhead. However, organizations can still add manual review stages if needed.

The post Automating Training Request Approvals Using AI in Microsoft Copilot Studio first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

If you manage a Dynamics 365 CRM environment, duplicate records are not just an inconvenience; they are an active threat to your business operations, marketing ROI, AI insights, and customer experience. Duplicate Dynamics CRM data inflates your record counts, confuses your sales team, triggers redundant email campaigns, and erodes trust in every report and dashboard you build.

Consider these real-world consequences of failing to deduplicate Dynamics 365:

• Sales reps calling the same prospect multiple times from separate records
• Marketing campaigns sending duplicate emails, damaging your sender reputation
• Finance teams generating double invoices for the same customer
• Analytics showing inflated pipeline numbers due to duplicate opportunities
• Customer service agents are unable to see a unified history across duplicate contacts

Industry research consistently shows that between 10% and 30% of CRM records contain some form of duplicate data. In Dynamics 365 environments that have been running for several years without proactive Dynamics CRM data cleansing, this figure can exceed 40%.

What Are Duplicate Detection Rules in Dynamics 365?

Duplicate detection rules in Dynamics 365 CRM are customizable logic definitions that instruct the system on how to determine if two or more records represent the same real-world entity. When a user creates or updates a record, the system checks it against these rules and alerts the user if a potential duplicate is found.

The duplicate detection framework in Dynamics 365 works on three levels:

• Real-Time Detection: When a user saves a new or updated record, Dynamics 365 checks it against published duplicate detection rules and displays a warning dialog listing potential duplicates. The user can still save the record, but the warning prompts human review.
• Bulk Duplicate Detection Jobs: Administrators can run scheduled or on-demand bulk jobs that scan entire entity datasets, all Contacts, all Leads, or all Accounts, to surface existing duplicate Dynamics 365 records that entered the system before rules were published, or that slipped through manual entry.
• Duplicate Detection During Data Import: When importing records via the Dynamics 365 import wizard, the system can apply active duplicate detection rules to flag or skip records that would create duplicates, protecting Dynamics 365 data accuracy during bulk data loads.
• Understanding Matching Rules and Conditions: The most powerful part of Dynamics 365 duplicate detection is the matching conditions engine. Each condition in a rule compares field values between two records, and you can add multiple conditions to create sophisticated logic for detecting duplicate Dynamics 365 records.

Limitations of Native Duplicate Detection in Dynamics 365

While the built-in duplicate detection framework is a solid starting point, it has meaningful limitations for organizations dealing with large volumes of Dynamics CRM data or complex deduplication requirements:

• No fuzzy matching: native rules only support exact or prefix-based matching. ‘John Smith’ and ‘Jon Smyth’ will not be caught as duplicates.
• No phonetic matching: names that sound alike but are spelled differently (e.g., ‘Catherine’ vs ‘Kathryn’) are not detected.
• No cross-entity deduplication: you cannot natively detect that a Contact and a Lead represent the same person.
• Limited merge control: the native merge UI merges two records at a time and gives limited control over which field values are retained from each record.
• No bulk merge: you cannot select 50 duplicate pairs and merge them all in one operation.
• No preview of merge result: you cannot see what the merged record will look like before committing.
• No duplicate dashboard: there is no centralized view showing your overall duplicate health score.
• Performance on large datasets: bulk jobs on very large entity sets (100,000+ records) can be slow and resource-intensive.

These limitations are why many Dynamics 365 administrators and architects turn to dedicated solutions like DeDupeD by Inogic, a purpose-built duplicate merge tool for Dynamics 365 that addresses all of the above gaps.

Advanced Duplicate Identification Tool for Dynamics 365: DeDupeD by Inogic

DeDupeD is an advanced deduplication app, built natively for Dynamics 365 CRM, that provides end-to-end deduplication capabilities, from intelligent detection to controlled merging. It is the go-to solution for organizations serious about Dynamics 365 data accuracy and Dynamics CRM data cleansing.

What Makes DeDupeD Different?

• Fuzzy Matching: detects duplicates even when names, addresses, or phone numbers are slightly different due to typos, abbreviations, or formatting variations
• Phonetic Matching: identifies records that sound alike, catching duplicates like ‘Kathryn’ and ‘Catherine.’
• Cross-Entity Matching: detect duplicate Dynamics CRM records across entities, such as matching a Lead to an existing Contact
• Bulk Merge with Preview: select hundreds of duplicate groups and merge them all at once, with full control over which field values survive the merge
• Configurable Matching Rules: build sophisticated multi-field, multi-condition rules that go far beyond what native Dynamics 365 detection supports
• Duplicate Dashboard: a central view showing your overall duplicate record count, trends over time, and entity-by-entity breakdown
• Master Record Control: define rules that automatically determine which record is the ‘master’ (e.g., oldest record, most recently updated, or record with the most related activities)
• Role-Based Access: control which users can view, approve, or merge duplicate records

How DeDupeD Identifies Duplicate Records in CRM

DeDupeD uses a multi-layered approach to identify duplicate records in Dynamics 365 CRM. Understanding how it works helps administrators configure it optimally:

The Identification Process

1. Rule Evaluation: Each record is evaluated against all active DeDupeD matching rules for its entity type.
2. Score Calculation: DeDupeD calculates a similarity score for each pair of records based on how many conditions match and how closely the field values align.
3. Threshold Filtering: Only record pairs that meet or exceed the configured similarity score threshold are surfaced as potential duplicates.
4. Grouping: Duplicate pairs are grouped into clusters so you can see all records representing the same entity at once, not just individual pairs.
5. Review Queue: Identified duplicates are placed into a review queue where authorized users can compare, approve, and merge them.

Real-Time vs. Background Duplicate Detection

DeDupeD supports both modes. Real-time detection warns users the moment they create or edit a record. Background jobs scan your entire dataset on a schedule to catch existing duplicates that entered the system through integrations, data imports, or manual entry before rules were active.

Setting Up Duplicate Matching Rules in DeDupeD

Here is how to configure duplicate matching rules and conditions in DeDupeD to detect duplicate Dynamics 365 records effectively:

Step 1: Install and Configure DeDupeD

• Install DeDupeD from Microsoft Marketplace or the Inogic Website into your Dynamics 365 environment
• Assign the DeDupeD Administrator security role to your configuration team
• Open the DeDupeD app from the Dynamics 365 app switcher

Step 2: Create a New Deduplication Rule

• Navigate to DeDupeD → Configuration → Matching Rules
• Click New Rule
• Select the Target Entity (e.g., Contact)
• Enter a Rule Name and Description
• Set the Rule Status to Active

Step 3: Add Matching Conditions

For each condition you want to add:

• Click Add Condition
• Select the Field to compare (e.g., Email Address)
• Choose the Match Type: Exact, Fuzzy, Phonetic, Contains, Starts With, Ends With, or Custom
• Set the Weight — this determines how much this condition contributes to the overall similarity score
• Optionally enable Ignore Blanks — if either record has a blank value for this field, skip the condition rather than failing the match

Step 4: Set Up Matching Rule Conditions for Specific Scenarios

Scenario: Detecting Duplicate Contacts by Email

• Field: Email Address | Match Type: Exact | Weight: 60
• Field: Last Name | Match Type: Fuzzy | Weight: 20
• Field: First Name | Match Type: Phonetic | Weight: 20
• Threshold: 60 (matches on email alone are sufficient)

Step 5: Publish and Run

• Click Save and Publish to activate the rule
• Navigate to DeDupeD → Jobs → New Job
• Select the rule(s) to apply
• Choose the record scope (All Records, Records created in last 30 days, etc.)
• Click Run Now or Schedule for recurring execution

Conclusion

Duplicate records are one of the most damaging yet solvable problems in any Dynamics 365 CRM environment. With a well-configured set of duplicate detection rules and a clear process for reviewing and merging identified duplicates, you can dramatically improve Dynamics 365 data accuracy, sales team efficiency, and the reliability of your CRM reports.

Ready to remove duplicate Dynamics 365 data at scale?

Explore DeDupeD at the Inogic Website or Microsoft Marketplace to start a free trial and see how it can transform your Dynamics 365 data quality today.

Need more details or an end-to-end execution tour? Reach us at crm@inogic.com.

The post Duplicate Identification Rules for Dynamics 365 CRM: A Complete Guide 2026 first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

Today’s businesses rarely operate within a single application. Applications such as Sales Hub, which manage leads, opportunities, accounts and revenue to help sales teams close deals faster. On the other hand, Customer Service helps handle cases, tickets and customer support interactions to deliver faster issue resolution. Field Service is used to schedule technicians, manage work orders and track on-site services efficiently. Marketing Automates campaigns, emails, and customer journeys to generate and nurture leads. Project Operations plans, tracks, and bills projects by combining project management, resources, and financials in one system.

Here, each application works well individually, but together they often feel disconnected. Users need to switch between platforms, copy information manually, and spend more time navigating systems than actually solving problems. Even with AI copilots available, the experience doesn’t always improve because most copilots are still limited to one application at a time.

Key Takeaways

• Traditional copilots are limited to single applications
• MCP Server enables structured, cross-system interactions
• Copilot agents can execute workflows across Business Central, Dataverse, and SharePoint
• Reduces manual effort and system switching significantly

Limitations of Traditional Copilots:

Traditional copilots are helpful assistants, but their scope is short. They can answer questions, summarize information or perform small actions within the app they belong to. However, they struggle when there are tasks that require answers from multiple systems.

As a result, users still do most of the work manually. The copilot informs but it doesn’t truly execute.

What is MCP Server in Copilot? (Simple Explanation)

MCP (Model Context Protocol) Server provides a structured way for copilots to interact with multiple systems using predefined tools instead of direct API calls.

Copilot with MCP Server:

To make Copilot genuinely useful, it needs accessibility across multiple systems. This is where Microsoft Copilot, combined with the Model Context Protocol (MCP) comes into the picture.

MCP Server acts as a bridge between Copilot agents and enterprise tools. Instead of directly accessing databases or API’s in an unstructured way, the agent communicates through standardized tools exposed by the MCP server. These tools define exactly what the copilot needs to do. Whether it’s retrieving data or updating records.

MCP Server with different Systems:

With MCP Server, the copilot can interact with different platforms such as Microsoft Dynamics 365 Business Central, Microsoft Dataverse and Microsoft SharePoint.

Instead of treating each system separately, the copilot works across them as if they were one connected environment. For the user, it feels like interacting with a single intelligent assistant.

Key Criteria to Consider While Setting Up MCP:

Before building an MCP-powered agent, start with –

• Creating a Copilot agent from scratch by attaching the right tools. Each tool represents a specific capability, such as reading customer data, updating records or accessing documents.
• Clear descriptions and proper instructions ensure the agent understands how and when to use each tool. Once activated, the copilot can securely communicate with multiple systems.

Steps to Implement Copilot with MCP Server

Let us understand this by 3 real-life scenarios –

Scenario 1: Sales Deal Closure with Dynamics 365 Business Central

In this scenario, the copilot agent will check customer financial information from Business Central before closing a sales deal. It helps verify details like credit limits or financial exposure, so the user can decide whether the deal can be approved or not.

Step 1: Let us start by creating a blank Copilot agent named ‘Enterprise Unified Agent’. At this stage, the agent has no knowledge or access to any systems.

Step 2: A tool needs to be added that allows the agent to connect with ‘Microsoft Dynamics 365 Business Central’ through the MCP server.

Step 3: Inside Business Central, the MCP Server Configuration needs to be opened in order to connect Copilot with it.

Standard API’s are then exposed as tools so the copilot can access them.

After saving the configuration and refreshing the tools, they become available for the agent to use.

Step 4: Each tool needs to be provided with a clear ‘Description’ explaining its purpose. These descriptions help the copilot understand when and how each tool should be used during interactions with the user.

Step 5: Add ‘Instructions’ in the agent, which provides guidelines to the copilot on how to respond, what tasks to perform, and how to use the available tools during interactions. Once the configuration is complete, the agent can start interacting directly with Business Central data.

Step 6: Now the user needs to simply ask a question regarding sales deal closure, and the copilot retrieves the required information, such as customer details, along with the final decision as ‘Approved’ or ‘Not Approved’, without the need to manually navigate through the system.

Scenario 2: Technician Scheduling and Service Booking with Business Central and Microsoft Dataverse Server

In this scenario, the copilot helps manage service requests by checking asset details, verifying spare parts availability, and scheduling a technician. It collects issue details, date, and time, then books the service by using information from both Business Central and Dataverse.

Now we have to enhance the copilot by connecting it to multiple systems instead of just one.

Step 1: The second tool for ‘Microsoft Dynamics 365 Business Central’ needs to be configured using the same MCP setup process. This allows the agent to access additional data and perform more actions within the system.

Add ‘Description’ for the tool as per the requirement:

Step 2: An additional tool is needed to be added for ‘Microsoft Dataverse’ so the agent can retrieve records that are stored in it.

Add ‘Description’ for the tool as per the requirement:

Step 3: Add ‘Instructions’ to the agent as per the requirement:

Step 4: Now we need to make a connection between ‘Microsoft Business Central’ and ‘Microsoft Dataverse’ by entering the environment URL and enabling the data synchronization so the copilot can access updated information from both systems.

Step 5: Now we need to add Dataverse tables as knowledge sources, which will allow the Copilot to retrieve data from them whenever needed.

Necessary Tables are added as below:

Step 6: Now the user asks a question regarding ‘Technician booking’, so the copilot retrieves the required information by using both Microsoft Dataverse and Microsoft Dynamics 365 Business Central to process the request and provide the response.

Step 7: The agent interacts with the user to collect required details such as:

• Issue description
• Service date and time

As you can see above, the copilot asks for the required details like the ‘Issue & service time’, then checks the system and schedules the technician accordingly

Scenario 3: Retrieve Instructions from Documents with SharePoint

In this scenario, the copilot accesses documents stored in SharePoint to answer user questions. It reads policies, guidelines, or reference files and provides the required instructions so users can quickly find the information they need.

Step 1: To retrieve instructions, documents need to be added to Microsoft SharePoint.

Step 2: To make these documents accessible, Microsoft SharePoint needs to be added as a knowledge source for the Copilot, as shown below

We need to upload the necessary ‘Documents’ to Microsoft SharePoint as below

Step 3: ‘Descriptions’ and ‘Instructions’ need to be added to guide the agent on how and when it should use the document-based information during conversations.

Step 4: Now the user needs to ask the agent questions that require information from documents in SharePoint.

As you can see above, the copilot searches the documents and shows the required instructions step by step based on the question.

Conclusion:

By the end of these 3 scenarios, the copilot grows from a simple blank agent into a smart assistant that can connect to different systems and help complete tasks. Instead of opening multiple apps like Business Central, Dataverse, or SharePoint, users can just ask the copilot and get the information they need in one conversation. This shows how a basic copilot can gradually become a powerful tool that not only answers questions but also helps get real work done faster.

FAQs

1. What is MCP Server in Microsoft Copilot?

MCP (Model Context Protocol) Server enables Copilot to interact with multiple systems using predefined tools instead of direct API calls. It standardizes how Copilot accesses and executes actions across platforms.

2. Can Copilot work across multiple Dynamics 365 applications?

Yes. With MCP Server, Copilot can interact with Business Central, Dataverse, and SharePoint within a single workflow, enabling cross-system execution.

3. How is MCP different from traditional API integrations?

APIs require custom integration logic, while MCP exposes standardized tools with predefined schemas, making it easier for Copilot to discover and use capabilities dynamically.

4. What are MCP tools in Copilot?

MCP tools are predefined actions (like retrieving data or updating records) that Copilot can invoke. Each tool represents a specific business capability exposed by a system.

5. Is MCP Server required for building advanced Copilot agents?

For cross-system and action-oriented Copilot scenarios, MCP Server is essential as it enables structured, secure, and scalable integrations.

The post How to Build a Cross-System Copilot Agent in Dynamics 365 Using MCP Server first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

Sales teams working in Dynamics 365 CRM often struggle to understand complex stakeholder relationships inside large accounts. Relationship mapping in Dynamics 365 CRM is a visual way to understand how accounts, contacts, stakeholders, and opportunities are connected. By transforming CRM records into visual diagrams, teams can identify decision makers, influence paths, and organizational structures more easily.

In this guide, we answer 10 common questions about relationship mapping and CRM data visualization in Dynamics 365 CRM.

What is relationship mapping in Dynamics 365 CRM, and how to implement it?

Relationship mapping in Dynamics 365 CRM is a visual way to understand how accounts, contacts, stakeholders, and opportunities are connected. Instead of analyzing raw records or lists, CRM users can see relationships through visual diagrams, helping them identify key decision makers, influence paths, and hidden connections that affect sales outcomes.

Relationship mapping helps CRM teams:

• Visualize connections between accounts, contacts, and opportunities
• Identify decision makers and influencers
• Understand organizational hierarchies
• Discover hidden relationships that affect deals

Modern relationship mapping tools like mind maps using Map My Relationship, hierarchy views, and influence maps make relationship mapping easier by transforming complex CRM data into clear visual networks.

How does relationship mapping help close deals in Dynamics 365 CRM?

Relationship mapping helps close deals faster by identifying the right people to engage within a customer organization. By visualizing decision makers, influencers, and reporting structures, sales teams can prioritize key contacts and build stronger engagement strategies that accelerate deal progression.

Relationship mapping enables sales teams to:

• Identify decision makers vs influencers
• Understand reporting structures
• Track existing relationships across accounts
• Plan multi-threaded sales strategies

Visual CRM tools like Map My Relationship allow teams to see who knows whom, which improves outreach and stakeholder engagement.

How can you visualize relationships between accounts and contacts in Dynamics 365?

You can visualize relationships between accounts and contacts in Dynamics 365 by using CRM visualization tools that convert relational data into visual diagrams such as mind maps, hierarchy trees, or organizational charts. These views make it easier to understand how stakeholders are connected across accounts and opportunities.

Typical CRM visualization methods include:

• Mind Map View – displays connections between contacts and stakeholders
• Hierarchy View – shows account structures
• Tree View – visualizes parent-child relationships
• Influence Mapping – identifies key decision makers

Solutions like relationship mapping apps for Dynamics 365 enable these visualizations directly inside the CRM interface.

 What is influence mapping in CRM relationship management?

Influence mapping is a CRM technique used to identify the people who influence purchasing decisions within an organization. Instead of focusing only on primary contacts, influence maps visualize connections between stakeholders, helping sales teams understand internal dynamics and build stronger relationship strategies.

Influence mapping helps teams:

• Identify champions and blockers
• Understand internal stakeholder influence
• Plan targeted engagement strategies
• Navigate complex enterprise accounts

Advanced CRM visualization tools like Map My Relationship represent influence relationships using interactive relationship maps

What are the best ways to visualize complex CRM relationships?

The best ways to visualize complex CRM relationships include using mind maps, hierarchy charts, tree views, and network diagrams. These visualization methods transform CRM records into structured visual models that help users understand connections, organizational structures, and influence paths quickly.

Popular CRM visualization approaches include:

Modern Dynamics 365 tools like Map My Relationship integrate these views directly within CRM dashboards.

Can Dynamics 365 CRM show account hierarchies visually?

Yes, Dynamics 365 CRM can display account hierarchies visually using hierarchy charts and relationship visualization tools. These visual structures help CRM users understand parent companies, subsidiaries, and business unit relationships within large organizations.

Account hierarchy visualization helps with:

• Enterprise account management
• Understanding corporate structures
• Planning account-based sales strategies
• Managing multi-location customers

Advanced CRM apps like Map My Relationship enhance these capabilities by providing interactive hierarchy views and relationship diagrams.

What is the best tool for relationship mapping in Dynamics 365 CRM?

The best relationship mapping tools for Dynamics 365 CRM allow users to visualize complex relationships through multiple interactive views such as mind maps, tree diagrams, and influence maps. These tools help sales and relationship managers understand stakeholder networks and account structures without leaving the CRM environment.

An effective relationship mapping solution should provide:

• Mind Map relationship visualization
• Account hierarchy charts
• Influence mapping
• Tree and network views
• Interactive CRM relationship diagrams

Solutions like Map My Relationships transform Dynamics 365 data into visual relationship intelligence, making it easier for teams to analyze connections and manage complex accounts.

What is stakeholder mapping in CRM?

Stakeholder mapping in CRM is the process of identifying and visualizing individuals who influence purchasing decisions within an organization. By mapping stakeholders, sales teams can understand relationships between decision makers, influencers, and internal champions.

Stakeholder mapping helps with:

• Enterprise deal management
• Account-based selling strategies
• Influence identification
• Strategic relationship planning

Visualization tools often represent stakeholders through interactive relationship diagrams.

What is influence mapping in Dynamics 365 Sales?

Influence mapping is a technique used to identify how different stakeholders affect purchasing decisions within an organization. Instead of focusing only on primary contacts, influence maps show how decision makers, influencers, and internal champions are connected.

Influence mapping helps sales teams:

• Understand internal power dynamics
• Identify champions and blockers
• Plan targeted engagement strategies
• Navigate complex enterprise sales cycles

CRM visualization tools often represent influence relationships using interactive maps.

What Is Account Relationship Mapping in CRM?

Account relationship mapping in CRM is the process of visually representing how contacts, departments, subsidiaries, and partner organizations are connected to a customer account. Instead of viewing isolated records, relationship maps display these connections in a structured visual format, helping sales teams understand influence networks, organizational structures, and key stakeholders.

Account relationship mapping typically includes:

• Mapping internal contacts: Identifying how decision makers, influencers, and end users are connected within an organization.
• Mapping partner relationships: Understanding connections between customers, vendors, resellers, or strategic partners involved in the business ecosystem.
• Mapping subsidiaries and parent companies: Visualizing corporate structures such as holding companies, regional branches, and business units.
• Tracking cross-account connections: Discovering relationships between contacts who interact with multiple accounts, departments, or opportunities.

These relationships are often visualized using relationship network diagrams, org charts, hierarchy charts, or stakeholder maps, allowing CRM users to quickly interpret complex account structures and engagement pathways. Tools designed for CRM relationship visualization can transform standard CRM records into interactive relationship maps, making it easier to analyze stakeholder influence and manage complex enterprise accounts.

Relationship mapping transforms traditional CRM records into visual relationship intelligence. By combining stakeholder mapping, influence visualization, and account hierarchy views, sales teams gain a clearer understanding of complex customer ecosystems inside Dynamics 365.

Get a 15-day free trial from Inogic Website or Microsoft Marketplace. If you want an end to end implementation demo, reach out to us at crm@inogic.com.

The post What Is Relationship Mapping in Dynamics 365 CRM? 10 FAQs on CRM Data Visualization first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

Automation testing requires interacting with different UI elements in an application. Tests may fail for several reasons such as incorrect selectors, synchronization issues, or unexpected changes in the UI. Identifying reliable UI selectors is therefore crucial when writing complex automation scripts. One of the most common causes of UI automation failures is the use of incorrect or unstable selectors.

Some common reasons why automation scripts fail include:

Targeting Incorrect Selectors

• The UI element no longer exists on the page.
• The selector matches multiple UI elements.
• The UI structure has changed after application updates.

Timing and Synchronization Issues

• Modern web applications often load content asynchronously. As a result, UI elements may appear after a delay. Tests can fail if the script attempts to interact with an element before it is available. Using proper waiting mechanisms such as explicit waits and assertions helps ensure that elements are present and in the correct state before interacting with them.

Playwright Inspector

Debugging tools such as the Playwright Inspector allow to pause test execution and visually inspect the web page during test runs. This makes it easier to identify locator issues and understand how the test interacts with the application.

The Playwright Inspector works as a debugging interface that opens when Playwright tests are executed in debug mode. It provides several useful capabilities:

• Pause and step through test execution
• Inspect elements on the page
• Validate selectors used in the test
• Generate reliable locators
• Observe browser actions in real time

Because Playwright interacts with a real browser, it allows to observe actual browser behavior. This helps in verifying that the application performs as expected during automation. With the Inspector, you can:

• Watch the browser perform each action
• Verify navigation, clicks, and form submissions
• Confirm that the application behaves as expected
• Step through the test line by line
• Ensure waits and assertions are placed correctly

In previous blog we have already explored how Playwright can be used for Dynamics 365 automation testing wherein we have simply created contact record using Typescript code.

Using TypeScript with Complex Selectors:

Let’s extend the same use case. While creating a Contact record in Dynamics 365 CRM, we will now work with more complex UI elements such as lookup fields and option set fields. At the same time, we will use the Playwright Inspector for live debugging.

To perform the debugging process you can add a page.pause() method to your test. This way you will see the GUI page appears for “Playwright Inspector” while running the test.

By following the same steps provided in previous blog you can complete the Playwright setup (if not already) and here is the upgraded version of typescript code with more complex selectors and debugging step.

Typescript:

Create tests/contact.spec.ts:

Note: You can refer below code await page.pause () is added explicitly.

import { test, expect, Page } from '@playwright/test';

import { populate } from 'dotenv';

import fs from 'fs';

import path from 'path';

 

// --- AUTOMATIC VIDEO SAVER (FIXED) ---

test.afterEach(async ({ page }, testInfo) => {

const video = page.video(); // get video BEFORE closing

await page.close();

 

if (video) {

const videoPath = await video.path();

const timestamp = new Date().toISOString().replace(/[:.]/g, '-');

const newName = `${testInfo.title.replace(/\s+/g, '_')}_${timestamp}.webm`;

const historyFolder = 'video-history';

 

if (!fs.existsSync(historyFolder)) {

fs.mkdirSync(historyFolder);

}

 

const newPath = path.join(historyFolder, newName);

await fs.promises.copyFile(videoPath, newPath);

 

console.log(` Video saved to: ${newPath}`);

}

});

 

test('Create New Contact in D365', async ({ page }) => {

// Debugging step

await page.pause()

test.setTimeout(120000);

 

const appId = process.env.APP_ID!;

const orgUrl = process.env.CRM_URL!;

 

// 1. Navigate directly to Contacts grid, pause command use for debugging

 

await page.goto(`${orgUrl}/main.aspx?appid=${appId}&pagetype=entitylist&etn=contact`);

await page.waitForLoadState('domcontentloaded');

 

// 2. Click New (robust selector)

const newButton = page.locator("(//span[contains(.,'New')])[1]");

await expect(newButton).toBeVisible({ timeout: 30000 });

await newButton.click();

 

// 3. Wait for form to load (First Name field)

const firstName = page.locator('[data-id*="firstname"] input');

await expect(firstName).toBeVisible({ timeout: 30000 });

 

// 4. Fill mandatory fields

await firstName.fill('Test');

await page.locator('[data-id*="lastname"] input').fill('Bot');

await page.locator('[data-id*="jobtitle"] input').fill('Dev');

await page

.locator('[data-id*="emailaddress1"] input')

.fill('auto34@example.com');

 

const parentAccountInput = page.locator('[data-id*="parentcustomerid"] input');

 

// A. Click the field to activate it

await parentAccountInput.click();

 

// B. Type the search value

await parentAccountInput.fill('test');

 

// C. Wait for the dropdown results to appear and click the correct one

// We look for a list item (role=option or li) containing the text 'test'

const lookupResult = page.getByRole('option', { name: /test/i }).first();

 

// Ensure the result is actually visible before clicking to avoid flakes

const resultList = page.locator('ul[aria-label*="Lookup results"]');

await resultList.waitFor({ state: 'visible', timeout: 10000 });

 

// 4. Select the item from within that list

// We use locator('li') to match the list item specifically, ensuring we don't click other UI elements

const correctOption = resultList.locator('li').filter({ hasText: /test/i }).first();

 

await correctOption.waitFor({ state: 'visible', timeout: 5000 });

await correctOption.click();

 

// 5. Validation (Optional but recommended)

// Ensure the input field now contains the text (meaning selection stuck)

//await expect(parentAccountInput).toHaveValue(/test/i);

 

// --- PREFERRED METHOD OF CONTACT FIX ---

 

// 1. Target the wrapper, NOT the input (which is invisible)

// We use .first() just in case the selector matches the label and the field

const contactMethodDropdown = page.locator('[data-id*="preferredcontactmethodcode"]').first();

 

// 2. Wait for the wrapper to be visible

await contactMethodDropdown.waitFor({ state: 'visible', timeout: 10000 });

 

// 3. Click to expand the list

await contactMethodDropdown.click();

 

// 4. Select 'Email' from the expanded list

const emailOption = page.getByRole('option', { name: 'Email' });

 

// Wait for the dropdown animation

await emailOption.waitFor({ state: 'visible', timeout: 5000 });

await emailOption.click();

 

// 5. Save (button role, not menuitem)

const saveButton = page.locator("(//span[contains(.,'Save')])[1]");

await expect(saveButton).toBeVisible({ timeout: 30000 });

await saveButton.click();

 

});

Run the test:

Run the above typescript file using below command

npx playwright test contact.spec.ts –headed

As you have add a page.pause() it run your tests in debug mode. You can play, pause or step through each action of your test using the toolbar at the top of the Inspector.

Step Over:

Clicking the “Step Over” button in the Playwright Inspector will run the test step by step and will show a LIVE execution on browser as shown:You can see the current action highlighted in the test code, and matching elements highlighted in the browser window.Pick Locator:

While debugging, you might need to choose a more resilient locator. You can do this by clicking on the Pick Locator button and hovering over any element in the browser window. While hovering over an element you will see the code needed to locate this element highlighted below which then you can copy it into your code.Record feature:

You can click on “Record” button and “Start Recording” the other web element with user interactions corresponding typescript code will be recorded/generated in background through recording feature.When started recording you will be able to locate the element start filling in data and can view generated code.The new Playwright Inspector window opens up where the recording code can be viewed and can be copied in the existing code.You can explore more about Playwright locators here and may need to tweak little bit in recorded script and start using the same in existing code.

Conclusion:

Using Playwright Inspector makes debugging UI automation much easier by allowing inspect elements and execute tests step by step. This helps identify unstable selectors and improves the reliability of automation scripts. This leads to more stable tests and a smoother automation development process.

FAQs

What are the common causes of UI automation test failures in Microsoft Dynamics 365?

UI automation tests in Microsoft Dynamics 365 commonly fail due to:

• Unstable or incorrect UI selectors
• Frequent UI updates in Dynamics 365
• Asynchronous loading of elements
• Timing and synchronization issues
  Using reliable locators and proper wait strategies helps reduce failures.

What is UI automation testing in Microsoft Dynamics 365 CRM?

UI automation testing in Microsoft Dynamics 365 involves simulating user interactions (like form entry, navigation, and record creation) to validate that the CRM application behaves correctly. Tools like Playwright help automate these workflows efficiently.

How does Playwright help with Dynamics 365 automation testing?

Playwright enables:

• Cross-browser automation
• Reliable element handling with auto-waiting
• Powerful locator strategies
• Built-in debugging tools like Playwright Inspector

This makes it highly effective for automating complex Dynamics 365 applications.

Is it possible to automate end-to-end workflows in Microsoft Dynamics 365 using Playwright?

Yes, Playwright supports full end-to-end automation in Dynamics 365, including navigation, form submissions, lookups, and validations. With proper waits and selectors, entire business workflows can be reliably automated.

How can you verify form submission in Dynamics 365 automation?

Form submission can be verified by checking confirmation messages, updated field values, or successful navigation. Assertions ensure that the action has completed as expected.

How do you handle timing issues in Dynamics 365 automation?

Timing issues are handled using Playwright’s auto-waiting along with explicit waits like waitFor() and assertions. This ensures elements are fully loaded and ready before interaction, reducing test failures.

What is the advantage of using role-based selectors in Playwright?

Role-based selectors improve reliability by targeting elements based on accessibility roles rather than structure. This makes tests more stable, especially in dynamic applications like Dynamics 365.

The post How to Use Playwright Inspector for Faster Test Debugging in Dynamics 365 CRM first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

Have you ever deleted a Contact record in Microsoft Dynamics 365 and immediately wished you could take it back? If yes, you’re not alone, and the situation is more recoverable than it seems. But the path to recovery isn’t obvious, and the longer you wait, the narrower your options get.

Here’s exactly what happens to your data, what Microsoft’s native tools can and can’t do, and how to get that Contact and everything linked to it back without raising an IT support ticket.

Key Takeaways

• Deleted Contacts in Dynamics 365 aren’t immediately purged, but they aren’t accessible from the UI either
• Native recovery options exist, but none of them are self-service for end users
• Everything linked to the Contact Activities, Notes, Timeline entries is at risk too
• Undo2Restore gives sales reps a one-click restore path, without IT involvement
• Recovery is possible within a configurable retention window. Act sooner rather than later

What Actually Happens When You Delete a Contact in Dynamics 365

When you delete a Contact record in Dynamics 365, it doesn’t vanish immediately from the database. Microsoft moves it to a soft-deleted state. But, and this is the part most users never see, what happens next depends entirely on your organization’s Dataverse retention policies and scheduled system jobs running in the background.

As a sales rep working inside the Sales Hub app, none of this is visible to you. The record disappears from your Active Contacts view. The associated Opportunity lookup goes blank. The Timeline call logs, emails, meeting notes, and appointments become inaccessible. You’re effectively locked out, even though the data may still technically exist somewhere in the system.

The Audit History did capture the deletion. But the native Audit Log in Dynamics 365 is read-only. You can see what happened. You just can’t act on it.

Can Dynamics 365 Recover a Deleted Contact? The Honest Answer

A deleted Contact in Dynamics 365 is removed from all active views immediately upon deletion, but may be recoverable depending on your organization’s Dataverse retention configuration, environment type, and elapsed time.

Recovery is possible, but it looks very different depending on who’s doing it:

The honest summary: recovery exists at the admin and IT level, but it’s never scoped to a single record, never fast, and never something a sales rep can action independently.

The Cost Isn’t the Contact

Re-entering a Contact’s name, email, and phone number takes five minutes. That feels manageable.

What you don’t realize until later is that the Timeline is gone. No record of the last call. No email thread. No notes from the previous meeting. Three weeks later, you’re on a follow-up call with that prospect, and you have zero context for the conversation.

You didn’t just lose a record. You lost the relationship history inside it. And if that Contact was linked to an open Opportunity in your pipeline, the knock-on effect touches your forecast too.

The Only Practical Way to Restore It Without Involving IT

This is where Undo2Restore, a Microsoft Marketplace-listed app for Dynamics 365 and Dataverse, fills the gap that native tools leave open.

It works on top of the Audit Log that Dynamics 365 already maintains. Instead of just showing you what changed, it gives you a UI to act on it. Here’s how the restore works:

1. Open the entity list where the Contact record lived
2. Click Restore Deleted in the Undo2Restore panel
3. Browse the recoverable records grid and locate your Contact
4. Select the record and click Restore

What comes back isn’t just the Contact record. Associated lookup records, Timeline activities, emails, and appointments linked to that Contact are restored alongside it in a single action.

One important note: recovery works within your organization’s configured retention window. The sooner you act after an accidental deletion, the more straightforward the restore.

What If It Wasn’t Just One Contact?

Bulk actions in Dynamics 365, such as mass updates, imports, or list deletions, can affect dozens or hundreds of records at once. At that scale, a backup restore via the Power Platform Admin Center becomes even more disruptive, since it rolls back the entire environment.

Undo2Restore includes a standalone Windows tool that handles bulk recovery independently of the CRM interface. No environment restore or collateral impact on other records.

Conclusion

Deleting a Contact by mistake happens. It’s a known risk in any shared CRM environment where multiple users work across the same data.

The actual problem is that Dynamics 365 doesn’t give end users a practical way to undo it themselves. By the time you realize what you lost, you’re already mid-conversation with no context and no history.

Undo2Restore closes that gap not by replacing what Microsoft built, but by making the recovery layer it already has actually usable for the people who need it most.

Try Undo2Restore free for 15 days from our website or Microsoft Marketplace.

The post Accidentally Deleted a Contact in Dynamics 365? Here’s How to Restore It Fast! first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

If you’ve been working with AI in your business processes lately, you’ve probably run into a really frustrating roadblock: the gap between the chatty text an AI wants to give you and the structured data your automation actually needs.

Let’s say you’re building a Power Automate flow to pull details out of customer emails. You want the person’s name, the priority, and the category. Ideally, you want to get back something clean like this:

JSON:

{

"customer_name": "Sarah Johnson",

"priority": "High",

"issue_category": "Billing"

}

Instead, the AI usually gives out a whole paragraph:

“The customer, Sarah Johnson, appears to have a high-priority concern related to billing. It would be advisable to route this to the finance team for further assistance.”

That’s great if a human is reading it. But for an automated flow? It’s a nightmare. You end up trying to write expressions using ‘split()’ or regular expressions just to grab the values you want, and if the AI rephrases even slightly on the next run, those expressions break. The core issue is straightforward: AI produces conversational text, but automated systems require structured, predictable data.

Microsoft’s Power Platform has a fix for this inside the AI Builder Prompt action. Whether you are using Power Automate or Copilot Studio, you can just tell the AI to hand you back perfectly formatted JSON instead of a paragraph. And the best part? That JSON maps straight into your Dynamics 365 fields, your flow conditions, or your Copilot variables. No messy parsing needed.

Understanding AI Builder Prompts

The Prompt tool can be accessed via the Power Apps maker portal, under AI Builder in Prompts. It allows users to define a custom AI instruction with optional dynamic input variables, and the generated response can be consumed in Power Automate or in Copilot Studio. By default, the output is plain text, but switching the output format to JSON enables the AI to return a structured object that downstream actions consume directly.

As a general guideline: use text output when communicating with a user, and JSON output when communicating with a system.

Setting Up a Prompt with JSON Output:

Navigate to Power Apps maker portal, under AI Builder in Prompts select the Build your own Prompt.

When writing the prompt, three elements are essential: a clear task definition, the JSON schema (field names, data types, allowed values), and explicit output constraints (return only the JSON, no extra text or formatting). Define dynamic inputs by clicking on Input, for example, an ‘EmailBody’ variable to hold customer email text passed from a flow.

In the configuration panel, change the Output format from Text to JSON. Use the built-in Test feature to validate the response structure.

Once tested, integrate it into Power Automate via the “Run a prompt” action, or into Copilot Studio as a Prompt Tool directly or use it within a topic.

Automated Email Categorization with Power Automate

Support teams get flooded with emails every single day. Usually, a human has to sit there, read each one, figure out the priority, guess the customer’s mood, and write a summary.

By combining the Prompt tool with JSON output, you can put this whole categorization process on autopilot. Here is roughly how it flows:

– An Email Arrives: A distressed customer sends an email regarding a critical payment failure on their account.

– The Prompt Analyzes: Your flow triggers immediately, grabs that email text, and ships it over to the AI Builder Prompt you built.

– Clean Data is Structured: The AI reads it, understands the context, and hands you back a neat JSON block.

– Parsed for Automation: Using the “Parse JSON” action in Power Automate, the structured data is instantly converted into dynamic content. You can now use these variables anywhere in your flow to route the email to the right team, trigger an urgent alert, or seamlessly create a record in Dataverse.

Conclusion

Switching AI Builder Prompts to JSON output is a simple but powerful enhancement for building production-ready automation.

While text responses are useful for human interaction, JSON output provides the structure required for reliable system integration.

This approach:

• Eliminates fragile parsing logic
• Ensures consistent AI responses
• Enables direct mapping to business systems

For any solution involving Power Automate, Copilot Studio, or Dynamics 365, using JSON output is one of the most impactful improvements you can make with minimal effort.

FAQs

What is JSON output in AI Builder Prompts?

JSON output is a structured response format in AI Builder Prompts that returns data as key-value pairs instead of conversational text, making it easier for automation systems to process.

 Can JSON output integrate with Dynamics 365?

Yes, structured JSON fields can map directly into Dynamics 365 entities and records without additional transformation.

 Can JSON output integrate with Dynamics 365?

Yes, structured JSON fields can map directly into Dynamics 365 entities and records without additional transformation.

What problems does JSON output solve in AI automation?

It eliminates inconsistent AI responses, removes the need for regex or string parsing, and ensures stable automation workflows.

How do I enable JSON output in Power Apps AI Builder Prompts?

In the Power Apps maker portal, go to AI Builder → Prompts, create or edit a prompt, and change the output format from Text to JSON in the configuration panel.

The post How to Use JSON Output in AI Builder Prompts for Structured Automation first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.

You invested in Dynamics 365 to streamline operations, improve customer engagement, and drive growth.

But instead of speed and efficiency, your teams are dealing with:

• Delayed deployments/releases
• Unexpected production errors
• Last Minute fixes
• Frustrated stakeholders

Here’s is the truth; Most Dynamics 365 failures don’t come from bad code. They come from broken deployment practices.

At Inogic, we help businesses shift from reactive, error-prone deployments to predictable, automated, and scalable delivery models using modern practices like Azure DevOps CI/CD and Power Platform ALM pipelines.

Why Your Deployments Keep Breaking

For years, Dynamics CRM development followed a familiar pattern:

• Export solutions from Development
• Import into Test and Production
• Perform manual validations

While this may work in simple scenarios, it breaks down at scale.

Common Challenges

• Human Errors: A missed dependency or incorrect configuration can break production.
• Environment Mismatches: What works in Test fails in Production
• Lack of Visibility: No clear tracking of who changed what and when.
• Slow Time-to-Market: Manual processes delay releases and business responsiveness.
• Difficult Rollbacks: Fixing failed deployments takes hours instead of minutes.

The Business Impact

Every failed deployment isn’t just an IT issue it affects:

• Revenue opportunities
• Customer experience
• Team productivity
• Business continuity

Every unstable release erodes trust in your system.

The Shift: CI/CD with Azure DevOps

Modern businesses cannot afford slow, unpredictable releases.

This is where Continuous Integration (CI) and Continuous Delivery (CD) come in.

With Azure DevOps CI/CD, your deployment process becomes automated, consistent, and reliable.

What Changes with CI/CD?

1. A developer makes a change
2. The pipeline automatically builds and tests the solution
3. Errors are caught early
4. Approved changes move seamlessly to higher environments

What This Means for Your Business

• No more manual exports/imports
• Faster and more frequent releases
• Reduced deployment risks
• Full visibility into every change

Think of it as a factory line for your software, every step automated, tested, and optimized.

Bringing Control to Low-Code with ALM

The rise of low-code tools like Power Apps and Power Automate has empowered business users to innovate faster.

But without governance, this can lead to:

• Uncontrolled changes
• Broken dependencies
• Security risks
• Environmental chaos

The Fix: Power Platform ALM Pipeline

Application Lifecycle Management (ALM) introduces structure into low-code development.

Key Environments

• Development – Safe space for building
• Test – Validation and user acceptance
• Production – Stable, business-ready solutions

The Result

• Version control for every solution
• Controlled and automated deployments
• Easy rollback to previous versions
• Scalable innovation without chaos

This is essential for organizations scaling their Power Platform development services.

What Modern ALM & CI/CD Actually Deliver

When you move from manual processes to automated pipelines, the impact is immediate:

• Faster Time-to-Value: Release cycles shrink from weeks to days—or even hours.
• Reduced Risk: Automated testing minimizes production errors.
• Better Collaboration: Developers, IT teams, and business users work in sync.
• Full Traceability: Every change is logged, tracked, and auditable.
• Instant Rollbacks: Failures can be reversed quickly with minimal disruption.
• Scalability: Grow your system without increasing complexity.

Why Inogic?

At Inogic, we don’t just implement pipelines we fix the underlying process.

Our Approach

• Audit your current deployment process
• Identify bottlenecks and risks
• Implement structured CI/CD pipelines
• Establish governed ALM practices
• Train your teams for long-term success

Because tools alone don’t solve problems, process does.

Turn Your Dynamics 365 Into a Growth Engine

If your deployments still depend on manual effort, you don’t have a strategy you have a risk.

By modernizing your development lifecycle, you can:

• Eliminate release-day stress
• Deliver faster, smarter updates
• Build a resilient and scalable system

Let’s Fix What’s Slowing You Down

If your last deployment caused delays, rework, or uncertainty it’s time to rethink your process.

Let’s identify where your deployment pipeline is breaking and how to fix it.

crm@inogic.com

www.inogic.com

FAQs

What is Azure DevOps CI/CD in Dynamics 365 development?

Azure DevOps CI/CD in Dynamics 365 development is an automated process that builds, tests, and deploys CRM customizations across environments. It ensures that every change is validated before release, reducing errors and enabling faster, reliable deployments.

Why are manual deployments risky in Dynamics 365 environments?

Manual deployments in Dynamics 365 environments are risky because they rely on human intervention, which can lead to missed dependencies, configuration mismatches, and production failures. These issues often result in downtime, delayed releases, and increased operational costs.

What is a Power Platform ALM pipeline?

A Power Platform ALM pipeline is a structured deployment process that manages the movement of apps, flows, and solutions from development through testing and production. It ensures version control, governance, and consistent deployments across environments.

How does CI/CD improve Dynamics 365 implementation services?

CI/CD improves Dynamics 365 implementation services by automating testing and deployment, reducing manual effort, accelerating release cycles, and ensuring consistent configurations across environments.

How does Azure DevOps help in Dynamics CRM development?

Azure DevOps helps in Dynamics CRM development by enabling automated builds, test validation, release pipelines, and version tracking. It provides complete visibility into changes and ensures stable, repeatable deployments.

How does deployment automation reduce downtime in Dynamics 365?

Deployment automation reduces downtime by eliminating manual errors, enabling pre-deployment testing, and allowing quick rollback to stable versions if issues occur during release.

The post Modernizing Dynamics 365 Delivery: How CI/CD and ALM Drive Real Business Reliability first appeared on Microsoft Dynamics 365 CRM Tips and Tricks.