Finance and supply-chain agents must respect the actual legal entity, company, warehouse and transaction state behind a fluent answer. An inventory lookup might report on-hand units that are not available to promise; a credit inquiry might expose a limit without granting permission to modify it. A credible Dynamics 365 architecture labels each figure with source, business scope, observation time and the identity that is entitled to see it. When a downstream service times out after a possible reservation, reconcile by stable operation ID before retrying. For independent AB-100 ERP-agent practice material, the key judgment is whether the agent merely explains governed information or attempts an authorized, auditable business change. Neither a valid data schema nor a convincing natural-language response replaces the ERP system’s credit, inventory and approval rules.
Consider a fictional distributor operating through two legal entities, North Region and Export Division. The same product number may be stocked in both, but demand, allocation and customer credit decisions follow different rules. The business wants a natural-language assistant for purchasing analysts to investigate stock and credit exceptions. It does not want that assistant to bypass allocations, change the credit limit, or create purchase orders without approved controls.
Map the ERP record and legal-entity boundary first
The first architecture artifact should be a source-of-truth map. Inventory on hand, inventory available to promise, reserved units, open purchase orders, forecast supply and physical warehouse locations are related but not interchangeable. Similarly, customer balance, credit limit, payment terms and a credit hold belong to distinct fields and processes. Before designing natural-language answers, agree which source supplies each measure and when it becomes authoritative.
A user asking “Do we have enough part A-217 for next week’s shipment?” has not supplied a company, warehouse, date or allocation rule. A responsible assistant can identify the missing information and ask for it or present scoped alternatives. It should not total quantities across legally separate companies or assume that a positive on-hand number can be used for that customer’s order.
A sales case can pass into cross-application Dynamics agents, but a Finance or Supply Chain answer must also identify the correct legal entity, ERP record type, effective time and permitted reader. Case handoff context is not enough to authorize reading a customer balance or changing a stock reservation.
Use Dataverse virtual entities without confusing a view with authorization
Microsoft documents finance-and-operations virtual entities as Copilot Studio knowledge sources. These Dataverse tables refer to live ERP data rather than requiring a separately refreshed copy of every record. Adding an entity as agent knowledge does not authorize cross-company disclosure: the user’s or service identity’s Dataverse and finance-and-operations permissions must allow the actual query and company context.
This bridge is useful, but it does not mean every virtual entity or operation is appropriate for a chat agent. Dataverse virtual entities can expose create, read, update and delete capabilities where supported by their backing entity and configuration. A knowledge-source experience intended to answer questions is not an authorization to invoke all of those operations. Define separate service tools for business mutations with narrow scopes, independent checks and application audit trails.
The tutorial describes a sample on-hand inventory entity such as mserp_inventoryonhandaientity and a customer table entity for credit-related questions. Treat those documented names as product-specific examples that require correct environment setup and data-access rules. Do not assume that every tenant exposes the same entities by default, or that the full set is available to every Copilot Studio maker.
Model inventory availability as more than one number
The fictional distributor receives a request: “Can we send 600 replacement valves tomorrow?” The agent retrieves 800 units on hand. A simplistic answer is “yes,” but 350 may be reserved, another warehouse may be outside the shipping region, and a safety-stock policy may reduce usable stock. The agent should distinguish physical quantity from a permitted commitment and cite the underlying availability measure it actually retrieved.
A useful response can say, “The North Region view reports 800 units on hand at the snapshot time. I have not verified reservations, available-to-promise, warehouse allocation or shipment authority.” If an approved availability service exists, invoke it with the item, company, warehouse, customer and date, then report the computed eligible quantity and decision status. The backend owns the formula and reservation rule; the model interprets the service result, not the other way around.
This is not merely cautious phrasing. Incorrect stock commitment can affect customer promises, freight costs and manufacturing scheduling. A model that supplies one plausible aggregate while overlooking a legal entity can create business consequences even when the answer appears numerically coherent.
Distinguish credit evidence from a credit decision
The same distributor asks whether an export customer can receive another large shipment. The assistant may retrieve an authorized credit limit and current relevant account status. It should not decide to raise the limit or remove a credit hold from that evidence. A trusted credit service must consider current receivables, currencies, exposure, legal entity and the organization’s approval policy before returning a recommendation or a permissible transaction state.
Design the explanation for an authorized analyst: which legal entity’s account is being considered, which source and timestamp were used, what is missing, and whether a formal credit review is required. Protect other customer accounts and sensitive financial data. If the caller lacks permission to view credit terms, the agent must not reveal them because they happen to be retrievable by an internal service identity.
A response of needs_credit_review is a legitimate successful outcome if the business rules require approval. Counting it as an AI failure would encourage the agent to invent certainty. A sales representative might be allowed to submit a review request while only finance staff can approve it. Separate those identities in the agent/service contract and audit what was requested and decided.
Design the knowledge-source lifecycle for accurate ERP answers
The architect should identify which source entities are needed, verify the intended customer and entity permissions, prepare the appropriate knowledge-source setup, and test the source after publishing. Microsoft’s tutorial describes adding finance-and-operations virtual entities through the Copilot Studio knowledge experience and testing with concrete inventory and customer questions. It also notes prerequisites in both Finance and Operations and Dataverse. The exact configuration should follow the tenant’s current Microsoft guidance and the team’s privileges.
Knowledge quality is more than connection health. A connected entity may yield records under the wrong company context, or supply a total that lacks business meaning. Label each field with business ownership, effective date, company context and intended calculation. Test stale and conflicting data, restricted users, and unsupported cross-company queries. A document uploaded as a PDF is not a substitute for a controlled operational lookup when the answer depends on the current ERP state.
If knowledge retrieval is cached or copied into a broader search system, document the latency and permission model. A retrieved invoice fragment from last month should not be treated as a live balance. For changing operational data, the user should know whether an answer came from live records, an indexed snapshot or a historical report. The provenance should survive into the generated explanation.
Keep approved actions narrow and replay-safe
Suppose an analyst asks, “Create a replenishment request for these valves.” The agent should not infer supplier, price, ordering legal entity, purchase threshold or delivery terms from an informal prompt. It can prepare a draft proposal using authorized inputs and request human confirmation. A separate process can validate supplier status, budget authority, inventory policy and the proposed order against the system of record.
Use a stable correlation key to protect against duplicate writes if the client retries after a network timeout. A service should return a durable status such as draft_prepared, awaiting_approval or submitted_to_erp. Never report order_created merely because a model called a function. If the ERP integration times out, query the authorized transaction service before repeating the write. Financially consequential retries are not a conversational problem; they are a transaction-integrity problem.
A request that crosses companies or exceeds policy should be refused or escalated through the proper approval process, with an explanation appropriate to the user’s permitted visibility. The agent cannot grant itself finance-system privileges by asking another agent or invoking an MCP tool; tool identity and least-privilege checks must hold through every hop.
Test company isolation, staleness and operational ambiguity
Build a test corpus with the same product number in two companies, a warehouse with reserved stock, an unavailable-to-promise item, a customer on credit hold, an expired price agreement, a user with access to only one business unit, and an intentionally duplicated replenishment request. For each case, record the expected data source, the allowed response and prohibited side effects. The hardest failures often resemble reasonable answers until the company or timestamp is inspected.
Use negative tests that ask for another company’s restricted account data or for an unauthorized credit-limit update. Verify that permissions are enforced by the actual data and transaction services, not just the prompt. If the system supplies an incorrect but syntactically valid table, the evaluation should fail. For numeric outputs, compare against independently computed authoritative records.
Technical telemetry should connect a user request to the queried company, entity name, knowledge or service revision and business receipt, while applying data-minimization rules to logs. Track not only answer acceptance, but corrected inventory mistakes, unnecessary credit reviews, approval denials and prevented duplicate drafts. These metrics reveal whether the agent genuinely improves operations.
Define ERP-specific acceptance and escalation
An acceptable first release might permit company-scoped inventory explanations, status lookups and preparation of review drafts, while explicitly excluding order creation or credit changes. That is an architectural accomplishment if users get reliable evidence and a clear path to authorized action. Adding transaction capabilities later requires new identity, control and regression evidence, not simply a stronger model or an extra prompt.
An inventory figure without company, warehouse, unit of measure, transaction status and observation time can be actively misleading even when the retrieved number is real. The same applies to customer credit: an apparent available balance is not permission to extend a limit or book an order. The distributor, item numbers, companies and decisions in these examples are fictional and illustrative; no actual inventory, customer account or ERP transaction was accessed or changed.