AB-100 Grounding: Dynamics 365, Dataverse and SharePoint

AB-100 Grounding: Dynamics 365, Dataverse and SharePoint

A support agent tells a customer the wrong warranty date. The model might be functioning as designed: the response used an outdated SharePoint article, an incorrectly matched Dynamics 365 case, or a Dataverse record that should have been invisible to this user. Grounding is not simply attaching documents to a model. It is an architecture for current, authorized and accountable facts.

Microsoft’s AB-100 exam asks solution architects to assess the relevance, timeliness, completeness and access boundaries of data used in AI business solutions. Consider the warranty service below: its system of record, policy documents, retrieval mechanisms and customer identity must agree before the agent can safely act.

Map the business facts to authoritative sources

An integration review should also describe what makes a record identifiable across systems. The CRM case may reference a customer by one internal key while the order platform uses another. A join based on a display name or email can merge people incorrectly after an address change or account reuse. Establish a canonical relationship with validation and a controlled way to handle missing or conflicting identifiers. Keep that mapping visible to the team responsible for correcting it.

In a design workshop, walk through a customer who changes their surname, owns two products and has an old support case under a different region. Ask how each source would recognize the person without disclosing another account’s history. If the team cannot demonstrate the join safely with ordinary data, adding a generative model will not repair the identity problem.

A manufacturer handles claims using Dynamics 365 Customer Service cases, Dataverse customer and product entities, SharePoint policy documents, and an order platform with purchase and shipping facts. Each source has its own update schedule, owner and authorization model. If the agent retrieves the most similar text without identifying the authoritative record, it may confidently quote the wrong customer’s contract.

Document a source matrix before indexing: which question each source answers, its stable identifier, update expectations and the business owner who may correct it. A serial number and delivery status normally call for structured record lookup; warranty exclusions may require a published policy clause. An employee’s free-text case note is context, not necessarily an approved customer-facing rule.

When a new system is added, update the matrix and tests. A clever retrieval layer cannot decide on its own whether a newly synced spreadsheet has authority to override the contract database.

Separate relevant text from current, complete data

A document can match the customer’s question and still be expired. Another can describe the right product but the wrong market. A third may omit the exceptional plan purchased by the customer. Relevance, freshness and coverage are separate dimensions: none can be inferred from a single high semantic similarity score.

Define a freshness target for each source. Use a live transaction lookup for volatile order state where possible, and controlled document ingestion for relatively stable published guidance. Carry an effective date or version into the retrieved evidence. If a recent policy cannot be confirmed, the agent should say so or escalate rather than fabricate a current answer.

Test a source outage independently of an unknown answer. If the order API is temporarily unavailable, treat that as missing evidence, not proof the customer has no eligible order.

Enforce permissions before a record reaches the model

A Copilot Studio connector backed by a privileged service account might be able to read all Dataverse cases. That does not authorize the customer-facing agent to summarize any case the user asks about. The model instruction “respect permissions” is not sufficient if unauthorized content has already entered the prompt or retrieval context.

Where delegated authorization is supported, validate the actual caller’s permissions. When a service identity is required, enforce resource ownership, field visibility and business-purpose checks on the server. The Power Platform agent overview gives broader context; AB-100 architecture requires proving that an identical query returns different permitted records for two different users.

Include ambiguous customer-name cases and deliberate attempts to request another customer’s data. A confident refusal or safe clarification is the expected behavior when authorization cannot be established.

Use exact structured lookups alongside document retrieval

Dataverse tables have defined keys, relationships and field types. To determine whether order 123 is covered, validate the customer and exact order ID before retrieving entitlement fields. Embedding search is useful for longer passages but is poorly suited to choosing an authoritative financial value from similarly named records.

SharePoint documents need version identity and enough neighboring text to preserve conditions and exceptions. A chunk containing “twelve-month warranty” may be misleading if the next paragraph excludes a particular refurbished model. Test the retrieved passage in context, not just the line that matches a query.

A robust response can combine a validated transactional record, a specific policy version and a deterministic eligibility rule, then have the model explain the result. The result should not depend on the model inventing missing identifiers or overriding the eligibility function.

Resolve source conflicts explicitly

Imagine the general SharePoint policy grants twelve months, while a Dataverse contract states that a customer purchased a twenty-four-month extension. If both sources are authentic, the higher-ranking text snippet is not automatically correct. Define precedence in the business rules: a valid customer-specific entitlement might override a general default.

Record the scope and effective date of exceptions, along with a responsible owner. If two supposedly authoritative records disagree, hand off a case with the conflicting evidence rather than averaging the values or allowing the model to decide which database “seems more credible.”

Create tests for ordinary entitlements, legitimate overrides, expired documents and conflicting source data. The test passes only when the source precedence and final user communication align with approved policy.

Preserve provenance without overlogging customer data

Support staff should be able to determine which order record and policy revision supported an agent’s statement. A generic hyperlink to the organization’s help center is not a useful citation. Prefer source references and effective dates where the interface can expose them to authorized reviewers.

Telemetry can capture relevant source IDs, model and agent version, action outcome and correlation identifiers without storing an entire private customer record in a broadly accessible debug system. Protect logging access separately from original business-data access.

When a source is corrected or deleted, test whether the retrieval cache and index have followed the change. A successful indexing job in isolation is not evidence that a published agent stopped citing the old policy.

Separate explanation from the authority to change business state

“Explain the returns policy” is a knowledge request. “Is my order eligible?” needs verified identity, a live order record and a rule. “Issue the refund” invokes a financial action with different authorization and perhaps human approval. Design those as distinct routes rather than asking one unrestricted agent to infer its own authority.

Retrieved content can include outdated instructions or even untrusted text telling an assistant to ignore constraints. Treat it as evidence, never permission. Tool calls should validate parameters, access and relevant business preconditions outside generated language.

If the sources remain contradictory, the right output is an unresolved case with supporting references. A plausible guess can create an expensive and auditable business error.

Test grounded answers after every source or model change

Use a release comparison across two policy versions rather than evaluating the latest agent only against its own answers. In the first version, one product category has a standard warranty; in the second, a customer-specific entitlement extends coverage. Keep the same synthetic customer and order identifiers in both tests, then change only the relevant source version. The expected answer should change for the entitled customer and remain unchanged for unrelated customers. If other answers drift, inspect retrieval scope, indexing and record joins before blaming the language model. This is a practical way to turn data governance from a diagram into a verifiable deployment condition.

Use an explicit evaluation ledger: scenario identifier, user authorization scope, source versions, expected allowed action, expected refusal or escalation, actual result and reviewer decision. Pair automated checks for record and format correctness with human review of ambiguous explanations. A system can cite the expected document and still draw the wrong conclusion about an exception. Count that as a failure rather than granting credit for having a citation.

The same tests support safe release decisions when indexing rules, model versions or permissions change. If a new retriever improves answer fluency but starts choosing outdated customer-specific clauses, reject the release or limit its scope until the defect is understood. Business trust grows from reproducible evidence and a documented ability to roll back, not from an impressive one-off demonstration.

Create fictional customers with similar names, overlapping product numbers and two versions of a warranty policy. One test identity may view only one account. Ask about a normal claim, an extended entitlement, an expired policy, missing data and an unauthorized record. Specify the expected sources and safe escalation for each.

Measure unsupported-answer rate, wrong-record selection, stale version use and the effectiveness of access-denial behavior. A retrieval similarity score does not establish whether a customer was correctly told about a refund. Repeat the tests after changing connectors, document ingestion, permissions or the model.

The architect’s real deliverable is a traceable and enforceable data contract. Grounding is successful when answers stay current, within permission boundaries and supported by the right business evidence—even when a source fails or a user asks an adversarial question.

• Category: Certifications Microsoft