A finance or supply-chain agent is valuable only when its recommendations fit the exact state of the business system. A model may correctly explain a purchase order yet be unable to tell whether an invoice has been posted, whether a stock reservation remains valid, or whether the requesting employee can change a supplier record. Microsoft AB-100 asks architects to orchestrate AI features in Dynamics 365 finance and supply-chain applications while preserving the transactional rules that make enterprise resource planning reliable.<\/p>\n
Imagine a manufacturer whose buyer asks an agent whether a delayed component can be replaced without jeopardizing production. The agent might combine on-hand inventory, open purchase orders, demand forecasts and supplier lead times. Each source has a time, company and authorization scope. An answer that merely repeats old inventory figures can cause a missed shipment. The architecture must separate explanation from commitment and state exactly when a human or ERP operation owns the decision.<\/p>\n
Finance and operations applications enforce business logic around posting, settlement, inventory reservation, procurement and security. An AI agent should not recreate that logic in natural-language prompts. Use the application’s supported services, data entities, workflows and validations to determine what operations are possible. A proposed journal entry is not a posted journal; a recommended substitution is not an approved change to a bill of materials.<\/p>\n
Model the state transition for the specific business action. A vendor invoice may move from received to matched, approved and posted, with exceptions along the way. The agent can gather documentation, identify mismatches and propose a resolution. The ERP system should validate amounts, purchasing policy, fiscal period, currency, ownership and segregation of duties. If a required condition fails, return an actionable exception rather than a fabricated successful status.<\/p>\n
Operating procedures, vendor agreements and accounting policies are suitable grounding sources when they have clear effective dates, owners and access rules. But questions about today’s on-hand quantity or an outstanding credit limit require current operational data. Mixing a cached policy answer with a live balance without indicating which is which can mislead users. Architect a retrieval layer that records source type, version and freshness expectations.<\/p>\n
Microsoft documents adding knowledge to finance and operations agents<\/a>, including Dataverse virtual entities that expose permitted ERP information. Virtual entities are a useful integration path, but their availability and security should be checked in the target environment. The agent should not infer that being able to read an inventory entity means it can reserve, receive or dispose of goods. Those are separate permissioned business actions.<\/p>\n A multinational organization’s similarly named warehouses, vendors and customers may belong to different companies or legal entities. A part number can exist in several companies with different accounting rules. Include legal entity, site, warehouse, currency, customer and version identifiers in tool contracts where relevant. Do not accept an unqualified \u201capprove this order\u201d as sufficient input for a change with financial consequences.<\/p>\n Ensure that row-level and company-level access remain enforced at the data source and action layer. A purchasing manager in one region may need a summarized network-wide availability answer but lack permission to access another entity’s vendor banking details. Data minimization should be explicit in any agent-to-agent handoff. For broader enterprise controls, AB-100 governance in regulated environments<\/a> provides the ownership and review lens.<\/p>\n Procurement workflows often span several systems: an inbound supplier message, document extraction, inventory planning, approval, purchasing, and logistics confirmation. A failure can occur after some actions succeed. Record a correlation identifier, completed steps, pending approvals and safe compensation paths. If a system times out after recording a purchase order, check its actual state before attempting another create operation.<\/p>\n Suppose an agent recommends transferring stock from warehouse A to B. The first leg is recorded, but the second fails because the receiving location is closed. Do not tell the user that the transfer is complete simply because the agent’s intended plan included both steps. Surface the partial state, stop unsafe retries, alert the appropriate owner and follow a documented recovery process. The orchestration design must remain accurate even when the model misunderstands a tool result.<\/p>\nOrganize cross-company and cross-legal-entity data carefully<\/h2>\n
Design procurement and inventory scenarios for partial failure<\/h2>\n
Treat Copilot in-app guidance as a bounded capability<\/h2>\n