Two Agents, One Record: When Copilot Studio and Dynamics 365 Agents Touch the Same Transaction
Picture a Business Central sales order on a busy morning. The Sales Order Agent created it from a customer email overnight. Then, at 9am, a sales rep asks a Copilot Studio agent to change the delivery date on the same order. Your operations team built that second agent. Both agents did what they were designed to do. So the question is simple. What does the record say now, and can anyone explain how it got there?
Microsoft now offers prebuilt agents inside Dynamics 365. It also lets you build your own in Copilot Studio. At DAX Software Solutions, we think a second agent changes things. Once two agents can write to the same transaction, multi-agent governance stops being theory. It becomes a design decision.
Who is acting when two agents touch one record?
Microsoft’s Sales Order Agent FAQ states that the agent “runs as its own user.” It has predefined permission sets. In addition, all its actions “carry the agent’s user ID,” including when it creates or changes records. That user ID appears in list views, history and posted documents, just like any other user.
A Copilot Studio agent works differently. Take one that connects through the Business Central connector. Microsoft’s guide to creating Copilot Studio agents for Business Central states that it uses the signed-in user’s permissions. In other words, the agent acts as that user. Microsoft’s Copilot Studio connector guidance adds a detail. By default, connections use the credentials of the person using the agent. However, makers can choose to provide their own credentials instead.
As a result, one change on the order carries an agent’s identity. The other may carry a person’s name. So anyone who reads the history later needs to know about that difference.
Do both agents follow the same rules?
No. One has published limits, while the other has the limits you set. Microsoft states that the Sales Order Agent works only with sales quotes and sales orders. It does not create new items, contacts or customers. It also does not post documents.
By contrast, a custom Copilot Studio agent can do whatever its setup allows. For example, take agents that use the Business Central MCP server. Microsoft states that these get read-only access to exposed API pages by default. To create, update or delete data, you must allow it for each API.
Microsoft also notes that Business Central applies its own business logic to these agent actions. This includes pricing, discounts and validation rules. That logic is a shared safety net. However, it does not decide which agent should make the change.
What happens when two updates collide?
It depends on the platform and on how each update was built. First, note that Business Central keeps its data in Business Central itself. It does not use Dataverse unless the two are integrated.
For Dataverse-based apps such as Dynamics 365 Sales, Microsoft describes optimistic concurrency. This feature lets an app check whether a record changed between reading it and updating it. Developers turn it on for each request. If the versions do not match, the update fails with a conflict error.
Meanwhile, Microsoft’s Sales Order Agent documentation, as we read it, does not cover one case. It does not say how the agent handles a change by another user or agent during its task. For that reason, design your handoffs so that two agents never work on the same fields at the same time. Do not rely on the platform to referee.
Can you reconstruct what happened afterwards?
Yes, but the trail may be split. For the Sales Order Agent, Microsoft states that users get a detailed timeline for each task. It shows the key steps that the agent and people took. On the other hand, a Copilot Studio agent keeps its own execution logs. Microsoft says these show request and response payloads.
For Dataverse-based apps, Microsoft’s auditing guidance also helps. Audit logs can show who created or updated a record, which fields changed and the previous value. However, you set up auditing at environment, table and column level. So you need to turn it on for the tables your agents share.
How should you approach multi-agent governance?
Decide ownership before the second agent goes live.
- Map who touches what: list every agent, prebuilt or custom, that can write to each record type
- Give each step one owner: for example, one agent creates the quote and the other only reads it
- Separate identities: decide if a custom agent acts as the user or has its own account
- Apply least privilege: start custom agents as read-only, then add create, update or delete only where needed
- Turn on the trail: enable auditing for shared tables and keep agent logs ready for review
- Keep humans in the loop: Microsoft notes that approval workflows can add control to the Sales Order Agent’s tasks
This builds on two earlier themes: who owns your Copilot Credits and who approves the overage. In each case, agents scale safely when every decision has a named owner.
Frequently asked questions
Does the Sales Order Agent have its own identity in Business Central? Yes. Microsoft states that it runs as its own user, and its actions carry the agent’s user ID.
Whose permissions does a Copilot Studio agent use with the Business Central connector? It uses the signed-in user’s Business Central permissions. In other words, the agent acts as that user.
Can a Copilot Studio agent change Business Central data through the MCP server by default? No. By default, it gets read-only access to exposed API pages. You must allow create, update and delete for each API.
Does Dataverse record which fields an agent changed? Yes, once you turn on auditing for the table and column. Then the audit logs show who updated a record, which fields changed and the previous value.
DAX Software Solutions: Governance Before Scale
DAX Software Solutions designs human-in-the-loop operating models for Agentic AI in Dynamics 365. This includes how several agents share the same data. Is a second agent about to join one of your processes? If so, talk to our team.
Microsoft’s product guidance is for information and may change. Some features described here, such as the Business Central MCP server, may be in preview. Check how they work in your environment before you act.