A customer-service manager asks an AI assistant, ‘Can this customer receive an exception to our refund policy?’ The assistant writes a confident answer using a policy document that was superseded three months ago. The resulting mistake is not primarily a language-generation problem. It is a source-selection, versioning and business-authority problem. Microsoft AB-410 addresses building intelligent applications within Power Platform, including Dataverse, prompts, AI capabilities and connected workflows. Reliable applications must determine what information an AI feature can use, who is permitted to access it and how the final business action is authorized.
The word grounding often suggests that adding documents will automatically make a model trustworthy. It does not. A model may misinterpret correct source material, choose the wrong customer record or overstate what an ambiguous passage proves. The architecture therefore needs several independent safeguards: structured authoritative data, carefully scoped knowledge, clear task instructions, output validation and approval for consequential actions. Distinguish this application-level problem from training a foundation model or managing its underlying serving infrastructure; those are different responsibilities.
Decide which facts belong in Dataverse and which belong in documents
Start by inventorying the business facts used by the application. Customer identity, order number, payment status and refund amount should normally come from authoritative structured systems. A current refund policy may be stored as a controlled document with an effective date and version. Free-form interaction notes may provide useful context but should not override formally approved contract terms. When these source types are mixed indiscriminately in one prompt, the model can produce answers that are fluent but impossible to audit.
Build a Dataverse data model with explicit relationships to the relevant customer, purchase and case records. Enforce permissions in the platform so a support agent can read the records needed for a case without gaining visibility into unrelated accounts. Keep identifiers available for cross-system reconciliation. When the assistant drafts an answer, supply the minimum verified fields and relevant approved policy passages. Don’t send the entire customer database merely because more context seems likely to improve output.
Documents require ownership and lifecycle controls. Identify who can publish a policy, when it takes effect, how superseded versions are marked, and whether the business process needs to consider historical terms. A customer who purchased under last year’s contract may legitimately be governed by different terms from a new customer. A retrieval process that always chooses the latest document without considering transaction date can therefore be wrong even if the document itself is authentic.
Use connectors with explicit access and data-movement boundaries
Power Platform connectors can retrieve information from supported services and act in workflows. Each connector runs under a defined connection and its permissions. Understand whether it accesses data as the signed-in user, a configured service identity or another authorized context. A model that receives information through a high-privilege connector can expose material the individual user was never entitled to read. Prompts cannot substitute for enforcing access at the data and connector layer.
List every data path before implementation: which source is read, which fields are transferred, which processing environment handles the input and where the result is stored. Consider data loss prevention policies governing connector combinations. An internal customer profile should not flow into an unapproved external destination through a seemingly harmless automation. Use purpose-limited connections and document the owner responsible for credential rotation, access reviews and incident escalation.
Test denied access deliberately. A support agent assigned to customer A should not obtain customer B’s case details by phrasing a question differently. If a connector cannot enforce row-level scope for a given workflow, filter and validate authorized record identifiers in trusted application logic before collecting data. Be especially wary of broad search functions that retrieve the ‘most relevant’ result across accounts without guaranteeing correct tenant or customer boundaries.
Construct useful prompts without confusing them with rules
A task prompt should identify the input types, required output and evidence standard. For a refund explanation, it may ask for a concise summary of applicable policy, the relevant verified order state and any missing information that prevents a recommendation. Require uncertainty to be stated when a governing clause is unavailable. Separate retrieved policy passages, user questions and system instructions so the assistant is less likely to treat untrusted document text as an instruction with elevated authority.
AI Hub prompts or equivalent supported Power Platform capabilities can be consumed from apps and cloud flows, but the surrounding integration must still check the result. A structured output can help the application display reason, evidence reference and a tentative recommendation separately. Validate that dates and amounts conform to expected formats. If a response includes a reference that is not among the supplied sources, do not render it as a verified citation. Treat the response as a proposed interpretation, not a transaction-ready instruction.
Use ordinary deterministic logic for mandatory limits and authorizations. If refunds over a defined threshold require manager approval, enforce that rule in the app or flow. Do not rely on the model to remember the policy each time. This allows business users to see that natural-language assistance is flexible while formal action remains reproducible, reviewable and attributable to an authorized decision-maker.
Investigate retrieval failures rather than merely rewriting prompts
Suppose the assistant incorrectly says a damaged product is ineligible for return. There are multiple possible causes. The search source may have omitted an exceptions policy; a cached policy may be stale; the wrong customer region may have been inferred; the model may have misread an included clause; or the prompt may have asked for a yes/no answer without enough context. Each calls for a different repair. Adding ‘be accurate’ to the instructions is unlikely to resolve a missing source or a wrong regional filter.
Create a test set that exercises those boundaries. Include a transaction subject to a historical policy, a missing order number, two customers with similar names, a partially contradictory note and a document containing an instruction such as ‘ignore prior policies.’ The application should treat retrieved documents as evidence to evaluate, not as commands that can modify security boundaries. Verify that unauthorized requests are rejected before any sensitive data is returned and that ambiguity leads to clarification or human review.
When troubleshooting, retain the minimum approved evidence needed to understand the failure: task type, source identifiers and versions, prompt version, output, user role and whether any consequential action occurred. Avoid storing raw confidential documents unnecessarily in general debugging logs. A system that fixes accuracy by spreading private examples across multiple diagnostic services may create a new governance problem.
Make output validation part of the experience
Show the user which facts were verified and which portions are suggestions. An app can display the current order status from Dataverse, the named policy version and a draft explanation in separate interface areas. This gives the reviewer a straightforward way to spot inconsistency. Do not manufacture a source link if the application cannot provide one. A sentence that sounds like a citation but does not point to a specific approved document is not equivalent to evidence.
For high-impact decisions, make review a real control. The reviewer should have sufficient context, time and authority to reject the suggestion, and the app should record the decision through its normal approval mechanism. Requiring a click on ‘approve’ without displaying the evidence is weak protection. Where some low-risk tasks can be automated, define their permitted scope and monitor exceptions, corrections and customer complaints rather than assuming that a high average quality score proves safety.
Think also about failure modes outside the model. If a source repository or connector is unavailable, the assistant should explain the limitation and route users to a supported manual process. It should not quietly fall back to remembered policy wording and present it as current. If the source set was refreshed, test whether the application still uses the intended version. A release that adds new documents can change retrieval behavior even without a prompt edit.
Treat source and prompt changes as versioned application changes
Assign ownership for the knowledge set, prompt, connector configuration and user-facing response format. Keep a record of important changes and representative before-and-after evaluations. When a policy changes, confirm that documents, structured rules, help text and flow approvals remain consistent. A sophisticated retrieval pipeline cannot correct a business organization whose sources disagree and have no accountable owner.
AB-410 study is most valuable when candidates can choose the right Power Platform asset for a requirement. Dataverse represents authoritative business records; connectors move information under defined permissions; prompts and AI models assist with language-driven interpretation; app and cloud-flow logic enforce process state and authorization. Grounding is reliable only when all four cooperate and the application’s claims remain traceable to the right customer, policy and point in time.
Check what happens when two sources legitimately disagree
A particularly useful acceptance case occurs when a public policy summary and an individual customer’s signed agreement use different language. The model must not treat the most recent or most easily retrieved passage as an automatic override. The application should identify the applicable agreement version, relevant effective dates and any authorized exception, then route an unresolved conflict to the proper business owner. Selecting the right authority is a domain decision, not a measure of semantic similarity.
Build this ambiguity into the test dataset with safe examples. Ask the assistant for a refund recommendation when the public policy permits thirty days but the customer’s signed terms specify a shorter window. The desired behavior might be to present the relevant provisions and request authorized review, not to invent a universal answer. Evaluate whether the app correctly separates fact, interpretation and final permission. When the review resolves the issue, update the authoritative record or knowledge source so the same conflict does not recur silently.
This case illustrates why source governance matters more than a sophisticated prompt. Good grounding is not just retrieving text; it is knowing which information governs the particular person, transaction and time period, and preserving human authority when the sources cannot settle the matter.