Build a Copilot Studio Agent over ERP MCP with Approval Steps

Tier: Advanced · Workflow area: ERP Copilots & Agents · ~45 minutes

MCP (Model Context Protocol) turns ERP capabilities into tools an agent can discover and call. Dynamics 365 ERP MCP servers expose finance and operations actions to Copilot Studio agents, and that is exactly the moment governance has to be designed in rather than bolted on. The pattern this playbook installs — read/write asymmetry with Power Automate approvals on the write path — is the single most reusable control in agentic ERP work.

When to use

• A Dynamics-adjacent team wants an agent that does things, not just answers"create the vendor payment journal" instead of "here's how to create one." MCP is the sanctioned path; ad-hoc API glue is the shadow-IT path.
• You need a reference implementation of human-in-the-loop for agentsthis build is the demonstrable answer to "what does an approval gate actually look like?" and feeds directly into pb-51's control design.
• Multiple agents will share the same ERP capabilitiesMCP centralizes the tool definitions once, instead of re-teaching each agent a REST surface.

When NOT to use

• When the write action is irreversible and high-valueposting to the general ledger, releasing payments above a threshold, master-data merges. Approval steps mitigate; for these, keep the agent read-only and let humans act in the ERP itself until pb-51's full control set is in place.
• Against a production environment during developmentbuild and test in a Dynamics 365 sandbox with copied-down, masked data. An agent bug plus a real environment equals real journal entries.
• If nobody owns the approval queuean approval step that lands in an unwatched inbox is worse than no agent: work silently queues and dies. Name the approver role before you build.

The recipe

1. 1.

   Connect the ERP MCP server in Copilot Studio. Create a new agent, then under Tools → Add a tool → Model Context Protocol, add the Dynamics 365 ERP MCP server for your environment and authenticate with a service connection scoped to a dedicated agent account — never a human's credentials. The tool list the server advertises is your action inventory.

2. 2.

   Sort every advertised tool into read or write. Make the inventory explicit before wiring anything:

   Copy

   Here is the MCP tool list from our ERP server (names + descriptions
   pasted below). Classify each as READ (no state change) or WRITE
   (creates/updates/posts anything). Flag any tool whose description is
   ambiguous about side effects — those default to WRITE until verified.
   Output a two-column table I can paste into our design doc.
   

   The default-to-WRITE rule for ambiguous tools is the whole point of the exercise. Enable only the tools you classified; an agent should not carry tools it has no scenario for.

3. 3.

   Let reads flow, and verify grounding. Wire read tools (query vendor, get invoice status, list purchase orders) directly to topics. Test that answers come from tool output, not model memory: ask about a vendor that does not exist and confirm the agent reports "not found" rather than inventing one.

4. 4.

   Build the approval flow for the write path. In Power Automate, create a flow triggered by the agent (or wrap the write as an agent flow) with this shape:

   Copy

   Trigger: agent requests write action
     → Compose: action name, full parameter payload, requesting user,
       conversation ID, agent's one-line justification
     → Start and wait for an approval (Approvals connector)
         Assigned to: role-based approver group (not one person)
         Details: the composed payload, verbatim
     → Condition: Approved?
         Yes → call the ERP MCP write tool with the SAME payload
         No  → return rejection reason to the agent conversation
     → Log: outcome + payload + approver + timestamp to an audit table
   

   Two details carry the integrity of the gate: the approver sees the exact payload that will execute (not a paraphrase), and the executed call uses that same payload — approval of X must never execute X′.

5. 5.

   Instruct the agent to be honest about the gate. Add to the agent's instructions:

   Copy

   When a user requests any change to ERP data, state that the change
   requires approval, summarize exactly what will be submitted, and
   submit it via the approval flow. Never claim a change is complete
   until the flow returns an approved-and-executed result.
   

   Then test the lie case deliberately: request a write, reject it in the approval queue, and confirm the agent reports rejection instead of success.

6. 6.

   Run an end-to-end trace before anyone else touches it. One read (auto-executes, grounded answer), one write (approval card arrives with full payload → approve → record actually changes in Dynamics → audit row written), one rejected write (record unchanged, agent reports it). Screenshot all three traces; they are your governance evidence for pb-52.

Make it yours

• SAPthe same asymmetry in Joule Studio: skills over released BTP/OData APIs, with write-path skills routing through SAP Build Process Automation approval steps; SAP also exposes MCP-style tool surfaces via BTP, and the read/write sort transfers unchanged.
• Oracle FusionAI Agent Studio agents call Fusion REST; front write intents with an Oracle Process Automation human task playing the Power Automate role.
• SalesforceAgentforce actions marked as requiring confirmation plus a Flow approval step give the same shape; pb-51 generalizes the thresholds.

Quality check

• Every write tool is behind the flow — verified by test, not by diagramattempt each write conversationally and confirm an approval card appears every time; one unwired write tool voids the design.
• The approval card shows the executable payload verbatimapprovers approving summaries are approving fiction.
• Rejection was tested as thoroughly as approvalincluding that the agent's conversation reflects it and no partial state was left behind.
• The audit table reconciles against ERP change logssample five approved writes and match them to actual Dynamics records; the gate's log must agree with the system of record.