Are Dynamics 365 ERP form tools just RPA with a new name?

No — and the difference decides whether your agent survives a form change, a slow morning, or a security review. This is for the architect who has been asked to explain why this is not the screen-scraping project that failed in 2019.

6 minute read.

They look identical and they are architecturally opposite

The Dynamics 365 ERP MCP server [GA] exposes a family of tools that read like a macro recorder: open a menu item, find a control, set a value, click, select a grid row, save, close. Anyone who has lived through an RPA (robotic process automation — software that drives an application's screen the way a person would) programme sees that list and reaches for the same objection. In the Microsoft stack that objection has a name: Power Automate desktop flows, which drive a machine "using application UI elements, images, or coordinates".

The objection is wrong, and the reason is one sentence: form tools never open a client session and never touch the browser. They work through server APIs that hand the agent the application's view model — the server-side object describing what a form currently shows, its controls, its values and its available actions.

No screenshots. No pixel coordinates. No rendering, no waiting for a spinner, no scroll position. The agent reasons over a structured object that the server built, which is the same object the client would have rendered.

What the catalogue actually contains

Three families, and knowing which is which is most of the design.

**Data tools** — Tools: data_find_entity_type, data_get_entity_metadata, data_create_entities, data_update_entities, data_delete_entities, data_find_entities, data_find_entities_sql · What it is for: CRUD through data entities. Fastest path, fewest calls
**Form tools** — Tools: form_open_menu_item, form_find_menu_item, form_find_controls, form_open_or_close_tab, form_set_control_values, form_open_lookup, form_click_control, form_select_grid_row, form_filter_grid, form_sort_grid_column, form_filter_form, form_save_form, form_close_form · What it is for: Driving the application where business logic lives behind a button
**Action tools** — Tools: api_find_actions, api_invoke_action · What it is for: Invoking X++ classes built with the AI tool framework

A form-tool sequence for creating a record reads exactly like a person's: find the menu item, open the form, click New, find the controls, set them, save. The difference is that every one of those steps is a typed server call returning a structured result, not a guess about what is on screen.

Why that distinction is not academic

Selector-based screen driving breaks on things that have nothing to do with your business process. Desktop flows interact with a machine "using application UI elements, images, or coordinates", so a moved button, a slow render or a different screen resolution is a failure mode.

Microsoft's newer answer trades that brittleness for non-determinism rather than removing it. The computer use tool [GA] in Copilot Studio is powered by Computer-Using Agents (CUA), "an AI model that combines vision capabilities with advanced reasoning to interact with graphical user interfaces", and Microsoft's claim for it is that "it adapts to interface changes".

Form tools take neither path. The view model is a typed server object, so there is no resolution and no render to wait for. Personalisation is not a layout to cope with either — Microsoft builds the context "based on the agent's security permissions and application configuration, extensions, and personalization", so it arrives as structure rather than as something to look at.

There is a commercial edge to it as well, though not the one people assume. Both paths bill on the same meter: Microsoft says MCP tool calls "align with the Agent Action feature, which bills at a fixed rate per tool call", and Computer-Using Agents "are also billed at the agent action rate".

The difference is the licence. Copilot Studio agent usage "is included in the Microsoft 365 Copilot license"; Computer-Using Agents (CUA) usage is "not included in the Microsoft 365 Copilot USL". Same rate, different inclusion.

The rule that surprises people: prefer data tools anyway

Microsoft's own published agent instructions are blunt about it — prefer data tools over form tools for CRUD, and reach for form or action tools only when data tools genuinely cannot do the job. Fewer calls, better performance, lower bill.

So form tools are not the default. They are the answer to three specific situations:

The operation runs business logic behind a button — a posting, a confirmation, a release — that is not expressible as writing a row.
The value is calculated by the application at runtime, so it exists in the view model and nowhere in an entity.
There is no public entity for what you need. OData exposure is a per-entity property — Microsoft's data-entity wizard calls it Enable public API — so the honest alternative here is usually building the entity, not driving the screen.

An agent built entirely on form tools is usually an agent whose designer never ran data_find_entity_type.

Where form tools stop

Publishing the limits is more useful than publishing the capability list, and Microsoft documents these plainly.

**Unsupported controls — calendar, organisation chart, list view, availability view, HTML editor, image, radio button, time edit** — A heavily customised form can be partially unreachable
**Custom controls are not supported at all** — If your ISV shipped a custom control, the agent cannot touch it
**Tabs are closed by default** — The agent must open a tab before it can find controls under it. Extra calls, and a common dead end
**Menu-item discovery is filtered twice — by the left-side navigation pane, and by what the user role can access** — Anything outside nav is invisible to form_find_menu_item, and so is anything the agent's role cannot reach
**No advanced grid filters — only the "matches" operator** — Microsoft names "before", "after" and "between" for date columns as unsupported, though a date value expression is still valid. A bounded range belongs on the data tools
**No document viewer, DocuUpload or FileUpload** — Attachments run through a separate pathway, and Microsoft's file support for the MCP server is still [PP] — its own page says preview features "aren't meant for production use"

Two of those are worth carrying into design review. The custom-control gap means the more your implementation partner tailored the UI, the smaller your agent's reachable surface — which is a genuinely counter-intuitive result. And the missing date filters send you back to the data tools for anything time-bounded, which reinforces the preference above.

The counter-argument

"If server-side view models are so much better, why does Microsoft ship a screen-driving agent at all?"

Because the two solve different problems. A Computer-Using Agent exists to reach systems with no API and no server contract — the twenty-year-old application nobody can extend, the supplier portal with no integration story. That is a real and permanent category, and screen-driving is the only honest answer in it.

Dynamics 365 is not in that category. It has a server contract, and the MCP server exposes it. Using a screen-driving agent here means choosing the tool built for systems that lack what this one has.

What to do this week

Open the form your first agent will use and count the custom controls on it. That number is the size of your unreachable surface, and nobody has counted it yet.
Take the three operations you want the agent to perform and mark each entity CRUD or button with logic behind it. The first group belongs on data tools; only the second needs form tools.
Check whether the forms you care about are reachable from the left navigation pane and by the role the agent runs as. Microsoft filters menu-item discovery by both. If a form fails either test, discovery will never find it and your instructions have to name the menu item directly.

Where we would draw the line

We would not build the screen-driving version of an ERP agent on Dynamics, at any price. Microsoft supports that route — it publishes a Power Automate RPA solution for Dynamics 365 Finance that carries out the steps "as if a human were doing it in front of their computer" — but it puts a browser, a signed-in session and a stored password in a path the MCP server does not need. We would not build an agent whose write path is entirely form tools when the same write is an entity operation. And we would not design against a custom control — if the control is the only route to the value, the honest answer is to expose the value properly through an action, not to teach an agent to poke at a UI element that was never meant to be an interface.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

If you are choosing between the data path and the form path for a specific operation, we will walk it with you on a call. https://cognilium.ai

Are Dynamics 365 ERP form tools just RPA with a new name?