Microsoft Graph connectors for Dynamics 365

There's a gap between where Dynamics 365 data lives and where people spend their day. A salesperson working in Outlook and Teams doesn't want to open the CRM to check whether an account has open cases; a project manager writing a status report in Word wants last month's work orders findable without switching apps. A Graph connector closes that gap: it indexes content from an external system — Dataverse tables, Business Central records, or anything else — into the Microsoft Graph index, where it becomes searchable through Microsoft Search and, more importantly now, groundable by Microsoft 365 Copilot.

That last part is why a feature that spent years as a search-admin curiosity suddenly matters. When M365 Copilot answers "what do we know about Contoso?", it can only draw on what's in its grounding reach — mail, files, Teams, and whatever Graph connectors have indexed. Without a connector, your CRM is invisible to the Copilot your organisation is paying for.

How a Graph connector works

The model is index-and-refresh, not live query:

1. A connection is configured per source — which environment, which tables, which columns — in the Microsoft 365 admin center (or programmatically via the Graph API for custom connectors).
2. The connector crawls on a schedule, with full crawls establishing the corpus and incremental crawls picking up changes. This is a copy of searchable text and metadata into the tenant's Graph index — not a federation layer.
3. Each indexed item carries an access control list mapped from the source system, and Microsoft Search trims results per user at query time. Someone who can't see a record in Dynamics doesn't see it in search results or Copilot answers — provided the ACL mapping is configured honestly rather than set to "everyone" to make testing easier. That shortcut has a way of becoming permanent.
4. Results surface in Microsoft Search (Office.com, SharePoint, Bing work search), in Copilot responses with citations, and in context-aware experiences like Context IQ.

Microsoft ships gallery connectors for Dynamics 365 CRM tables and Business Central, alongside connectors for the systems you're likely consolidating search across anyway — Salesforce, ServiceNow, Jira, Confluence, file shares. For anything bespoke (a legacy ERP, a custom Dataverse-adjacent system), the Graph connectors API lets you build your own; it's a well-documented push API, and a custom connector is a realistic few-days build for an integration developer, not a platform project.

Connector or agent? The decision that actually matters

Graph connectors are one of two ways to put Dynamics data in front of Copilot, and picking wrong wastes months. The connector pattern suits discovery: static-ish, text-heavy content that people search for and Copilot should cite — account summaries, case histories, knowledge articles, product records. Its weaknesses are freshness (data is as current as the last crawl) and interactivity (an index answers "what exists?", never "create a follow-up task").

For transactional questions — live opportunity values, stock levels, "update the close date" — you want an agent or plugin built in Copilot Studio that calls Dataverse or the Business Central APIs at question time. The trade-offs run the other way: always-live data, real actions, but per-question latency and a build to maintain. Most organisations doing this seriously end up with both: a Graph connector making the corpus findable, and an agent handling the live operations. The split is covered from the agent side in Copilot agents vs Copilot Studio and Microsoft 365 Copilot for Dynamics 365.

Practical notes before you switch one on

• Index selectively. The instinct to index every table is wrong twice: index quota is finite (tenants get a capped item allowance, with more granted via M365 Copilot licensing), and irrelevant records dilute search relevance. Accounts, cases, and knowledge articles earn their place; forty million ledger entry rows do not.
• Choose columns for humans. The connector indexes what you map. A record that surfaces in Copilot as a bare name with no description or owner is technically indexed and practically useless — map the columns that make a result self-explanatory.
• Plan the refresh cadence against expectations. If sales expects this morning's notes in this afternoon's Copilot answer, an overnight incremental crawl will read as "broken". Set the schedule, then set expectations to match.
• Test security trimming with real users, not admin accounts. Admin accounts see everything; the interesting failures are field workers seeing records their Dynamics security role would have hidden.
• Mind the licensing seam. Graph connectors and Microsoft Search are Microsoft 365 features; the Dynamics side only controls what the connector may read. Quota and entitlement questions land with the M365 admin, which makes this one of the genuinely cross-team features — budget a conversation, not just a configuration.

For the underlying plumbing — what the Graph API can do against Dataverse directly, beyond search — see Microsoft Graph and Dataverse, and for the Business Central flavour of the same story, the Graph API with Business Central.