Copilot Studio Cheat Sheet

Fundamentals

Copilot Studio is the low-code tool for building agents — conversational and autonomous AI assistants grounded in your data and able to act on it. An agent combines instructions, knowledge (what it can answer from), tools (what it can do), and topics (authored conversation paths). It builds on Power Platform, so agents live in environments, ship in solutions, and obey DLP. (Copilot Studio is the successor to Power Virtual Agents; older bots are now labelled classic and don’t support the generative features.)

• Agent — the top-level thing you build and publish. New agents default to generative orchestration.
• Topic — an authored slice of conversation on a canvas, made of nodes (message, question, condition, tool call…).
• Knowledge — sources the agent searches to answer (SharePoint, Dataverse, files, public websites, web search…).
• Tool — an action the agent can call (connector, agent flow, prompt, REST API, MCP server, computer use).
• Orchestration — how the agent decides what to do next: generative (the model chooses) or classic (trigger phrases pick one topic).

Orchestration: generative vs classic

Orchestration decides who controls the next step — the model or the author. Generative orchestration (default for new agents) lets the agent pick the best mix of topics, tools, knowledge, and other agents from their descriptions, auto-ask for missing inputs, and compose the reply. Classic orchestration matches the user’s message to one topic’s trigger phrases and runs exactly what you authored. Toggle it on the agent’s Overview page under Orchestration.

Pick classic when the path must be exact

• Authentication and identity verification, consent capture, PCI / payment collection.
• Regulatory or legal wording that must be delivered verbatim, in a fixed order.
• DTMF menu flows and any journey where exact steps matter more than flexibility.
• You can still use generative answers inside a classic agent as a fallback for unmatched questions.

Topics & nodes

A topic is a portion of a conversation defined on the authoring canvas as a graph of nodes. Agents start with system topics (essential behaviours you can customise but not create) and a few predefined custom topics (greeting, end of conversation…). Every topic you add is a custom topic. Under the hood a topic is an AdaptiveDialog you can also edit as YAML in the code editor or the VS Code extension.

Key system topics

Triggering topics

A topic can start four ways: from the user’s utterance (intent recognition via trigger phrases, classic), because the agent chooses it from its description (generative), from a Redirect in another topic, or from an event (conversation start, inactivity, custom event, an error, an autonomous trigger).

Variables & scope

Variables store user responses and carry state. They live at four scopes. Question nodes auto-create an output variable of the right type; you can promote a topic variable to global, and pass variables in and out of topics and Power Automate (whole records and tables, not just primitives).

Useful system variables

Entities & slot filling

An entity is a type of information the NLU model extracts from a message (an email, a date, money, a person). Slot filling stores that extracted value into a variable — and lets the agent *skip* questions whose answers were already in the user’s opening line. “I’d like 3 large blue t-shirts” can fill quantity, size, and colour at once.

Custom entities

• Closed list — a fixed set of values with optional synonyms (e.g. *Hiking* ← “trekking”, “mountaineering”).
• Regular expression — values in a fixed format, ideal for IDs like INC000001 (^INC[0-9]{6}$).
• Dynamic (open list) entity — values supplied at runtime from a table variable (≤ 100 entries); great for per-user lists like payees or accounts.
• One of multiple entities — accept any of up to five entities at one turn; the answer is a *record* (Identifier.account, Identifier.phone…).

Power Fx in agents

Power Fx is the Excel-like formula language for logic inside an agent — set a variable, evaluate a condition, parse a string, shape a table, or build a dynamic Adaptive Card. It’s the *data* layer of the conversation: there are no UI/behaviour functions here (no Navigate, SubmitForm, screens). You set state with the Set a variable value node, not a Set() call, and reference variables with their scope prefix.

Reference variables by scope

System.Conversation.Id          // system variable
Global.gblUserName              // global variable
Topic.customerName             // topic variable
Environment.ApiBaseUrl         // Power Platform environment variable

Set a variable with a formula

Upper(Text(Topic.customerName))

A condition as a formula

Topic.bookingDate > DateAdd(Now(), 14)

Knowledge & grounding

Knowledge sources ground the agent’s answers in trusted content instead of the model’s general training. Add them on the Knowledge page (agent-wide) or in a Create generative answers node (topic-level). Internal files are chunked, vector-indexed, and stored in Dataverse; web and SharePoint use Bing/Graph search. Source limits differ by orchestration mode — and a generative-answers *node* always uses classic processing, so its public-site cap is 4 even when the agent is generative.

• Public website URLs allow up to two path levels (contoso.com/engines/rotary); sites that need auth or aren’t Bing-indexed (wikis, SharePoint) don’t work as public sources.
• Generative answers supported content: SharePoint modern pages, Word (.docx), PowerPoint (.pptx), and PDF.
• Dataverse knowledge needs Dataverse search enabled and Authenticate with Microsoft; add synonyms and a glossary so the model maps business terms.
• Citations are returned automatically; if you customise the answer (store it in a variable for a card) you must render citations yourself, especially in Teams.

Tools & actions

Tools let an agent *do* things, not just answer. In generative orchestration the agent calls tools automatically based on their name and description; in classic mode you call them from a node inside a topic. The same underlying tool (a flow, a connector) can be added to many agents, each with its own input/output wrapper.

Authentication

Set authentication under Settings → Security → Authentication. It controls who can chat, which variables you get, and which channels are available — and changes only take effect after you publish.

• Teams and all Microsoft channels require authentication — they can’t be anonymous. Use Microsoft auth, or manual auth if you also need other channels.
• User.AccessToken / User.IsLoggedIn only exist with manual auth — pick it when a topic needs a token for a downstream API.
• Federated credentials (secret-less, short-lived OIDC tokens) are the recommended manual setup over stored client secrets.
• A Power Platform data policy can *require* authentication, which removes the No-authentication option entirely.

Channels & publishing

You must publish before anyone can use the agent, and a single publish updates every connected channel — make a change, publish again, or users stay on the old version. Add channels after the first publish.

ALM & environments

Copilot Studio brings Power Platform ALM into the app. Every agent belongs to a solution; author unmanaged in DEV and import managed to TEST/PROD, or deploy with pipelines in one click. Keep config out of the agent so it travels cleanly between environments.

• Solutions — set a preferred/default solution so new agents and components land in the right place; export/import or use pipelines from inside Copilot Studio.
• Environment variables — store URLs, list names, and thresholds; reference them in Power Fx with Environment. so values rebind per environment.
• Connection references — one per connector/purpose so credentials rotate in a single place across all flows and tools.
• Environment strategy — at least DEV/TEST/PROD, governed with DLP and Managed Environments; lock down the Default environment.
• Avoid hardcoding — no inline site URLs, keys, or emails; secrets belong in Key Vault via environment variables.

Analytics

Every published agent emits analytics from the first conversation. The unit is the session: a continuous interaction addressing the user’s questions within a 60-minute window (and ≤ 100 turns). Review these monthly and act on the gaps.

Design best practices

• Lead with knowledge, author the exceptions. Ground broad Q&A in trusted sources; reserve topics for flows that must be exact.
• Write descriptions like briefs. In generative mode, topic/tool/knowledge descriptions *are* the routing logic — be specific about what and when.
• Keep topics bite-size and reusable. Redirect into shared topics; pass inputs/outputs; one fix propagates everywhere.
• Use entities and slot filling so the agent asks only for what’s missing — fewer turns, happier users.
• Centralise config in environment variables and connection references; never hardcode URLs, list names, or secrets.
• Authenticate by default, apply least-privilege scopes on tools, and prefer federated credentials over stored secrets.
• Test before you widen. Use the test canvas and demo website, validate negative paths, and re-check after flipping to generative orchestration.
• Publish deliberately — every publish hits all channels; review, then ship.