Dynamics 365 ERP MCP Deep Links: Copilot Studio Rendering, SQL Filters and Security Limits

Microsoft has addressed that traceability gap across its Dynamics 365 Finance and Operations applications. Listed under Microsoft's AI at Work roadmap item 576825 as launched—following a May 2026 preview and an August 2026 general availability window for Worldwide Standard Multi-Tenant web environments—responses generated through the Dynamics 365 ERP Model Context Protocol (MCP) server now include direct deep links to the underlying ERP records and application pages.

While the roadmap entry frames this as an automatic productivity boost for administrators, makers, and marketers, technical documentation on Microsoft Learn reveals the real engineering story underneath. Generating a deep link, getting an AI agent to render it properly, and determining what a user actually sees when they click it are three separate operations governed by strict query translation rules and Dynamics 365 security boundaries.

How Dynamics 365 ERP MCP Deep Links Work​

The Dynamics 365 ERP MCP server allows Microsoft Copilot and custom AI agents to query and manipulate business data across the Dynamics 365 ERP suite. With the deep links feature enabled, whenever an MCP tool retrieves or modifies records, the server appends a DeepLinks array to its JSON response. Each entry in that array pairs a target Url with a descriptive Label—such as Open CustomersV3, Open US-001 for a single record, or View CustomersV3 following a record update.

According to Microsoft Learn documentation, this capability is controlled by the Deep links for Model Context Protocol toggle inside Dynamics 365 Feature management, where it is enabled by default. If an administrator disables the feature, the MCP server stops appending deep links to new tool responses, though any URLs already returned in earlier chats will still function if clicked.

Depending on the tool category invoked by the agent, the DeepLinks array sits in slightly different places in the payload:

• Data tools: Returned inside Result.DeepLinks.
• Form tools: Returned at the top level under DeepLinks.

Why Copilot Studio Agents Need Explicit Instructions​

One of the most important operational caveats documented on Microsoft Learn is that the MCP server only generates the links; the client application decides whether and how to show them.

Tool definitions from the MCP server include response semantics metadata (_meta["microsoft/response_semantics"]) pointing to the DeepLinks array. Microsoft 365 Copilot automatically reads this metadata and renders the links as clickable citations in the chat interface.

However, other MCP clients—including custom agents built in Microsoft Copilot Studio—decide for themselves how to handle the payload. If you are building or maintaining a Copilot Studio agent that talks to the Dynamics 365 ERP MCP server, the links may not appear unless you explicitly instruct the agent to render them. Microsoft Learn recommends adding prompt instructions that tell the agent to:

1. Look for the DeepLinks array in the JSON tool response and format each Label and Url as a clickable Markdown link.
2. Render the Url verbatim without reconstructing, simplifying, or stripping query parameters.

Why the strict warning against letting an LLM "clean up" the URL? Because the URL carries percent-encoded JSON filter arrays and navigation targets. If an agent trims or hallucinates a parameter to make the link look prettier, the navigation breaks.

Section Summary: The ERP MCP server automatically packages URL-and-label pairs into tool responses by default, and while Microsoft 365 Copilot displays them natively as citations, custom agents in Copilot Studio need explicit system instructions to output the exact, unmodified URLs.

Which MCP Tools Generate Links (and Which Do Not)​

Not every interaction with the Dynamics 365 ERP MCP server produces a clickable trail. Microsoft Learn divides tool behavior into clear buckets based on how data is queried or modified.

The SQL vs. OData Filter Nuance​

From an engineering standpoint, the most intricate part of Microsoft's implementation is how data_find_entities_sql translates SQL WHERE clauses into Dynamics 365 deep-link filters.

When an agent runs a SQL query against ERP entities, the server attempts to map the conditions into supported URL filter operators:

• Standard comparisons (=, <>, >, >=, <, <=) map to Is, IsNot, GreaterThan, GreaterThanOrEqual, LessThan, and LessThanOrEqual.
• IN (...) clauses or OR conditions checking equality on the same field become IsOneOf.
• BETWEEN maps directly to Between.
• LIKE patterns at the start or end of strings become Contains, BeginsWith, EndsWith, or DoesNotContain (for NOT LIKE '%text%').
• LIKE patterns with internal wildcards (such as '%Contoso%Europe%') convert to the Matches operator, swapping SQL's % and _ wildcards for Dynamics 365's * and ? syntax.

If every condition in the WHERE clause translates cleanly—or if there is no WHERE clause at all, or only a left outer join—the tool returns a single link that opens the filtered list in Dynamics 365.

What happens when the AI writes a complex query using inner joins, EXISTS subqueries against another entity, OR conditions spanning different fields, or unsupported SQL functions? Because Dynamics 365 cannot express those joins as a simple list filter, the MCP server falls back to generating one separate link per returned record.

There is a catch here for developers: per-record fallback links require the entity's key fields (such as CustomerAccount) to be present in the SQL SELECT list. If the query omits the key fields, data_find_entities_sql refuses to guess; it returns no link and appends a note explaining why. Microsoft specifically designed the SQL tool so that it never returns a link that would display more records than the query actually matched. Furthermore, aggregation queries (GROUP BY, SUM, COUNT) never return deep links.

By contrast, the OData-style data_find_entities tool only translates simple equality conditions (Field eq 'value') in its $filter parameter. Microsoft Learn warns that if a data_find_entities request uses other filter conditions, those extra conditions are dropped from the link, meaning the opened ERP list page can show more records than the AI response summarized.

Section Summary: Data retrieval and form actions generate links tailored to the operation, while deletions, metadata lookups, and custom API invocations return none. SQL queries guarantee never to over-match records in a link, whereas OData searches only carry over basic equality filters.

Under the Hood: URL Anatomy and the Read-Only Grid Fallback​

When a deep link is generated, it points to the environment's base URL using the mi=action:McpDeepLinkNavigator action handler. Decoded for readability, the structure looks like this:

https://<environment>/?mi=action:McpDeepLinkNavigator&nav=<target>&nt=<entity|mi>&filters=<filters>&cmp=<company>

• nav: Identifies the target data entity name (e.g., CustCustomerV3Entity) or display menu item (e.g., CustTableListPage).
• nt: Specifies whether the target is an entity or a menu item (mi).
• filters: An optional JSON array of filter objects containing f (field name), op (operator), v (value), and an optional ds (joined data source table, such as DirPartyTable, when the field does not live on the main table). Multiple filters on different fields act as an AND conjunction.
• cmp and crossCompany: Defines the legal entity context. If a tool ran in cross-company mode, it passes crossCompany=true instead of a single company code.
• parentNav: Used by form tools when a target page can only be opened in the context of a parent record's display menu item.

What Happens When a User Clicks the Link?​

Clicking a citation in Copilot does not dump the user onto a static webpage. Instead, McpDeepLinkNavigator checks permissions, launches the target page through its normal menu item (applying standard page setup and default filters), layers on the link's filters, and counts the matching records:

1. Zero matches: Displays "The requested record was not found."
2. Exactly one match (and a details page exists): Opens directly into that record's details view.
3. Multiple matches: Opens the list page filtered to those records.
4. No openable page exists for the table, or a data-tool filter cannot be applied by the form: Falls back to the MCP deep link browser, a built-in read-only grid.
5. A form-tool filter cannot be applied by the page: Opens the page unfiltered and alerts the user: "One or more filters could not be applied."

That read-only grid is a clever safety net. If an agent queries a valid data entity that lacks a dedicated user-interface form—or applies a data filter that a standard form cannot digest, or returns cross-company results for a page that doesn't support cross-company views—Dynamics 365 renders the matching data in a locked-down grid displaying up to 15 columns (key fields, company column if cross-company, filtered fields, and additional available columns). Users cannot edit data in this grid or double-click a row into a detail view, though foreign-key references remain clickable to jump to related records.

Security Boundaries and Known Operational Limits​

For enterprise IT administrators worried about AI oversharing, the most reassuring line in Microsoft's documentation is also the blunt one: a deep link does not grant access to anything.

Every user in Dynamics 365 receives the McpDeepLinkNavigatorView duty (Navigate MCP deep links) as part of the baseline System user role, which merely lets the browser initiate the navigation router. Once triggered, the application enforces the clicking user's exact security posture:

• Entity and Menu Item Permissions: Data-tool links check for read permissions on the data entity (the same permission model used by OData services). If a user lacks entity read rights but has role access to the underlying list or details page, the app gracefully opens the page instead. Form-tool links strictly require permission to open the target menu item.
• Detail Page Restrictions: If a user has list access but lacks permission to open a detail view, clicking a single-record link keeps them on the filtered list page.
• Field-Level Security: If a deep link filters on a field the user is barred from viewing, Dynamics 365 ignores that filter and displays the "One or more filters could not be applied" warning.
• Record-Level and Company Security: Extensible Data Security (XDS) policies and legal-entity access restrictions apply across every form and read-only grid.
• Anti-Enumeration Protection: If a target entity or page does not exist, Dynamics 365 displays the exact same "You do not have permission to open this form" message used for unauthorized pages, preventing users from probing the environment structure via crafted URLs.

Hard Limits to Keep on Your Radar​

Before rolling out custom ERP agents to finance departments, administrators and makers should note several hard technical boundaries documented by Microsoft:

• The 4,096-Character Filter Ceiling: If the JSON filter payload in a deep link exceeds 4,096 characters, Dynamics 365 drops the filters entirely and opens the page unfiltered. Extremely long URLs can also trip browser or web-server URL length limits.
• Aggregate Data Entities: Entities built as AxAggregateDataEntity cannot resolve to an underlying table and never generate deep links.
• Multi-Value Form Filters: Links generated by form tools capture only the first value when a form filter contains multiple values.

By grounding conversational AI answers in native ERP navigation—while refusing to bypass role-based access controls, XDS policies, or field-level security—Microsoft has turned Copilot citations from static text footnotes into functional workflow shortcuts. For Dynamics 365 administrators and developers, the checklist is straightforward: verify that the Feature Management toggle remains active, ensure custom SQL queries include primary keys in their SELECT lists, and update Copilot Studio agent instructions so those deep links make it onto the user's screen intact.