Copilot Studio agents for D365 F&O: what still needs X++

An agent built in Microsoft Copilot Studio and connected to the Dynamics 365 ERP MCP server can, with no development, read and change data through data entities and use Finance & Operations forms the way a user would. X++ is still needed in three cases: when business logic is reachable neither through an entity nor through a form, when a data entity is missing, and to define the security (privileges, duties, roles) the agent will run under.

In other words, the question is not "agent or development": agents move part of the work to configuration, and focus X++ on smaller, targeted, better-secured action classes.

In Copilot Studio, you add it from the Tools tab: "Add a tool", "Model Context Protocol" filter, select the "Dynamics 365 ERP MCP" server, create the connection, then "Add to agent". The agent then reaches the server's data, form and action tools, within the limits of its security role.

Microsoft Learn gives two practical tips. The orchestration model matters: the documentation recommends Claude Sonnet 4.5, or GPT-5 (Chat) if it is not available, rather than GPT-4.1. And the agent's instructions should say when to use which tools, for example prefer data tools for CRUD and only fall back to forms when needed.

For tool details, prerequisites and limits, see our article on the Dynamics 365 ERP MCP server.

• Logic with no UI: a calculation (balance, availability, margin), a composite operation (create a header and its lines with checks), a business validation that sits behind no button. Learn says so: there can be scenarios where the action is available neither through entities nor through the client.
• Unexposed data: if no data entity covers your custom tables, the agent cannot read them efficiently. Building the entity is a classic X++ development.
• Controlled entry point: an action class lets you enforce your validations and transaction, rather than letting the agent chain form clicks.
• Security: the action menu item, the privilege and its link to a duty then a role are part of the deliverable.

The "Create AI tools with finance and operations business logic" documentation (a preview feature) describes the pattern. The class carries the AIPluginOperationAttribute attribute, implements the ICustomAPI interface and is decorated with CustomAPIAttribute (a natural-language name and description used by orchestration). Inputs and outputs are data members, declared with CustomAPIRequestParameter and CustomAPIResponseProperty. The logic goes in the run method. Learn excerpt for an input parameter:

[CustomAPIRequestParameter('The customer account number', true),
    DataMember('accountNumber')]
public CustAccount parmAccountNum(CustAccount _accountNum = accountNum)
{
    accountNum = _accountNum;
    return accountNum;
}

And for a response property:

[CustomAPIResponseProperty('The current customer account balance'),
    DataMember('balance')]
public AmountCur parmBalance(AmountCur _balance = balance)
{
    balance = _balance;
    return balance;
}

Then: create an action menu item (ObjectType = Class, Object = your class), add it to a privilege linked to a role, deploy, and flush the extension cache (database sync or the SysFlushAOD class). The class then shows up on the "Synchronize Dataverse Custom APIs" form and the MCP server offers it through api_find_actions. Without the MCP server, you also create a Dataverse Custom API and add it as a tool in Copilot Studio.

Development prerequisites: a Unified Developer Environment (UDE), the Copilot for finance and operations solutions installed, and the "(Preview) Custom API Generation" feature enabled. As with any preview, do not use it in production without checking Microsoft's terms.

• Forgetting the action menu item or the privilege: the class compiles but does not appear in the API list.
• Not flushing the cache after deployment: the class exists but cannot be invoked yet.
• Vague descriptions in CustomAPIAttribute and parameters: orchestration uses them to pick the tool and fill inputs.
• An over-broad agent role: more visible objects, more risk and less precise orchestration.
• Rebuilding in X++ what a data entity already does: the agent prefers data tools for CRUD.

Start with configuration: a dedicated role, precise instructions, data tools. Test on a Tier 2 or UDE environment. Note every task where the agent fails or goes through a long chain of clicks: those are your candidates for an action class or a data entity.

These developments are short and well bounded, which makes them good tickets for Skalp AI: ERP context analysis, specification, X++ code and unit tests, delivery to your Azure DevOps and validation by your IT lead. To see how Skalp differs from Copilot, read Skalp AI vs Copilot for D365; to expose your services, D365 F&O API interfaces; for the bigger picture, building X++ without a consultant in 2026. Pricing: Basic, Pro and Max plans, 1 credit (≈ €400 on Basic, €200 on Pro, lower in packs) consumed only when the code is generated.

• Microsoft Learn, "Build an agent with Dynamics 365 ERP MCP", updated 5 Mar 2026, accessed 11 Oct 2026.
• Microsoft Learn, "Create AI tools with finance and operations business logic (preview)", updated 5 Mar 2026, accessed 11 Oct 2026.
• Microsoft Learn, "Use Model Context Protocol for finance and operations apps", updated 18 Aug 2026, accessed 11 Oct 2026.