Templates › Copilot Studio solution design
Copilot Studio solution design
Template id: studio-solution-design
Responsible skill: copilot-studio:studio-agent-design. Sections are detailed with copilot-studio:topics-and-orchestration, copilot-studio:studio-knowledge-architecture, copilot-studio:studio-actions-and-tools, copilot-studio:studio-connectors, copilot-studio:studio-authentication, copilot-studio:dataverse-integration, copilot-studio:power-automate-actions, copilot-studio:conversation-design and copilot-studio:multi-agent-design.
Use this design after the agent brief is agreed and before build starts. Every fact the organisation must supply is marked [To confirm: ...]; replace the marker when the fact is confirmed, and never fill it with a guess. Example rows are fictional and are there to be replaced or deleted. Where a design choice depends on a product feature, record the source record checked and the date, because availability, limits and licensing change often.
1. Summary
| Field | Entry |
|---|---|
| Agent name | [To confirm: working name] |
| Agent brief reference | [To confirm: brief reference and date agreed] |
| Business owner | [To confirm: name and role] |
| Technical owner and co-owner | [To confirm: names or team] |
| Copilot Studio Architect or reviewer | [To confirm] |
| Risk tier (0-4) | [To confirm: tier from risk classification, with date] |
| Design status | Draft / Agreed / Reviewed / Superseded |
| Version and date | [To confirm] |
2. Question-to-mechanism map
Map each representative question from the brief to the mechanism that should handle it. This map seeds orchestration and knowledge tests.
| # | Representative question | Mechanism (knowledge / tool / authored topic / child or connected agent / exclusion) | Specific source, tool, topic or agent | Why this mechanism |
|---|---|---|---|---|
| 1 | Fictional example: "What is the mileage rate for a hire car?" | Knowledge | Fictional example: Travel policy library | Open question answered from owned policy |
| 2 | Fictional example: "Raise an expense claim for yesterday's taxi" | Tool | Fictional example: Create expense draft flow | Action in the expenses system with confirmation |
| 3 | [To confirm] | [To confirm] | [To confirm] | [To confirm] |
3. Design decisions
Record the decision, the default it departs from (if any), the alternatives rejected and the reason.
| Dimension | Decision | Alternatives rejected and why | Source record checked and date |
|---|---|---|---|
| Orchestration (generative, classic or mixed) | [To confirm] | [To confirm] | [To confirm] |
| Structure (one agent, child agents, connected agents) | [To confirm] | [To confirm] | [To confirm] |
| Authentication setting | [To confirm] | [To confirm] | [To confirm] |
| Channels | [To confirm] | [To confirm] | [To confirm] |
| Environments and solution | [To confirm] | [To confirm] | [To confirm] |
4. Topics and orchestration
| Item (knowledge source, tool, topic or agent) | Name | Description used by orchestration | Authored or generative | Reason an authored topic is needed |
|---|---|---|---|---|
| [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] |
System topic behaviour (greeting, fallback, escalation, errors, sign-in, end): [To confirm: summary or link to the conversation section]
Global variables and their scope: [To confirm]
5. Knowledge
| Source | Knowledge type | Scope (site, library, folder, table, domain) | Owner | Readiness verdict | Permission behaviour (trimmed to user / same for all) | Description | Refresh route |
|---|---|---|---|---|---|---|---|
| [To confirm] | [To confirm] | [To confirm] | [To confirm] | Ready / Ready with conditions / Not ready | [To confirm] | [To confirm] | [To confirm] |
Uploaded files (origin, owner, review date): [To confirm, or "none"]
Use of general model knowledge or public web: [To confirm: off, limited or on, with reason]
6. Tools, flows and connectors
| Tool | Type (connector action, flow, prompt, custom connector, REST API, MCP server) | System and operation | Read / create / update / send / delete | Identity it runs under | User confirmation | Failure message | Owner |
|---|---|---|---|---|---|---|---|
| [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm: end user or approved service identity] | Yes / No | [To confirm] | [To confirm] |
| Connector | Data policy group per environment | Account behind the connection | Data leaves tenant or region? | Owner |
|---|---|---|---|---|
| [To confirm] | [To confirm] | [To confirm] | Yes / No | [To confirm] |
Approvals for any shared or service identity: [To confirm: approver and date]
7. Dataverse
Complete if the agent reads or writes Dataverse records.
| Table | Columns used | Read / write | Identity and security roles | Sensitive columns excluded | Business rules relied on |
|---|---|---|---|---|---|
| [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] |
Where conversation records are stored, who can read them and retention: [To confirm]
8. Authentication and identity
| Channel | Authentication | Single sign-on configured and tested | Identity provider owner |
|---|---|---|---|
| [To confirm] | [To confirm] | Yes / No | [To confirm] |
Secrets and certificates with renewal dates (record in the ALM plan): [To confirm]
9. Conversation
| Behaviour | Specification |
|---|---|
| Greeting and AI disclosure | [To confirm] |
| Voice and style sheet reference | [To confirm] |
| Clarification rules | [To confirm] |
| Escalation triggers and destinations | [To confirm] |
| Context passed on hand-off | [To confirm] |
| Out-of-hours message | [To confirm] |
10. Multi-agent design
Complete only if the solution uses child or connected agents, or calls agents on other platforms.
| Agent | Pattern | Owner | Contract (purpose, inputs, outputs, version) | Context passed | Identity | Failure behaviour |
|---|---|---|---|---|---|---|
| [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] | [To confirm] |
End-to-end owner: [To confirm]
11. Environments, ALM and deployment
| Item | Entry |
|---|---|
| Development, test and production environments | [To confirm: names and zones] |
| Solution and publisher | [To confirm] |
ALM plan reference (alm-and-environment-plan) | [To confirm] |
| Channels and approved audience | [To confirm] |
| Rollout stages | [To confirm] |
12. Testing, analytics and run model
| Item | Entry |
|---|---|
| Test plan reference and release threshold agreed by business owner | [To confirm] |
| Zero-tolerance failures | [To confirm] |
| Success measures and where each is read | [To confirm] |
| Improvement review rhythm and attendees | [To confirm] |
| Support route for users | [To confirm] |
| Recertification frequency | [To confirm] |
13. Reviewer gates
| Reviewer | Required from tier | Finding summary | Blocking / advisory | Resolved? |
|---|---|---|---|---|
| Design authority | [To confirm] | [To confirm] | [To confirm] | Yes / No |
| Security and privacy | [To confirm] | [To confirm] | [To confirm] | Yes / No |
| Responsible AI | [To confirm] | [To confirm] | [To confirm] | Yes / No |
| Evaluation and quality | [To confirm] | [To confirm] | [To confirm] | Yes / No |
14. Open questions and preconditions
| Item | Owner | Due |
|---|---|---|
| [To confirm] | [To confirm] | [To confirm] |
15. Agreement
| Role | Name | Date |
|---|---|---|
| Business owner | [To confirm] | [To confirm] |
| Technical owner | [To confirm] | [To confirm] |
| Copilot Studio Architect | [To confirm] | [To confirm] |
Credit: Template from CopilotForge by Simon Foote (https://github.com/SimonFoote-greensparx/CopilotForge), licensed under CC BY 4.0. Keep this credit when you share or adapt the template; in your own completed document you may keep it as a footer or remove it.