I start with one job: answer a small set of service-desk questions. I add actions only after the answers and access controls are dependable.
Before I start
- Access to Copilot Studio and an environment where you may create agents.
- An appropriate subscription for publishing; trial agents can be tested but cannot be published.
- A small approved knowledge source, ten test questions, and an accountable service owner.
Step by step
Define a useful first task
I write a one-sentence outcome: “Help employees find the approved onboarding process.” I list what the agent must not do: approve access, reset credentials, or change production systems.
Create the agent
At copilotstudio.microsoft.com, choose the intended environment and create an agent. In the standard experience, describe its purpose, then inspect the generated name and instructions. The newer agent experience has different labels; use Microsoft’s matching instructions for your environment.
Set instructions and boundaries
I replace vague instructions with the template below. I explicitly tell the agent to acknowledge missing evidence and send unresolved requests to the service desk.
You help employees follow the approved onboarding process.
Use only the approved knowledge sources.
Give numbered steps and cite the source when available.
If the answer is missing or ambiguous, say so and ask a clarifying question.
Never invent approvals, passwords, access rights, or completed actions.
Escalate access changes to the service desk.Add a small knowledge source
Open Knowledge, add the approved source, and wait until it is ready. I use public test documentation or a deliberately restricted internal source first. I check the source permissions separately from who may access the agent.
Test normal and difficult questions
In the test chat, ask the ten prepared questions, including an out-of-scope request and a request to ignore instructions. I log expected answer, observed answer, source, and pass/fail in the test sheet. I require every critical test to pass.
Check authentication and data policies
Before publishing, I choose an authenticated internal channel, confirm the allowed audience, and review connectors and environment data policies with the platform owner. I test as a normal user as well as the maker; successful maker access is not proof of correct user access.
Publish to a pilot audience
Publish only with a suitable licence, then configure the intended channel. I start with a small group and document the owner, support route, cost limit, and release version. A demo website is appropriate for non-sensitive demonstrations.
Review before expanding
I inspect pilot failures and usage with the owner. For a later action such as ticket creation, I define the exact permitted fields, confirmation step, and connector identity before enabling it.
How I check the result
0 of 4 checks completed
Checklist progress stays in this browser. I use it to track checks, not to certify a deployment or compliance.
If something does not work
No creation option
Check the environment, maker permissions, experience selection, and licence.
Cannot publish
A trial may allow testing only. Confirm publishing entitlement and channel permissions.
Unsupported answer
Reduce the source set, clarify instructions, and add the failure to the test sheet.
My working templates
I record expected answers, permission checks, failures, and evidence before release.
Download CSV ↓I document the use, role, classification decision, and evidence for every AI system.
Download CSV ↓Official sources I checked
I checked these sources on 13 October 2026. Product screens and legal requirements change; I verify the relevant source before a production rollout or legal decision.