On this page
Test as the person who will ask the question
Hypothetical situation: a maker connects a policy knowledge source and receives a useful answer in a development test. A colleague then opens the published experience and receives no answer. Another colleague sees information the business owner did not intend for that audience. The maker’s successful test did not establish the published experience’s identity and information boundary.
Start by naming the actual user, deployment channel and knowledge source for the acceptance test. ‘The agent can read SharePoint’ is too broad. The useful question is which documents a particular person should be able to use through the experience being released.
Keep sign-in and authorisation separate. A person reaching a signed-in screen has not, by that fact alone, demonstrated the correct knowledge boundary. Equally, a missing answer does not prove that permissions are the cause. The test needs expected documents and a recorded identity before the team interprets the result.
When a source owner changes document permissions, agree how the team will establish that the published experience reflects the intended change. Record the relevant refresh and propagation conditions from the implementation rather than inventing an immediate guarantee. Repeat the controlled negative case after that process. If the result remains unclear, keep the access conclusion open and have the administrator inspect the evidence.
Use a dated example without generalising it
Microsoft’s February 2024 article describes a Copilot Studio sample wrapped in a SharePoint Framework component. The component exchanges the signed-in user’s token so the copilot can access protected SharePoint and OneDrive sources on that user’s behalf. Its example limits answers to site material the user already has access to.
That establishes a specific documented approach before this coverage date. It does not mean every channel, connector or authentication setup behaves identically. The article also describes app-registration and Azure-permission setup for the sample. Do not present it as a switch that automatically fixes every knowledge-access problem.
For your review, have the administrator document the supported configuration actually in use. Record whether the intended channel has the necessary authentication arrangement and whether the source has the intended audience. This article does not supply current UI instructions or a universal permission recipe. Validate those implementation details against the environment before changing it.
Prepare positive and negative knowledge cases
Create a controlled document set with clearly distinguishable statements. Include one document intended for the test user and another excluded from that user’s audience. Use harmless invented content, not a real confidential policy, to test the negative case. Ask questions that would reveal which source was used.
Run the same cases through the actual published experience with the approved test identities. Inspect both the answer and its references. If a result is unexpected, establish which document was retrieved and under which identity before changing permissions. Do not treat a refusal as sufficient proof of a secure configuration; the source may simply be missing or unavailable.
Avoid testing only the maker account, which may hold broader rights than the receiving team. Keep the maker’s diagnostic route in a separate row so the difference remains visible. The proposed matrix is a review practice, not a claim that a prompt enforces permissions or that an answer alone proves every access control.
| Identity and route | Source expectation | Evidence |
|---|---|---|
| Intended user in published channel | Permitted fixture can support an answer | Answer, source reference and identity |
| Excluded user in published channel | Restricted fixture is not disclosed | Negative case and configuration review |
| Maker diagnostic route | Record separately from consumer access | Do not generalise maker success |
| Changed-permission case | Follow the agreed propagation and refresh behaviour | Retest after the documented process |
Include the channel in the handover
Record the published route, source owner and administrator responsible for authentication. Identify when the access tests must be repeated: after a channel change, authentication change, source change or material permission update. Keep the evidence with the operational record so support can distinguish a source problem from a user-access issue.
Ask the receiving team to perform a simple permitted query and explain where to report an unexpected disclosure or missing answer. They should not have to ask the maker to run every question using a privileged account. Also make clear who maintains the documents themselves; technically correct access can still expose outdated guidance.
For a practical lab, give participants a successful maker test and an incomplete consumer test record. Ask them what evidence is missing before they approve release. The useful outcome is a precise question about identity, source or channel, followed by a repeatable check. ‘It worked in the test pane’ should remain a diagnostic observation rather than the entire acceptance decision.
Sources & further reading (1)
Historical evidence checked . Review practices and hypothetical exercises are editorial recommendations, not product guarantees.
