6
Article

The radio buttons on my form were invisible to the agent

Egel Pjetri September 24, 2026 4 views

I've been quietly enjoying the fact that the ERP MCP server has form tools, not just data tools. Data tools are the obvious half: read, create, update, delete. Fine. But form tools let an agent do the other thing — open a page, set a control, click an action — the way a person would, with all your posting logic and validation firing exactly as designed. No parallel API surface to build. That still feels slightly magical to me.

What I hadn't thought about until this week is that "drive the form like a user" means the agent has to find your controls. By name. And that puts a design decision I made three years ago, half-asleep, directly in the critical path of an AI workflow.


The bit that got me

Buried in the 10.0.49 platform notes is a set of form-tool fixes that are much more interesting than their one-line summaries suggest:

  • Group option button controls — your FrameOptionButton = Radio and Check groups — were a control family the agent couldn't read or set at all. Not "worked badly." Couldn't touch. If a required step on your form is a radio group, that flow just didn't work.
  • Control resolution hardening: find-by-name, grid group resolution, and a preference for non-lookup controls when setting a value. That last one is the tell — if you've got a lookup and a plain field with similar names, the agent was picking wrong and failing ambiguously.
  • Menu item label resolution (including via search), plus document upload and viewer support.

So a whole class of "the agent kind of works on this form, sometimes" was really just naming collisions and one blind spot.


Why I care, and what I'm doing about it

This is the first time control naming has had a functional consequence for me. FormStringControl1 never hurt anyone before — it does now. Vague, duplicated, or near-identical control names are the difference between an agent completing a task and giving up in a way nobody can debug.

My takeaway: if you're building agent flows over custom forms, the fix isn't in the agent. Get onto PU73 PQU-1 (7.0.8199.29+; it's backported to 10.0.48 and 10.0.47 too), then go read your own form designs out loud. Would you know which control to click from the names alone? If not, neither will the agent.

I've got a PurchTableExt form I'm suddenly not proud of. Tomorrow's problem.

I've been quietly enjoying the fact that the ERP MCP server has form tools, not just data tools. Data tools are the obvious half: read, create, update, delete. Fine. But form tools let an agent do the other thing — open a page, set a control, click an action — the way a person would, with all your posting logic and validation firing exactly as designed. No parallel API surface to build. That still feels slightly magical to me.

What I hadn't thought about until this week is that "drive the form like a user" means the agent has to find your controls. By name. And that puts a design decision I made three years ago, half-asleep, directly in the critical path of an AI workflow.


The bit that got me

Buried in the 10.0.49 platform notes is a set of form-tool fixes that are much more interesting than their one-line summaries suggest:

  • Group option button controls — your FrameOptionButton = Radio and Check groups — were a control family the agent couldn't read or set at all. Not "worked badly." Couldn't touch. If a required step on your form is a radio group, that flow just didn't work.
  • Control resolution hardening: find-by-name, grid group resolution, and a preference for non-lookup controls when setting a value. That last one is the tell — if you've got a lookup and a plain field with similar names, the agent was picking wrong and failing ambiguously.
  • Menu item label resolution (including via search), plus document upload and viewer support.

So a whole class of "the agent kind of works on this form, sometimes" was really just naming collisions and one blind spot.


Why I care, and what I'm doing about it

This is the first time control naming has had a functional consequence for me. FormStringControl1 never hurt anyone before — it does now. Vague, duplicated, or near-identical control names are the difference between an agent completing a task and giving up in a way nobody can debug.

My takeaway: if you're building agent flows over custom forms, the fix isn't in the agent. Get onto PU73 PQU-1 (7.0.8199.29+; it's backported to 10.0.48 and 10.0.47 too), then go read your own form designs out loud. Would you know which control to click from the names alone? If not, neither will the agent.

I've got a PurchTableExt form I'm suddenly not proud of. Tomorrow's problem.

D365 mcp forms radio button
0 Comments

No comments yet. Be the first to comment!

Log in to comment on this topic.
Published by
Egel Pjetri

admin

View Profile
Share Topic