Skip to content

Guided tour

FabrCore 2.0 · Release and package availability

These guides track the current 2.0 source. Stable 2.0.0 publication is pending; package commands show the release target. Until it is published, follow the source quick start or use a matching available prerelease set. Release migration · Runtime modes

MODULE 10 · LESSON 10.12

Run the Microsoft integration checkpoint

Verify the complete Microsoft-connected request path.

Lesson 64 of 86 · FabrCore 2.0

Overview

An integration is ready only when the identities, permissions, routing and response format agree across systems. Local protocol tests catch implementation errors; tenant consent and service provisioning require live verification. Keep those forms of evidence separate.

Test the whole selected path

A local protocol test can verify serialization and route handling without proving a Microsoft tenant granted the intended permission. Conversely, a valid consent grant does not prove that the assistant returns a correctly routed answer. Use one representative Operations Desk request and record evidence at each boundary rather than collecting unrelated green status indicators.

Include negative cases in the acceptance record

Choose the actual channel and resource your product needs. Record caller/principal mapping, requested scopes, tool or remote-agent result, and the final visible response. Test revoked consent and a second identity as well as the happy path. Keep untested optional integrations explicitly out of the verified feature list.

Run a complete integration scenario

  1. Run one signed-in request through the local agent, Graph knowledge lookup and optional remote specialist, then return through web or Teams.
  2. Capture correlation and a redacted outcome at each boundary. Test revoked consent, denied scope, expired authorization and a text-only caller.
  3. Compare with the fixture path to isolate model behavior from transport/auth failures. Record the tenant/provider configurations actually tested.

Record one end-to-end result

  1. From the real test client/channel, ask the configured integration to perform a bounded read associated with SR-1042. Capture the visible answer and the relevant request/operation identifiers.
  2. Compare that answer with the authoritative Microsoft resource or remote-agent result. Confirm the same intended user/principal is attributed throughout.
  3. Revoke the test grant or deny the operation and repeat. The user should receive an actionable failure, with no leaked data or alternate-account fallback.

A useful acceptance record says what was exercised, under which identity and permission, and what actually returned. It does not claim coverage for other integrations merely because they share Microsoft branding.

If the result is different

Do not report production validation based only on mocks. A successful read does not validate a send/write operation or its required consent.

Go deeper

Explore the related documentation.