Microsoft AB-100<\/a> planning begins with a business operation, not a preferred model. Inventory the trigger, actors, records read and changed, approval points, current throughput, expensive errors and exception cases. Some steps need semantic reasoning, but others may be best implemented as a deterministic workflow or a native Dynamics 365 function. Model capabilities should not obscure the existing transaction owner.<\/p>\n Take a supplier onboarding process. The procurement clerk receives a form, checks supplier identity, verifies bank details against approved records and asks a manager to approve sensitive changes. An agent might summarize correspondence or identify missing fields, but the application should still enforce financial authorization and record each change. The architect must distinguish assist, propose and commit operations.<\/p>\n Record how many requests complete correctly, typical cycle duration, frequency and cost of human rework, identity\/access errors and exception escalations. Without a baseline, saying an agent reduces work by 80% is marketing rather than evidence. The selected indicators should map to a specific process and an agreed observation period.<\/p>\n Choose a pilot sample containing ordinary requests, ambiguous data, incomplete forms, a denied user and unavailable system. Record the human decisions required in each. A pilot with only clean happy-path data can look productive while hiding the most expensive process failures.<\/p>\n Create a data inventory with source owner, last validated update, sensitive-data classification, completeness, known duplicates and permissible user roles. A SharePoint policy, Dataverse customer record and finance ERP account can all mention a supplier yet differ in authority. Establish which source wins for each business field and what an agent should do when data conflicts.<\/p>\n Grounding architecture<\/a> depends on sound retrieval, provenance, permission boundaries and fresh source indexes. Business readiness asks whether the source data is fit for purpose before designing a retrieval pipeline. Improving chunking cannot repair a fundamentally incorrect customer master.<\/p>\n A dated policy document can help an agent explain purchasing rules, but a live invoice amount should normally come from an authorized record lookup rather than a stale embedded summary. Decide whether a fact is unstructured guidance, a structured field or an event. Then pick appropriate knowledge retrieval, connector access or deterministic calculation.<\/p>\n For a supplier credit limit, prefer a supported Finance and Operations or Dataverse record query with correct identity and typed inputs. For an explanatory policy, retrieve from approved documents with citations. An agent that invents an average from vaguely relevant paragraphs has crossed a source-of-truth boundary.<\/p>\n An administrator’s ability to read every source during configuration does not entitle all agent users to the same data. Compare delegated user authorization with any supported application\/service identity, and enforce permissions at the actual data source or tool. Merely instructing the model to hide confidential records is not sufficient access control.<\/p>\n Test a procurement clerk and a finance manager asking the same sensitive question. The clerk should receive only authorized information, while the manager may see additional fields. Include an external guest with no right to the record. Record each source’s access outcome, not just whether the chat interface accepted both prompts.<\/p>\n List prohibited autonomous actions such as changing supplier bank accounts without dual control, deleting financial records or submitting a regulatory report without approval. Place the guard at the transactional API and independent role system; a message that says \u201cask for confirmation\u201d can be bypassed if tools are overprivileged.<\/p>\nCreate a baseline that can be independently measured<\/h2>\n
Test grounding sources for quality and freshness<\/h2>\n
Separate exact operational facts from knowledge articles<\/h2>\n
Specify identities and data disclosure boundaries<\/h2>\n
Decide what the agent should never do<\/h2>\n