A named formula in Power Apps works like a named cell in Excel. You assign a name to a formula once, and Power Apps automatically updates that value wherever you reference it, without you writing a single line of “update” code. You don’t set it once and forget it, either—Power Apps recalculates it in real time whenever the underlying data changes, so every screen always shows the correct number.

Think of a sales team tracker built on a SharePoint list called SalesTracker, with columns for SalesRep, Region, Amount, and Status. Instead of writing the same “total approved sales” calculation in three galleries and a label, you write it once as a named formula, and every control that uses it stays in sync automatically. This one change in how you think about app logic can save you hours of debugging later, especially as your app grows past a handful of screens.

In this article, I’ll show you 5 ways to do named formula in Power Apps.

What Makes Named Formulas Different

A named formula lives inside the App object’s Formulas property, and it recalculates automatically whenever the data it depends on changes. Unlike a variable created with Set() or UpdateContext(), you never manually update a named formula—Power Apps controls exactly when it recalculates. This is a big mindset shift if you’re used to working with variables, where you decide when a value updates.

With variables, you write the update logic yourself, usually inside a button’s OnSelect property or in App.OnStart. With named formulas, you specify what the value should be, and Power Apps determines when to recalculate it.

This makes named formulas ideal for values that should always reflect the current data, such as totals, filtered lists, or user role flags. It also means your app has fewer moving parts to break, since there’s no risk of forgetting to update a value somewhere.

Before you start, know that named formulas require a modern Power Apps environment with the Power Fx formula bar enabled. Most apps created in the last couple of years already have this by default, so you likely won’t need to change any settings.

Method 1 – Basic Named Formula for a Simple Value

This method works best when you need a single reusable value, like today’s date or a constant business rule, available across every screen in your app without recalculating it manually each time.

Step 1: Open the App Formulas property

Go to Power Apps Studio → Tree view → App (select App from the dropdown at the top-left of the formula bar), then choose Formulas from the property dropdown. This property is different from OnStart, so don’t confuse the two.

CurrentQuarter = RoundUp(Month(Today())/3, 0);

Here is a screenshot for your reference.

How does this formula work?
RoundUp rounds a number up to the nearest whole number, and Month(Today()) gets today’s month number. Dividing by 3 and rounding up converts any month into its correct calendar quarter (1 to 4). You never need to update this manually—it recalculates itself every single day.

Step 2: Reference the named formula anywhere in your app

Add a Label control (Power Apps Studio → Insert → Text Label) and set its Text property:

"Current Quarter: " & CurrentQuarter

You can now reuse CurrentQuarter on any screen in your app, and it will always show the correct value without any extra code.

Pro Tip: Named formulas must always end with a semicolon, even the last one in the list. Forgetting it is the most common reason a named formula shows an error.

Check out Display Manager Name and Email in a Power Apps Gallery

Method 2 – Named Formula That Filters a Data Source

Choose this method when you want a consistently filtered view of your data—like “approved sales only”—available in multiple galleries without repeating the Filter() logic on every screen.

Step 1: Define the filtered named formula

In App → Formulas, add:

ApprovedSales = Filter(SalesTracker, Status = "Approved");

How does this formula work?
Filter() returns only the records from SalesTracker where Status equals “Approved.” Because this is a named formula, Power Apps automatically re-evaluates it every time the underlying list changes—you never call Refresh() manually for this value.

Step 2: Bind a Gallery to the named formula

Insert a Gallery control (Power Apps Studio → Insert → Layout → Vertical Gallery) and set its Items property:

ApprovedSales

Step 3: Reuse the same named formula on a second screen

Add another gallery on a different screen, maybe a “Manager Dashboard” screen, and set its Items property to the exact same value:

ApprovedSales

Both galleries now stay perfectly in sync. If a sales rep’s status changes from “Pending” to “Approved,” both screens update automatically without any extra code from you.

Pro Tip: If SalesTracker is a large SharePoint list, confirm that Filter() with a simple equality check like Status = “Approved” is delegable. Non-delegable filters silently cap results at 500 or 2000 records, so your totals could quietly become wrong without any error message.

Read Get Manager Details for the Current User in Power Apps

Method 3 – Named Formula for Aggregated Totals

Use this when you need live totals or counts, such as total approved sales amount, shown on a dashboard screen that updates as data changes without you refreshing anything.

Step 1: Create a named formula that sums a column

TotalApprovedAmount = Sum(ApprovedSales, Amount);

How does this formula work?
Sum() adds up the Amount column across every record returned by ApprovedSales. Because named formulas can reference other named formulas, you build a clean chain of logic without repeating the Filter() expression a second time.

Step 2: Display the total on a dashboard label

Text(TotalApprovedAmount, "$#,##0")

Step 3: Add a record count alongside the total

You can chain a second named formula right after the first one in the same Formulas property:

ApprovedSalesCount = CountRows(ApprovedSales);

Now both TotalApprovedAmount and ApprovedSalesCount stay live on your dashboard, updating instantly whenever a sales rep’s record changes status.

Pro Tip: Named formulas can reference each other in any order because Power Apps figures out the dependency chain for you—you don’t need to worry about which one loads first or write them in a specific sequence.

Check out Delegation in Power Apps

Method 4 – Named Formula for User Role or Access Logic

This method is suitable for scenarios where you need to show or hide controls based on who is logged in, such as allowing only regional managers to edit records in your sales tracker.

Step 1: Define a role-check named formula

IsRegionalManager = User().Email in ["manager1@company.com", "manager2@company.com"];

How does this formula work?
User().Email returns the signed-in user’s email address. The in operator checks whether that email exists inside your list of manager addresses, returning true or false automatically the moment the app loads.

Step 2: Use the named formula to control visibility

Select an Edit button (Power Apps Studio → Insert → Button, modern Fluent-based control) and set its Visible property:

IsRegionalManager

Step 3: Reuse the same logic to lock form fields

On an Edit form (Power Apps Studio → Insert → Forms → Edit form), set the DisplayMode property of a data card to:

If(IsRegionalManager, DisplayMode.Edit, DisplayMode.View)

This way, regular sales reps can view records, but only managers can actually edit them, all controlled from a single named formula.

Pro Tip: For real security, pair this with server-side permissions on the SharePoint list or Dataverse table—hiding a button only changes what users see, not what they can technically access through other means like Power Automate flows.

Check out Power Apps Notify Function

Method 5 – Named Formula with a User-Defined Function

Choose this experimental approach when the same calculation requires different inputs each time, such as calculating commission for any sales amount you pass in, rather than a fixed value.

Step 1: Define a user-defined function alongside your named formulas

CalculateCommission(SaleAmount: Number): Number = SaleAmount * 0.1;

How does this formula work?
A user-defined function works like a named formula but accepts a parameter (SaleAmount) and returns a calculated result. You write the logic once, then call it with different values wherever you need it, which named formulas alone cannot do.

Step 2: Call the function inside a gallery label

Text(CalculateCommission(ThisItem.Amount), "$#,##0")

Step 3: Reuse the function with a different tier

You can define a second function with a different rate for senior sales reps:

CalculateSeniorCommission(SaleAmount: Number): Number = SaleAmount * 0.15;

Now you have two clean, reusable functions instead of two long, repeated formulas scattered across your app.

Pro Tip: User-defined functions are still an experimental feature, so check Power Apps Studio → Settings → Upcoming features and enable them before use, and avoid relying on them in production apps until Microsoft marks them as fully supported.

Check out Power Apps Collect Function

Things to Keep in Mind

• Named formulas are immutable: Once Power Apps calculates a named formula, you cannot use Set() to override it—if you need a changeable value, use a variable instead.
• Check delegation before filtering large lists: Filter() on a SharePoint list or Dataverse table only pushes the query to the server for delegable operators; non-delegable filters truncate your data silently on large tables.
• Named formulas beat App.OnStart for initialization: Loading data through App.OnStart runs once at launch and can slow down startup, while named formulas calculate on demand and stay current automatically.
• Global variables still have their place: Use Set() for values users actively change, like a toggle or a selected filter, since named formulas cannot be manually updated at runtime.
• Canvas apps only, for now: Named formulas and user-defined functions currently work only in Canvas Apps, not in model-driven apps, so keep that in mind if you switch between app types.
• Don’t forget the semicolon: Every named formula in the Formulas property needs a trailing semicolon, including the very last one, or the whole property fails to save.

Named formulas in Power Apps offer five practical ways to centralize logic, ranging from simple constants to filtered data and user-defined functions with parameters. For most sales tracker style apps, start with a filtered named formula for your core dataset, then layer aggregation and role-based formulas on top as your app grows in complexity. I hope you found this article helpful.

You may also like:

• Power Apps Concatenate Strings

A hover effect is a small visual change — such as a color shift, a shadow, or a slight animation — that occurs when a user hovers over a gallery item. Think of a sales team tracker where each row shows a rep’s name, region, deal amount, and status. When a manager scrolls through that list, a subtle hover highlight helps them quickly spot the row they’re about to click, making the whole app feel more polished and responsive.

In this article, I’ll show you 4 ways to add hover effects to Power Apps gallery items.

I’ll use one consistent example throughout: a Sales Tracker gallery built from a data source with columns SalesRep, Region, Amount, and Status.

With the table data below, I have created the Sales Tracker list:

In the SharePoint Online site, I have created a SharePoint list with the above data. Here is a screenshot for your reference.

Before trying out any methods, I would suggest you create a responsive canvas app using Microsoft Power Apps.

Once the app is created, add a SharePoint data source to add the Sales Tracker list into the canvas app.

Next, add a Power Apps vertical gallery control to the Body container of the canvas app, then choose the Sales Tracker data source. Here I choose the layout of the gallery as: Title, subtitle, and body. Based on this, I choose which columns to display. You can see the screenshot below:

Method 1 – Use the Gallery’s Transition Property

This is the fastest built-in option, and it works well when you just want a simple “pop” or “push” motion without touching a single formula.

Step 1: Select your gallery control

In Power Apps Studio, click on the Sales Tracker gallery in the Tree view on the left, or click directly on the gallery in the canvas.

Step 2: Open the Transition property

Go to the Properties panel on the right side of the screen. Look for the Transition dropdown — it’s set to None by default.

Transition = Transition.Pop

You can see the properties I set for the gallery control in the screenshot below:

How does this formula work?
This isn’t really a formula — it’s a property setting. Pop makes the item lift outward when the mouse hovers over it, while Push makes the item press inward slightly. Power Apps applies this animation automatically to every row in the gallery, so you don’t need to configure each item individually.

Step 3: Test the effect

Click Preview (F5) or press Alt and hover your mouse over different rows in the Sales Tracker gallery to see the pop or push motion in action.

Pro Tip: The Transition property only affects motion, not color. If you want a color change alongside the animation, combine this method with Method 2 below.

Method 2 – Change Background Color with HoverFill on a Button

This method works best when you want a solid color highlight behind each row, similar to how table rows highlight in Excel. It’s the most requested hover effect in the Power Apps community.

Step 1: Add a transparent button as the top layer

Inside the gallery template, go to Insert → Button. Resize it to cover the entire row and move it to the top layer using Reorder → Bring to Front. Right-click the control to see the output. Ensure you add a classic button control.

Step 2: Set the button’s size to match the template

Height = Parent.TemplateHeight
Width = Parent.TemplateWidth

How does this formula work?
Parent refers to the gallery template that holds this button. TemplateHeight and TemplateWidth are built-in properties that return the exact size of one gallery row. Setting the button to match ensures the hover effect covers the whole row, not just part of it.

Step 3: Make the button transparent and set HoverFill

Fill = RGBA(0, 0, 0, 0)
HoverFill = RGBA(0, 120, 212, 0.15)
BorderThickness = 0

How does this formula work?
RGBA sets a color using Red, Green, Blue, and Alpha (transparency) values. Setting Fill to fully transparent (Alpha = 0) means the button is invisible until the mouse hovers over it. HoverFill only activates during a mouse hover and shows a soft blue tint at 15% opacity, so the rows behind it — like SalesRep and Amount — remain fully visible.

Step 4: Route clicks through the button

OnSelect = Select(Parent)

How does this formula work?
Since the button now sits on top of every control in the row, it intercepts all clicks. Select(Parent) tells Power Apps to trigger the gallery’s own OnSelect logic when the button is clicked, so you don’t lose your existing click behavior.

Pro Tip: Hover effects only apply to the item currently under the mouse cursor — Power Apps does not let you trigger hover states on other rows at the same time.

Now, when I preview the app and hover the Power Apps gallery item, you can see how the hover color is appearing like in the screenshot below:

Check out How to Set Control Value in Button Click on Power Apps?

Method 3 – Highlight Selected and Hovered Items with Conditional Formatting

This method is suitable for scenarios where you need to show both a hover state and a permanently selected state, such as allowing a manager to click a sales rep’s row and keep it highlighted.

Step 1: Add a background rectangle inside the template

Go to Insert → Shapes → Rectangle inside the gallery template and place it behind the text controls.

Step 2: Set its Fill property with an If function

Fill = If(ThisItem.IsSelected, ColorFade(Color.RoyalBlue, 0.7), Color.White)

How does this formula work?
ThisItem.IsSelected checks whether the current row is the one the user selected. If returns one color when true and another when false. ColorFade lightens RoyalBlue by 70%, creating a soft highlight instead of a harsh solid color.

Step 3: Layer a transparent button for the hover state

Repeat the button setup from Method 2, but set its HoverFill to a lighter shade than the selected color so users can visually tell hover and selected states apart.

HoverFill = If(ThisItem.IsSelected, ColorFade(Color.RoyalBlue, 0.7), ColorFade(Color.LightGray, 0.5))

How does this formula work?
This nested If makes sure a row that’s already selected doesn’t visually “flicker” to a different color on hover — it keeps the selected look, while unselected rows show a light gray hover tint.

Pro Tip: Avoid using bright, high-contrast HoverFill colors on Status columns with existing conditional formatting (like red for “Overdue”) — the hover tint can make status colors hard to read.

Check out Power Apps Switch Function

Method 4 – Apply Hover Effects to Icons and Labels Individually

Use this method when you want only specific elements — like a Status icon or Amount label — to react on hover, rather than the entire row.

Step 1: Select the individual control

Click on the specific label or icon inside the gallery template, such as the Amount label.

Step 2: Set its HoverColor or HoverFill property directly

HoverColor = Color.DarkBlue
HoverFill = RGBA(255, 255, 255, 0.1)

How does this formula work?
Most modern controls in Power Apps, including labels, icons, and buttons, expose HoverColor (text color on hover) and HoverFill (background color on hover) as native properties. You don’t need a button overlay here because the control itself supports hover states directly.

Pro Tip: Plain Text Label controls without a Fill property (transparent background labels) won’t show HoverFill visibly — pair them with a shape or button behind them if you need a visible hover background.

Read Power Apps Concatenate Strings (With Real Examples)

Things to Keep in Mind

• Gallery templates don’t support hover natively: The gallery container itself has no HoverFill property — you must use buttons, shapes, or individual controls inside the template.
• Layer order matters: If your transparent button isn’t the top layer, other controls will block the hover effect from being seen.
• Watch performance on large data sources: Adding complex If or ColorFade formulas to every row’s Fill or HoverFill can slow down rendering on large SharePoint lists or Dataverse tables with hundreds of rows.
• Delegation isn’t affected by hover formulas: Since HoverFill and Transition are visual-only properties, they don’t get delegated to the data source, but heavy nested logic still adds client-side rendering overhead.
• Test on touchscreens: Hover effects rely on mouse movement, so tablet and phone users won’t see them — always add a tap-based visual cue like IsSelected as a backup.
• Use named formulas for shared hover colors: If multiple screens use the same hover color scheme, define it once as a named formula instead of repeating RGBA values across every gallery.

Power Apps gives you four solid ways to add hover effects: the built-in Transition property for quick animations, layered buttons for full-row color highlights, conditional formatting for combined selected-and-hover states, and individual control properties for targeted effects.

For most beginners building something like a Sales Tracker gallery, start with Method 1 for a quick win, then move to Method 2 once you need real color feedback. I hope you found this article helpful.

You may also like:

• Power Apps Modern Checkbox Control

Microsoft Copilot Studio is that better way. It’s a low-code, graphical platform from Microsoft that lets you build AI-powered agents (also called chatbots or copilots) without writing a single line of code. Think of it as a visual drag-and-drop tool where you define what your bot knows, what it says, and what actions it can take — all from a browser.

For example, an HR team at a 300-person company can build an internal helpdesk agent in Teams that answers leave balance queries, routes IT tickets, and escalates complex issues to a live agent — all in one afternoon.

In this article, I’ll show you 5 ways to use Microsoft Copilot Studio to build and deploy AI agents for your business.

What Is Microsoft Copilot Studio?

Microsoft Copilot Studio (previously known as Power Virtual Agents) is a tool in the Microsoft Power Platform family. You access it at copilotstudio.microsoft.com. It lets you create agents — intelligent assistants that can hold conversations, answer questions, trigger workflows, and even act autonomously on your behalf.

An agent in Copilot Studio is made up of:

• Topics — individual conversation blocks that define what the agent says and does when a user asks something
• Nodes — building blocks inside each topic (like Message nodes, Question nodes, and Condition nodes) that control the conversation flow
• Knowledge sources — documents, SharePoint sites, or websites the agent can search to generate answers
• Tools — Power Automate flows, connectors, or HTTP requests that let the agent take real-world actions

Agents can be deployed to Microsoft Teams, websites, mobile apps, Facebook, and any channel supported by the Azure Bot Service.

Two Orchestration Modes to Know

Before you start building, you need to understand the two orchestration modes in Copilot Studio. This is the single most important concept for beginners.

• Classic orchestration: The agent uses trigger phrases — specific keywords or sentences you define — to match user input to the right topic. Think of it as a keyword-matching system with NLU (Natural Language Understanding) on top. Best for structured, predictable conversations.
• Generative AI orchestration: The agent uses a large language model (LLM) to dynamically decide which topic, tool, or knowledge source to use. It reads the description of each topic to understand intent. Best for open-ended, free-form conversations.

You can mix both modes in one agent. Now let’s build one.

Scenario used throughout this guide: You’re building an HR Helpdesk Copilot for Contoso Ltd, a company of 300 employees. The agent will live in Microsoft Teams and answer common HR questions — leave balances, payroll dates, and expense policy — while also logging support tickets in SharePoint.

Method 1 – Build a Manually Authored Topic (Classic Orchestration)

Use this method when you need the agent to follow a very specific, controlled conversation flow — like collecting employee details before showing leave balance information. This is the best starting point for any beginner.

Step 1: Open Copilot Studio
Go to copilotstudio.microsoft.com and sign in with your Microsoft 365 account. Select your environment from the top-right dropdown. Always use your organization’s environment, not the default one, to keep agents organized.

Step 2: Create a New Agent
Select Create from the left nav, then choose New agent. Give it a name — for example, Contoso HR Helpdesk. Add a short description like “Helps employees with leave, payroll, and expense queries.” Select Create.

Step 3: Add a New Topic
Navigate to Topics in the left menu. Select Add a topic → From blank. A blank authoring canvas opens with a Trigger node at the top.

Step 4: Set Trigger Phrases
Select the three dots (…) on the Trigger node → Properties. In the Phrases panel, add 5–8 trigger phrases such as:

How many leave days do I have?
Check my leave balance
Annual leave remaining
How much leave is left?
Leave balance query

These phrases train the NLU model to recognize when an employee is asking about leave.

Step 5: Add a Question Node
Select the + icon under the Trigger node → Ask a question. A Question node appears. Type: “Sure! What is your employee ID?” Under Identify, select User’s entire response. This stores the answer in a variable — name it Topic.EmployeeID.

Step 6: Add a Message Node
Select + → Send a message. Type: “Thank you, {Topic.EmployeeID}. Your leave balance request has been logged. HR will respond within 24 hours.” The curly braces reference the variable you captured earlier.

Step 7: End the Conversation
Select + → Topic management → End conversation. Optionally select End with survey to collect satisfaction data.

Step 8: Save and Test
Select Save in the top bar. Open the Test your agent panel on the right. Type one of your trigger phrases and walk through the conversation.

Pro Tip: Use 5–10 varied trigger phrases per topic. If two topics have overlapping phrases (e.g., “leave” appearing in both a Leave Balance topic and a Leave Request topic), the agent will misfire. Keep trigger phrases unique and specific to avoid topic conflicts.

Check out Environment Strategy for Copilot Studio: Dev, Test, Prod Best Practices

Method 2 – Use Generative AI to Answer Questions from a Knowledge Source

Use this method when you want the agent to answer questions it wasn’t explicitly programmed for — by reading documents, SharePoint pages, or websites. This is the fastest way to build a broad FAQ-style agent.

Step 1: Go to Knowledge
In your Contoso HR Helpdesk agent, select Knowledge from the left navigation menu.

Step 2: Add a Knowledge Source
Select Add knowledge → choose from the options:

• Files (upload PDFs or Word docs — e.g., the HR Policy handbook)
• SharePoint (point to an HR SharePoint site)
• Public website (e.g., your company’s benefits page)

Select SharePoint, paste the URL of your HR SharePoint site, then select Add.

You can see in the screenshot below that I have uploaded a PDF.

Step 3: Enable Generative Answers
Go to Settings → Generative AI. Make sure the Allow the agent to use its own general knowledge toggle is configured to your preference. You can also control whether the agent uses only your uploaded sources or the broader web.

Step 4: Set Orchestration Mode to Generative
In Settings → Generative AI → How should your agent decide how to respond?, select Generative (Preview). This switches the agent from trigger-phrase matching to AI-driven intent detection.

Here is a screenshot for your reference.

Step 5: Test a Question Not in Any Topic
Open the Test panel and type: “What is the company’s maternity leave policy?” The agent will search your SharePoint knowledge source and generate a plain-language answer — without you writing a single topic node.

How does this work?
The agent sends the user’s question to the Azure OpenAI GPT model along with content retrieved from your knowledge source. It generates a grounded, conversational answer in real time. It cites the source document so employees can verify.

Pro Tip: Generative AI answers are only available with a standalone Copilot Studio subscription — not the Teams-only plan. If your agent is purely Teams-based on a Microsoft 365 license, you must use classic orchestration with manually authored topics.

Read How Generative AI Works Inside Copilot Studio

Method 3 – Trigger a Power Automate Flow from a Topic

Use this method when the agent needs to do something — not just say something. For example: log a support ticket in SharePoint, send an email notification, or look up data from an API. This is where Copilot Studio becomes a true automation hub.

Step 1: Design the Scenario
In the HR Helpdesk copilot, you want employees to raise an IT support ticket directly from the chat. The agent collects the issue description and severity, then logs it as a SharePoint list item.

Step 2: Create a Power Automate Flow
In Copilot Studio, go to Topics → open or create your Log IT Ticket topic. Select + → Call a tool → Create a new flow. This opens Power Automate in a new tab.

The flow template pre-built for Copilot Studio has:

• A Run a flow from Copilot trigger — this receives inputs from the agent
• An action block where you build your logic

Step 3: Configure Flow Inputs
In Power Automate, select the Run a flow from Copilot trigger. Add two inputs:

• IssueDescription (Text)
• Severity (Text)

Then add a Create item action from SharePoint. Map the fields:

Site Address: https://contoso.sharepoint.com/sites/IT
List Name: IT Support Tickets
Title: [IssueDescription]
Severity: [Severity]
Status: New

Add a Respond to Copilot action at the end. Add an output variable: TicketID (Text). Set its value to the ID of the new SharePoint item.

Step 4: Save and Return to Copilot Studio
Save the flow. Return to Copilot Studio. Your new flow now appears as an available tool in the topic canvas.

Step 5: Wire the Flow into the Topic
Before the Call a tool node, add two Question nodes to collect:

1. “Please describe your issue.” → store in Topic.IssueDescription
2. “How severe is this issue? (Low / Medium / High)” → store in Topic.Severity

Then in the Call a tool node, select your Power Automate flow. Map:

• IssueDescription → Topic.IssueDescription
• Severity → Topic.Severity

Capture the output TicketID → store in Topic.TicketID.

Step 6: Confirm to the Employee
Add a Message node after the flow call: “Your ticket has been logged. Your ticket ID is {Topic.TicketID}. IT will contact you within 4 hours.”

How does this work?
When the agent reaches the Call a tool node, it passes the captured variables to the Power Automate flow as input parameters. The flow runs, creates the SharePoint item, and returns the ticket ID to the agent — all within the live conversation.

Pro Tip: Power Automate flows connected to Copilot Studio run under the connection credentials of the flow author, not the end user. Make sure the person who builds the flow has the correct permissions on SharePoint. If you need user-specific access, use the authentication node with Azure AD sign-in before calling the flow.

Check out How to Choose an AI Model in Copilot Studio: GPT-5, Claude, and More

Method 4 – Use Adaptive Cards for Rich Interactive Responses

Use this method when a plain text reply isn’t enough — you need to show a formatted card with buttons, images, drop-downs, or input fields. For example, displaying an employee’s leave summary with action buttons (“Apply Leave” / “View History”) directly inside Teams.

Step 1: Open the Adaptive Card Node
In your Leave Balance topic, after collecting the employee ID, select + → Adaptive Card. This node renders a structured visual card in the chat interface.

Step 2: Build the Card in the Designer
Copilot Studio has a built-in Adaptive Card designer. Select Edit JSON and paste this example card:

{
  "type": "AdaptiveCard",
  "version": "1.5",
  "body": [
    {
      "type": "TextBlock",
      "text": "Leave Balance Summary",
      "weight": "Bolder",
      "size": "Medium"
    },
    {
      "type": "FactSet",
      "facts": [
        { "title": "Annual Leave", "value": "12 days remaining" },
        { "title": "Sick Leave", "value": "5 days remaining" },
        { "title": "Employee ID", "value": "${EmployeeID}" }
      ]
    }
  ],
  "actions": [
    {
      "type": "Action.Submit",
      "title": "Apply for Leave",
      "data": { "action": "applyLeave" }
    },
    {
      "type": "Action.Submit",
      "title": "View Leave History",
      "data": { "action": "viewHistory" }
    }
  ]
}

Replace ${EmployeeID} with your variable reference using Copilot Studio’s Power Fx expression: =Topic.EmployeeID.

Step 3: Handle Card Responses
After the Adaptive Card node, add a Condition node. Check the value of the card’s output variable (automatically captured when a user clicks a button). Branch the conversation:

• If action = applyLeave → redirect to your Apply Leave topic
• If action = viewHistory → show a message with a SharePoint link

How does this work?
Adaptive Cards are JSON-defined visual templates rendered natively by the Teams or web client. The user’s button click returns a data payload back to the agent, which the Condition node reads to route the conversation.

Pro Tip: Adaptive Cards render beautifully in Microsoft Teams but may appear differently (or not at all) in simpler channels like direct-line web chat. Always test your agent in the actual channel you plan to deploy it to. Check the Channels page in Copilot Studio for channel-specific preview tools.

Read How to Monitor Token Usage by AI Model in Copilot Studio

Method 5 – Extend the Agent with a Custom Connector

Use this method when you need the agent to call an external system that doesn’t have a built-in Power Automate connector — for example, a third-party HRMS system, a payroll API, or a custom internal API. This is the most advanced method but still achievable without deep coding.

Step 1: Create a Custom Connector in Power Automate
Go to make.powerautomate.com → Custom connectors → New custom connector → Create from blank. Name it Contoso HRMS Connector.

Under General, enter the base URL of your HRMS API, e.g., https://api.contoso-hrms.com/v1.

Under Security, configure authentication — most APIs use either API key or OAuth 2.0. For this example, use API key. Set the parameter name to x-api-key and location to Header.

Under Definition, add an action called GetLeaveBalance:

• HTTP verb: GET
• Path: /employees/{employeeId}/leave-balance
• Response schema (paste your API’s JSON schema):

{
  "type": "object",
  "properties": {
    "annualLeave": { "type": "integer" },
    "sickLeave": { "type": "integer" },
    "employeeId": { "type": "string" }
  }
}

Select Create connector.

Step 2: Use the Custom Connector in a Power Automate Flow
Create a new flow with a Run a flow from Copilot trigger. Add an input: EmployeeID (Text). Add the GetLeaveBalance action from your custom connector. Pass EmployeeID as the employeeId parameter. Return annualLeave and sickLeave as output variables via the Respond to Copilot action.

Step 3: Call the Flow from a Copilot Studio Topic
Back in your Leave Balance topic in Copilot Studio, after the employee ID question, add a Call a tool node → select the flow you just built. Map EmployeeID → Topic.EmployeeID. Store outputs in Topic.AnnualLeave and Topic.SickLeave.

Step 4: Display the Live Data
Add a Message node: “Hi! You have {Topic.AnnualLeave} annual leave days and {Topic.SickLeave} sick leave days remaining.”

How does this work?
The custom connector acts as an authenticated bridge between your Power Automate flow and your external HRMS API. The agent calls the flow mid-conversation, the flow hits the API, and the live data comes back into the chat in real time — all transparent to the employee.

Pro Tip: Custom connectors require a premium Power Automate license (Power Automate Premium or a per-flow plan). If your organization only has standard Microsoft 365 licenses, you won’t have access to custom connectors. Check with your admin before designing a solution that relies on this method.

Things to Keep in Mind

• Licensing has two layers: To build agents, you need both a Copilot Studio tenant license and a Copilot Studio User License assigned to each maker. End users who chat with your agent do NOT need a special license.
• Teams-only plan has serious limitations: The Teams plan (available in select Microsoft 365 subscriptions) only supports classic orchestration and can only publish agents to Teams. You cannot use generative AI features or deploy to other channels without upgrading to the standalone plan.
• Trigger phrase conflicts break conversations: In classic mode, if two topics share very similar trigger phrases (e.g., “leave request” and “leave balance”), the agent may consistently pick the wrong topic. Keep trigger phrases distinct and test with varied phrasings before publishing.
• Power Automate connections authenticate as the flow author: Flows called from Copilot Studio run under the credentials of whoever built the flow — not the logged-in user. If your flow accesses sensitive SharePoint data, ensure the author account has the right permissions and is a service account, not a personal account.
• Environment selection matters: Always build and publish in the correct Power Platform environment. Agents built in the default environment are visible to everyone in your tenant. Use a dedicated environment for production agents to control access and governance.
• Session timeouts are short: By default, a Copilot Studio conversation session times out after 30 minutes of inactivity. Variables are cleared on timeout. If your agent workflow takes a long time (e.g., waiting for an approval), design the flow so it doesn’t depend on the same session to continue.

You now have a complete picture of what Microsoft Copilot Studio is and five practical ways to use it — from manually authored topics and generative AI knowledge responses, to Power Automate integrations, Adaptive Cards, and custom API connectors.

Start with Method 1 or Method 2 if you’re new to the platform; move to Methods 3–5 as your agent grows in complexity, and your use cases demand real-time data and richer interactions. I hope you found this article helpful.

The numbers look good. But the date line says “2026-06-24T14:32:10Z” instead of a nice, human format like “24th Jun 2026, 02:32 PM”. Your manager skims the email, gets confused, and writes back: “What time zone is this? And why does it look so technical?”

If this sounds familiar, you’re not alone. Flows love technical date formats. People don’t. You need a clean, readable date with the correct st / nd / rd / th suffix like 1st, 2nd, 3rd, 4th in your Power Automate emails, Teams messages, and approvals.

In this tutorial, I’ll show you 2 ways to format dates with st / nd / rd / th in Power Automate: using a single expression inside your action, and using a Compose-first approach to keep things clean.

Format Dates with Ordinal Suffixes (st, nd, rd, th) in Power Automate

Let’s pick a simple, relatable example: daily sales report emails.

You want the email subject line to look like this:

Daily Sales Report – 24th Jun 2026, 02:32 PM

Behind the scenes, your flow has the raw UTC date-time from utcNow():

2026-06-24T14:32:10Z

Your goal is to turn that raw value into a friendly string with:

• The day: 24
• The suffix: th
• A space
• The month and year: Jun 2026
• A comma and the time: 02:32 PM

All of this is done with one Power Automate expression using functions like concat(), formatDateTime(), int(), mod(), greaterOrEquals(), and lessOrEquals().

The final expression does exactly that:

concat(
    formatDateTime(utcNow(), 'dd'),
    if(
        or(
            and(
                greaterOrEquals(int(formatDateTime(utcNow(), 'dd')), 11),
                lessOrEquals(int(formatDateTime(utcNow(), 'dd')), 13)
            ),
            equals(mod(int(formatDateTime(utcNow(), 'dd')), 10), 0)
        ),
        'th',
        if(
            equals(mod(int(formatDateTime(utcNow(), 'dd')), 10), 1),
            'st',
            if(
                equals(mod(int(formatDateTime(utcNow(), 'dd')), 10), 2),
                'nd',
                if(
                    equals(mod(int(formatDateTime(utcNow(), 'dd')), 10), 3),
                    'rd',
                    'th'
                )
            )
        )
    ),
    ' ',
    formatDateTime(utcNow(), 'MMM yyyy, hh:mm tt')
)

Let’s unpack this step by step in plain English.

Step 1 – Understand the Key Date Functions

Before touching the big expression, you need to understand the building blocks.

In Power Automate, two core date functions do the heavy lifting:

• utcNow() – Returns the current date and time in UTC

Example output:

2026-06-24T14:32:10Z

• formatDateTime(timestamp, formatString) – Converts a date-time into a formatted text string

Example:

formatDateTime(utcNow(), 'dd')

Output:

24

Example:

formatDateTime(utcNow(), 'MMM yyyy, hh:mm tt')

Output:

Jun 2026, 02:32 PM

In your daily sales email, use utcNow() to get “now” and formatDateTime() to show it in a friendly format.

Step 2 – Build the Base Date String

First, ignore the st / nd / rd / th suffix.

Just build a simple date-time string that looks like:

24 Jun 2026, 02:32 PM

You can do this in any text field inside your flow (for example, Subject in Send an email (V2)):

formatDateTime(utcNow(), 'dd MMM yyyy, hh:mm tt')

Here’s what each part of the format string means:

• dd – Day as two digits → 24
• MMM – Month as short text → Jun
• yyyy – Year as four digits → 2026
• hh:mm – Hour and minute in 12-hour format → 02:32
• tt – AM/PM marker → PM

This is the base Power Automate date format you’ll build on.

Step 3 – Learn the Ordinal Suffix Rules

Now, you want to convert 24 to 24th, 21 to 21st, and so on.

These are called ordinal suffixes.

The rules are:

• Numbers ending in 1 → st (1st, 21st, 31st)
• Numbers ending in 2 → nd (2nd, 22nd)
• Numbers ending in 3 → rd (3rd, 23rd)
• All other numbers → th (4th, 5th, 6th, etc.)
• Special case: 11, 12, and 13 always use th

You’ll encode these rules in Power Automate using if(), and(), or(), mod(), and comparison functions.

Step 4 – Extract the Day Number

To decide which suffix to use, first get the day of the month as a number.

The expression does this with:

formatDateTime(utcNow(), 'dd')

This gives you a text value, such as "24".

To use math functions like mod(), convert that text to a number with int():

int(formatDateTime(utcNow(), 'dd'))

Now you have the day as an integer, such as 24.

This is what you’ll feed into your suffix logic.

Step 5 – Handle the Special “11–13” Case

Remember the rule: 11, 12, and 13 always get th.

The expression checks this first:

and(
    greaterOrEquals(int(formatDateTime(utcNow(), 'dd')), 11),
    lessOrEquals(int(formatDateTime(utcNow(), 'dd')), 13)
)

Breakdown:

• greaterOrEquals(value, 11) – Is the day >= 11?
• lessOrEquals(value, 13) – Is the day <= 13?
• and(condition1, condition2) – Are both true at the same time?

If both are true, the day is 11, 12, or 13.

So the suffix must be th.

Step 6 – Use mod() to Get the Last Digit

If the day is not 11, 12, or 13, you look at the last digit.

The expression uses mod() to get that last digit:

mod(int(formatDateTime(utcNow(), 'dd')), 10)

The mod() function returns the remainder when you divide a number by another number.

For day numbers:

mod(21, 10) → 1
mod(22, 10) → 2
mod(23, 10) → 3
mod(24, 10) → 4

That remainder is your last digit of the day.

You can now choose st, nd, rd, or th based on this digit.

Step 7 – Build the Suffix Selection Using if()

Next, you build a nested if() to choose the suffix.

Here is the core logic from the expression:

if(
    or(
        and(
            greaterOrEquals(int(formatDateTime(utcNow(), 'dd')), 11),
            lessOrEquals(int(formatDateTime(utcNow(), 'dd')), 13)
        ),
        equals(mod(int(formatDateTime(utcNow(), 'dd')), 10), 0)
    ),
    'th',
    if(
        equals(mod(int(formatDateTime(utcNow(), 'dd')), 10), 1),
        'st',
        if(
            equals(mod(int(formatDateTime(utcNow(), 'dd')), 10), 2),
            'nd',
            if(
                equals(mod(int(formatDateTime(utcNow(), 'dd')), 10), 3),
                'rd',
                'th'
            )
        )
    )
)

Let’s rewrite this in simple rules:

• If the day is 11–13, or the last digit is 0 → use th
• Else if the last digit is 1 → use st
• Else if the last digit is 2 → use nd
• Else if the last digit is 3 → use rd
• Otherwise → use th

The outer if() handles the 11–13 special case and also days ending with 0 (10, 20, 30).

The nested if() handles the last digit check for 1, 2, and 3, and defaults to th for the rest.

Step 8 – Concatenate Day + Suffix + Formatted Date

Finally, you put everything together using concat().

Here’s the full Power Automate expression again:

concat(
    formatDateTime(utcNow(), 'dd'),
    if(
        or(
            and(
                greaterOrEquals(int(formatDateTime(utcNow(), 'dd')), 11),
                lessOrEquals(int(formatDateTime(utcNow(), 'dd')), 13)
            ),
            equals(mod(int(formatDateTime(utcNow(), 'dd')), 10), 0)
        ),
        'th',
        if(
            equals(mod(int(formatDateTime(utcNow(), 'dd')), 10), 1),
            'st',
            if(
                equals(mod(int(formatDateTime(utcNow(), 'dd')), 10), 2),
                'nd',
                if(
                    equals(mod(int(formatDateTime(utcNow(), 'dd')), 10), 3),
                    'rd',
                    'th'
                )
            )
        )
    ),
    ' ',
    formatDateTime(utcNow(), 'MMM yyyy, hh:mm tt')
)

Breakdown in plain English:

• formatDateTime(utcNow(), 'dd') → "24"
• The big if() → "th" (for day 24)
• ' ' → a space
• formatDateTime(utcNow(), 'MMM yyyy, hh:mm tt') → "Jun 2026, 02:32 PM"

concat() joins all of these pieces into one final string:

24th Jun 2026, 02:32 PM

You can paste this expression directly into:

• Email subject
• Email body
• Teams message text
• Approval title
• Any other text field in your flow

Your daily sales report now reads:

Daily Sales Report – 24th Jun 2026, 02:32 PM

Method 1 – Use the Expression Directly in Your Action

This is the fast, direct way.

Here, I have created an instant cloud flow in Power Automate to test this.

1. Open your Send an email (V2) action.
2. In the Subject field, click on the formula or expression icon and then enter the code below.

concat(
    'Daily Sales Report – ',
    formatDateTime(utcNow(), 'dd'),
    if(
        or(
            and(
                greaterOrEquals(int(formatDateTime(utcNow(), 'dd')), 11),
                lessOrEquals(int(formatDateTime(utcNow(), 'dd')), 13)
            ),
            equals(mod(int(formatDateTime(utcNow(), 'dd')), 10), 0)
        ),
        'th',
        if(
            equals(mod(int(formatDateTime(utcNow(), 'dd')), 10), 1),
            'st',
            if(
                equals(mod(int(formatDateTime(utcNow(), 'dd')), 10), 2),
                'nd',
                if(
                    equals(mod(int(formatDateTime(utcNow(), 'dd')), 10), 3),
                    'rd',
                    'th'
                )
            )
        )
    ),
    ' ',
    formatDateTime(utcNow(), 'MMM yyyy, hh:mm tt')
)

3. Save and run the flow.

Your subject will show a clean Power Automate date format with ordinal suffix, perfect for sales reports.

After testing the flow, I can confirm I received the exact output in the email subject line. Here is a screenshot for your reference.

Method 2 – Use Compose to Simplify and Reuse

When you start using this date format in multiple actions, the long expression can become hard to maintain.

A cleaner approach is to use Compose actions to break the logic into smaller parts.

Here’s how.

Add a Compose – DayNumber action

Expression:

int(formatDateTime(utcNow(), 'dd'))

Add a Compose – DaySuffix action

Expression:

if(
    or(
        and(
            greaterOrEquals(outputs('Compose_-_DayNumber'), 11),
            lessOrEquals(outputs('Compose_-_DayNumber'), 13)
        ),
        equals(mod(outputs('Compose_-_DayNumber'), 10), 0)
    ),
    'th',
    if(
        equals(mod(outputs('Compose_-_DayNumber'), 10), 1),
        'st',
        if(
            equals(mod(outputs('Compose_-_DayNumber'), 10), 2),
            'nd',
            if(
                equals(mod(outputs('Compose_-_DayNumber'), 10), 3),
                'rd',
                'th'
            )
        )
    )
)

Add a Compose – FormattedDateTime action

Expression:

formatDateTime(utcNow(), 'MMM yyyy, hh:mm tt')

In your email Subject field, use:

concat(
    'Daily Sales Report – ',
    formatDateTime(utcNow(), 'dd'),
    outputs('Compose_-_DaySuffix'),
    ' ',
    outputs('Compose_-_FormattedDateTime')
)

This approach makes your Power Apps formula-style expression inside Power Automate more readable and easier to debug, especially in larger flows.

When to Use This Pattern

You’ll use this Power Automate date formatting pattern whenever:

• You send daily, weekly, or monthly reports.
• You generate sales summaries, scorecards, or temperature logs as emails.
• You build approval requests that show “Created on 3rd Jun 2026”.
• You log events, like “Order shipped on 21st Jan 2026, 11:15 AM”.

For example, with a daily sales amount of USD 1250, your email body might say:

Total sales for 24th Jun 2026, 02:32 PM: USD 1250.

The date formatting expression keeps that line readable and professional.

Conclusion

You learned how to take a raw UTC date-time, format it into a friendly string, and add the correct st / nd / rd / th suffix using Power Automate expressions.

Use Method 1 (single expression) when you just need the formatted date in one place, and Method 2 (Compose-based) when you want cleaner, reusable logic across multiple actions in a bigger flow.

I hope you found this article helpful.

Microsoft has solid guidance now. In this tutorial, I’ll walk you through everything you need to know to build a proper environment strategy for Copilot Studio — the Dev, Test, and Prod setup that keeps production stable while letting you innovate safely.

I’m going to explain this as I would for a colleague who’s just picked up Copilot Studio and wants to do things right from the start. Just practical, actionable guidance that you can apply today while working with Copilot Studio.

Why Environment Strategy Matters (And Why You Should Care)

Copilot Studio makes it incredibly fast to go from idea to working agent. You can build something impressive in an hour. That speed is amazing — but it also means agents can reach production maturity quickly, and without proper lifecycle practices, you end up with:

• Agents that break when moved because hardcoded URLs or connection references don’t work in the new environment
• No way to track what changed or who deployed something
• Production instability because someone made a direct change in the live environment
• Emergency fixes that block ongoing work because you’re trying to fix production while feature development is happening in the same space

The solution is environment isolation. You create separate spaces for different stages of your agent’s lifecycle, and changes flow in one direction only: Dev → Test → Prod.

This isn’t some fancy enterprise requirement. It’s basic best practice that emerges naturally once your agent serves real users and downtime has a cost.

The Three-Environment Model: Dev, Test, Prod

Let’s start with the foundation. The most tried-and-tested pattern in Power Platform is three environments:

Here’s what makes this work:

Dev is where you build. This is your active authoring space. You create topics, configure tools, add knowledge sources, and test conversations. Everything lives in an unmanaged solution — you can add, edit, or remove components freely.

Test is where you validate. Before anything touches production, it goes here. You run automated evaluations, do user acceptance testing (UAT), and confirm the agent works correctly with test-specific configuration (like test SharePoint libraries or test API endpoints). This uses a managed solution — it’s read-only, sealed. Nobody can edit it directly.

Prod is where users interact. This is your live environment. The agent here serves real users with real data. It also uses a managed solution, and changes only happen through the deployment pipeline — never by editing directly.

Changes flow in one direction: Dev → Test → Prod. This keeps production stable and predictable.

How to Create These Environments in Power Platform

You create environments in the Power Platform Admin Center (aka.admin.microsoft.com). The process is like below:

Open the Power Platform Admin Center

• Navigate to the Power Platform Admin Center (https://admin.powerplatform.microsoft.com) and then sign in using your Microsoft 365 or Power Platform administrator account.
• In the left navigation pane, click Manage, then Select Environments. This page displays all environments available in your tenant, including:
  • Production
  • Sandbox
  • Developer
  • Trial
  • Default Environment
• At the top of the Environments page, click the + New button.

Here is a screenshot for your reference.

• This launches the environment creation wizard.

Here, fill in the details to create an environment.

• Type: Developer
  • Creates a personal development environment for building and testing Power Platform solutions.
  • Not intended for production use.
• Region: United States
  • Determines the geographic location where the environment and data are stored.
  • Helps meet performance and compliance requirements.
• Name: dev-na-d66014c5
  • Unique identifier for the environment.
  • Used to distinguish it from other environments in the tenant.
• Owner
  • The user who creates and manages the environment.
  • Has full administrative access.
• Environment Group: None
  • The environment is not assigned to any environment group.
  • Environment groups help organize and manage multiple environments.
• Managed: No
  • The environment is not a Managed Environment.
  • Standard governance and monitoring features apply.
• Get New Features Early: No
  • Early access features are disabled.
  • The environment will receive new features during standard Microsoft releases.

You can also look at the settings below.

• Environment Group
  • Assigns the environment to a specific environment group for centralized administration.
• Make this a Managed Environment
  • Enables advanced governance, security, monitoring, and usage insights.
  • Recommended for enterprise and production scenarios.
• Get New Features Early
  • Provides access to preview and upcoming Power Platform features before general availability.
  • Useful for testing and learning new capabilities.
• Create on Behalf
  • Allows administrators to create a Developer environment for another user.
  • Commonly used in organizations to provision environments for makers and developers.
• Pay-as-you-go with Azure
  • Links the environment to an Azure subscription for usage-based billing.
  • Available only for Production and Sandbox environments, not Developer environments.

Here is a screenshot for your reference.

Do this for all three environments. Give them clear names so everyone knows which one is which.

When You Might Need More Environments

The Dev-Test-Prod foundation is solid for most teams. But as your agent matures and becomes more business-critical, you might want to add two optional environments:

Preview Environment: Catch Platform Regressions Early

Power Platform and Copilot Studio update continuously. Sometimes an update introduces a regression that breaks your agent. A Preview environment on the First Release ring gives you an early warning.

Here’s how it works:

• First Release gets platform updates weeks before the standard ring
• You deploy your current production solution into Preview
• You run evaluations on a schedule
• When evals start failing in Preview but still pass in Production, you have an early warning: something in the upcoming update might need attention
• You get weeks to investigate and adapt instead of reacting when production breaks

This is one of the most valuable yet underutilized practices in Power Platform ALM. A Preview environment with scheduled evals turns platform updates from a reactive concern into a proactive one.

Production-Aligned Dev Environment: Handle Emergencies Without Shipping Unfinished Work

Imagine this: your primary Dev environment has work in progress. A critical bug surfaces in Production. You can’t wait for the current development cycle to complete, and you can’t ship half-finished features alongside a hotfix.

The solution is a production-aligned development environment — a secondary Dev environment that holds an unmanaged copy of whatever is currently running in Prod. When an emergency arises:

• You make the fix there
• Export it as a managed solution
• Promote it directly through the pipeline (Prod-Aligned Dev → Test → Prod)
• Your primary Dev environment and its in-progress work remain untouched

Normal cycle: Dev → Test → Prod
Hotfix cycle: Prod-Aligned Dev → Test → Prod

This isn’t overhead for day one. Add it when the agent is mature enough that production downtime has a real cost. But plan for it from the start — retrofitting emergency processes during an actual emergency is how mistakes happen.

The Full Environment Picture

Start with Dev, Test, and Prod. Add Preview and Prod-Aligned Dev as the agent matures.

Solutions: The Unit of Deployment

If environments are where your agent lives, solutions are how it travels between them. A solution is a container — a package that holds every component your agent depends on and makes the entire set portable and promotable as a single unit.

What Goes Inside a Copilot Studio Solution

Everything your agent depends on must live inside a single solution:

• The agent itself
• Its tools (APIs, connectors, external integrations, workflows)
• Its environment variables (configuration that differs per environment)
• Its knowledge source references
• And everything else it needs to function

Anything created outside a solution is invisible to your deployment pipeline and cannot be promoted cleanly. This is the single most common mistake teams make early on — building components in the default environment without a solution, only to discover they cannot move them.

The fix is simple: create your solution first, then create everything else inside it.

How to Set Up Your Solution

1. Go to your Dev environment in Power Platform
2. Click Solutions → New solution
3. Name it (e.g., “Contoso-Copilot-Agent”)
4. Set the Publisher (use your organization’s publisher)
5. Click Create
6. Set it as your preferred solution — this ensures new components are automatically added to it rather than floating in the default solution

From that point on, every component must be created inside this solution. When you create a new topic, tool, or environment variable, make sure you’re creating it within the solution context.

Managed vs. Unmanaged Solution: The Critical Difference

Solutions exist in two forms:

When you export a solution from Dev, you choose to export it as managed or unmanaged. The best practice when promoting your agent is to export as managed. This managed package is what gets imported into Test and later into Production.

It’s sealed — nobody can edit it in place without going back to the dev environment. If a change is needed, it must be made in Dev, re-exported, and re-promoted. This one-way flow is what keeps Production stable.

Check out How Generative AI Works Inside Copilot Studio

Deploying With Confidence: Power Platform Pipelines

With your environments established and your solution containing all agent assets, how does the solution actually move from Dev to Test to Prod?

You could do this manually — export a .zip from Dev, navigate to Test, import it, repeat for Prod. This works, but it’s error-prone, undocumented, and doesn’t scale. It also leaves no trace of what was deployed, when, or by whom.

Power Platform Pipelines solve this. A pipeline is a pre-configured promotion path that connects your environments in sequence. Once set up, promoting your solution is a single action: select the solution, select the stage (Dev to Test, or Test to Prod), and deploy. The pipeline handles the managed export, the import into the target, and records the deployment in its history.

What a Pipeline Gives You

• Repeatability — the same process every time, no manual steps to forget
• Audit trail — who deployed what, when, and to which environment
• Rollback visibility — deployment history shows exactly which version is in each environment
• Guardrails — you can require approvals before a deployment proceeds to the next stage

What a Pipeline Does Not Do

• It does not validate that your agent works correctly after import — that’s what evaluations are for
• It does not set environment-specific configuration values — those must be in place before the solution arrives
• It does not manage secrets — those live in Azure Key Vault, referenced through environment variables

How to Set Up a Pipeline

1. Go to Power Platform Admin Center
2. Click Pipelines → New pipeline
3. Name it (e.g., “Copilot-Agent-Pipeline”)
4. Add your source environment (Dev)
5. Add your target environments (Test, then Prod)
6. Configure deployment stages with pre-deployment and post-deployment steps if needed
7. Click Save

Once configured, deploying is simple:

1. Go to your solution in Dev
2. Click Export to pipeline
3. Select the target stage (Test or Prod)
4. Click Deploy

The pipeline handles everything automatically.

Read Monitor Token Usage by AI Model in Copilot Studio

Configuration Without Hardcoding: Environment Variables

The principle is simple: nothing environment-specific gets hardcoded. API endpoints, SharePoint URLs, thresholds, feature flags — all go into environment variables.

Environment variables have two layers that are important to understand:

• Definition — the schema (name, data type, description). This travels with the solution.
• Value — the actual content. This is set per environment and does not travel with the solution.

This separation is what makes portability possible. When you import your managed solution into Test, it brings the variable definitions but not the values.

The Test environment already has its own values configured. The same workflow runs unchanged across Dev, Test, and Prod because it reads its configuration from whichever environment it happens to be running in.

Supported Environment Variable Types

How to Create an Environment Variable

1. In your Dev environment, open your solution
2. Click Add existing → More → Environment variable
3. Click New
4. Fill in:
   • Name (e.g., “API Endpoint”)
   • Schema name (e.g., “contoso_ApiEndpoint”) — this is what you’ll reference in your agent
   • Type (String, Number, Boolean, etc.)
   • Description (helpful for team members)
5. Do not set a current value if it will differ across environments
6. Click Save

Now reference this variable in your agent by using the schema name: contoso_ApiEndpoint

The Critical Mistake to Avoid

Do not set a current value on an environment variable inside the solution definition if that value will differ across environments. Values baked into the solution definition will override environment-specific values and silently break your portability.

Set values directly in each target environment after import.

Check out How to Choose an AI Model in Copilot Studio

Preparing Variables Before Deployment

When your pipeline promotes a solution to a new environment, the variable definitions arrive but the values do not. This means environment variable values must be configured in the target environment before the solution is imported — otherwise workflows that depend on those variables will fail at runtime.

Include this as an explicit step in your promotion process: verify that every expected variable has a value in the target before deploying.

How Values Are Supplied

There are two models depending on how you deploy:

With Power Platform Pipelines (in-product): When a solution containing environment variables is deployed, the pipeline prompts you to provide or confirm values for the target environment — just as a manual import would. If values already exist in the target, they are pre-filled. If they do not, you supply them at deployment time.

With CI/CD pipelines (Azure DevOps or GitHub Actions): You use a deployment settings file — a JSON file that maps each variable’s schema name to its target-specific value:

{
  "EnvironmentVariables": [
    {
      "SchemaName": "contoso_ApiEndpoint",
      "Value": "https://api-test.contoso.com"
    },
    {
      "SchemaName": "contoso_MaxRetries",
      "Value": "3"
    }
  ]
}

This file is passed as a parameter to the solution import task, pre-populating values during import without manual intervention.

In both models, the principle is the same: the solution carries the variable definitions, and the target environment (or its settings file) supplies the values. The pipeline never embeds environment-specific configuration into the solution artifact itself.

Secrets: Azure Key Vault Integration

For secrets — API keys, tokens, credentials — secret environment variables backed by Azure Key Vault provide a secure, auditable approach. The agent references a Key Vault secret rather than holding the value directly, and the platform resolves it at runtime. When a key rotates, you update Key Vault — no solution change or redeployment needed.

How to Set Up Key Vault Secrets

1. Create Azure Key Vaults per environment tier:
   • kv-agent-dev
   • kv-agent-test
   • kv-agent-prod
2. Store secrets with identical names across them (e.g., “ApiKey”, “AuthToken”)
3. In each environment, create a secret environment variable:
   • Type: Secret
   • Value: Reference to the Key Vault secret (e.g., @{appKeyVault}@contoso_ApiKey)
4. Structure your vaults so only the vault reference in each environment’s variable value differs. The workflow logic is identical everywhere — it asks for a secret by name, and the environment resolves it to the correct vault.

This approach means:

• Secrets never touch your solution
• Key rotation happens without redeployment
• You have audit trails for secret access
• Each environment uses its own isolated secrets

Knowing It Works: Evaluations and Testing

Deploying correctly does not guarantee behaving correctly. Evaluations close that gap.

An evaluation is a defined set of test inputs and expected outputs that measures whether your agent is selecting the right tools, triggering the right logic, and producing acceptable responses. It serves as your quality gate — giving confidence that a promotion is safe.

Agent Evaluation in Copilot Studio (Built-In Automated Testing)

Microsoft recently introduced Agent Evaluation — automated testing built directly into Copilot Studio. This lets you validate your agent’s responses against predefined expectations using multiple evaluation methods.

With Agent Evaluation, you can:

• Create reusable test sets (up to 100 test cases per set)
• Define success criteria per question
• Run tests under specific user identities
• Analyze pass/fail results and quality scores

How to Create a Test Set

Step 1: Open Your Agent in Copilot Studio

• Go to Microsoft Copilot Studio
• Open the agent you want to test
• Navigate to the Evaluation tab

Step 2: Create a Test Set

A test set is a collection of questions your agent should handle correctly. You can create test cases in multiple ways:

• AI-generated questions based on the agent description and knowledge
• Manual entry of questions and expected responses
• Reuse questions from test chat history
• Import a CSV file with up to 100 test cases

Each test case can include:

• Question
• Expected response (where required)
• Evaluation method
• Threshold for success

Step 3: Configure User Context

You can run evaluations under a specific user profile:

• Ensures the agent accesses the same data and connectors as real users
• Helps identify permission-related issues early

This is especially important for agents using secured SharePoint, Dataverse, or external connectors.

Evaluation Methods You Can Choose

Makers can choose from a wide range of test methods:

• Exact or partial matches — for strict checklist compliance
• Advanced similarity metrics — for semantic alignment
• Intent recognition — for understanding whether the right logic triggered
• Relevance and completeness — for overall helpfulness

You can also set custom thresholds to ensure your agent meets your organization’s unique standards for accuracy and relevance.

Where Evaluations Fit in Your ALM Process

Evaluations are not a standalone activity. They integrate directly into the promotion lifecycle:

• After changes in Dev — did anything regress? Run evals before exporting.
• Before promotion to Test — evals passing is the signal that a solution is ready to move forward.
• On a schedule in Preview — will the next platform update break us? Automated scheduled evals answer this continuously.
• After import in the target — did the deployment land cleanly? A post-deployment smoke eval confirms the agent is functional in its new environment.

Automating Evaluations in Your Pipeline

Evaluations can be triggered programmatically, which means they can become an automated gate in your promotion pipeline. Rather than relying on a human to remember to run them, you configure the pipeline to execute evaluations after each deployment and block further promotion if results fall below a threshold.

This transforms evaluations from a manual best practice into an enforced quality gate — no deployment reaches Production unless the agent demonstrably works.

The Copilot Studio Kit for Automated Testing

For more advanced automated testing, you can use the Power CAT Copilot Studio Kit. This integrates Power Automate cloud flows with Dataverse and the Copilot Studio Kit to validate agent functionality with security and data integrity tests.

The deployment process with the Kit requires three environments:

• Pipeline host environment: Hosts the pipelines and their extensions. It’s the central control point.
• Development (source) environment: Where you develop and test the agent. Kit is installed here.
• Target (production) environment: The final destination where the agent is published after passing validation.

High-level steps:

1. Open the Deployment Pipeline Configuration app
2. Configure the pipeline with name and linked development environments
3. Add deployment stages to define target environments
4. Enable pre-export and pre-deployment steps
5. Trigger on deployment request — the flow pauses, runs automated tests, evaluates results, and decides whether to proceed

Security and Governance: Environment-Level Controls

Your environment strategy isn’t just about deployment — it’s also about security. Each environment should have appropriate controls based on its purpose.

Environment-Level Settings to Configure

For Production:

• Lockbox — prevent unmanaged customizations
• Dataverse audit — enable logging for compliance
• IP firewall — restrict access to known IPs
• IP cookie binding — add another layer of authentication
• Environment auditing — enable for compliance tracking

For All Environments:

• Microsoft Entra Conditional Access — apply for corporate devices and networks
• MFA — enable multifactor authentication for all users
• RBAC — use Power Platform role-based access control to assign appropriate roles (admin, maker, end-user)
• Restricted user access — limit authoring access to specific security groups

Data Policies

Establish environment-level or tenant-level data policy rules for your agent to restrict unused connectors based on the agent’s use case:

• Restrict non-business connectors in production
• Allow broader connector access in Dev for testing
• Define which first-party (1P) and third-party (3P) connectors are permitted

Authentication Models

Establish the permitted authentication model for your Copilot agent:

• Authentication via Microsoft Entra ID (recommended for production)
• Manual authentication (for specific scenarios)
• No authentication required (only for public-facing agents with appropriate safeguards)

Additionally, decide on restricting or permitting web channel access to ensure an appropriate security level.

Least Privilege Principle

Restrict agent permissions to essential data sources only:

• In production, use a service principal account for deployment and custom connector authentication
• Don’t give agents broader access than they need
• Review and approve integrated app registrations, VNets, keys, and endpoints in Azure for production resources

Before You Promote: A Checklist

Before deploying your agent to Test or Prod, make sure you’ve covered these items:

• ✓ All agent assets live inside the solution
• ✓ Solution set as preferred solution in Dev
• ✓ No hardcoded environment-specific values anywhere
• ✓ Environment variable values configured in the target environment
• ✓ Secrets are in Key Vault, referenced via secret environment variables
• ✓ Pipeline configured with correct stage sequence
• ✓ Solution exported as managed for Test and Prod
• ✓ Evaluations pass before and after deployment
• ✓ Smoke test passes in the target after import
• ✓ Production knowledge sources (SharePoint libraries, documents) are properly referenced
• ✓ Data policies and RBAC are correctly configured in production

Common Pitfalls (And How to Avoid Them)

Pitfall 1: Creating Components Outside a Solution

Problem: You build topics, tools, and variables in the default environment without a solution. Later, you can’t export or promote them.

Fix: Create your solution first. Set it as preferred. Create everything inside it.

Pitfall 2: Hardcoding Environment-Specific Values

Problem: You hardcode “https://api-contoso.com” directly in your agent. It works in Dev but breaks in Prod because Prod uses a different endpoint.

Fix: Use environment variables. Reference contoso_ApiEndpoint instead of the actual URL. Set the value per environment.

Pitfall 3: Setting Current Values in Solution Definition

Problem: You set a current value on an environment variable in your solution definition. When you import to Test, it overrides Test’s value and breaks your agent.

Fix: Don’t set current values in the solution definition. Set values directly in each target environment after import.

Pitfall 4: Editing Directly in Production

Problem: Someone makes a quick fix directly in Production because “it’s just a small change.” Now production is unaligned with your solution, and you have no audit trail.

Fix: Never edit directly in Production. All changes go through Dev → Test → Prod via the pipeline. If it’s urgent, use the Prod-Aligned Dev environment for hotfixes.

Pitfall 5: Skipping Evaluations

Problem: You deploy without running evaluations. The agent breaks in production because a tool changed or a knowledge source is missing.

Fix: Run evaluations before every deployment. Make evals passing a requirement for promotion. Set up automated evals in your pipeline.

Pitfall 6: Using the Default Environment for Development

Problem: You build your agent in the Default environment. Later, you can’t isolate it, secure it properly, or promote it cleanly.

Fix: Create a dedicated Dev environment from the start. Close down the Default environment to the bare minimum to avoid ongoing security headaches.

Real-World Example: Deploying an HR Copilot

Let’s walk through a concrete example. You’re building an HR Copilot that answers employee questions about policies, benefits, and leave procedures.

Environment Setup

• Dev: “HR-Copilot-Dev” — where you build the agent
• Test: “HR-Copilot-Test” — where HR team validates
• Prod: “HR-Copilot-Prod” — where employees access it

Solution Structure

Create solution “HR-Copilot-Agent” in Dev. Inside it:

• Agent: “HR Policy Copilot”
• Tools: SharePoint connector (for policy documents), Dataverse table (for leave requests)
• Environment variables:
  • hrcontoso_SharePointUrl (String) — SharePoint site URL
  • hrcontoso_LeaveTableId (Data source) — Dataverse table reference
  • hrcontoso_ApiKey (Secret) — Key Vault reference for external HR API

Environment Variable Values

In Dev:

• hrcontoso_SharePointUrl = “https://contoso-dev.sharepoint.com/sites/hr-policies”
• hrcontoso_LeaveTableId = “dev-leave-table-id”
• hrcontoso_ApiKey = references kv-hr-dev@hrApiKey

In Test:

• hrcontoso_SharePointUrl = “https://contoso-test.sharepoint.com/sites/hr-policies”
• hrcontoso_LeaveTableId = “test-leave-table-id”
• hrcontoso_ApiKey = references kv-hr-test@hrApiKey

In Prod:

• hrcontoso_SharePointUrl = “https://contoso.sharepoint.com/sites/hr-policies”
• hrcontoso_LeaveTableId = “prod-leave-table-id”
• hrcontoso_ApiKey = references kv-hr-prod@hrApiKey

Evaluation Test Set

Create a test set with 20 questions:

• “What is the leave policy for new employees?”
• “How do I request maternity leave?”
• “What benefits are available after 6 months?”
• “How do I check my remaining leave days?”

For each, define the expected response type and set the evaluation method (semantic similarity with a threshold of 0.8).

Deployment Flow

1. In Dev: Build agent, test in test pane, run evaluations
2. Evals pass: Export solution as managed to pipeline
3. Pipeline deploys to Test: Solution imported, values already configured
4. In Test: HR team validates, runs evaluations again
5. Evals pass: Promote to Prod via pipeline
6. In Prod: Agent published, employees can access it

Hotfix Scenario

A critical bug surfaces: the leave request tool is returning wrong data.

1. Prod-Aligned Dev: Import current production solution as unmanaged
2. Fix the bug: Edit the tool in Prod-Aligned Dev
3. Run evaluations: Confirm fix works
4. Export to pipeline: Deploy through Test → Prod
5. Primary Dev untouched: Ongoing feature work continues without interruption

Getting Started: Your Action Plan

If you’re just starting with Copilot Studio ALM, here’s what to do:

Week 1: Set Up the Foundation

1. Create Dev, Test, and Prod environments in Power Platform Admin Center
2. Create your first solution in Dev and set it as preferred
3. Build a simple agent inside the solution
4. Create environment variables for any configuration that might change

Week 2: Add Pipelines and Testing

1. Set up a pipeline connecting Dev → Test → Prod
2. Create your first test set with 10-20 questions
3. Run evaluations and make sure they pass
4. Deploy your agent to Test using the pipeline

Week 3: Harden Production

1. Configure security settings in Prod (Lockbox, auditing, RBAC)
2. Set up environment variable values in Prod
3. Deploy to Prod with evaluations passing
4. Document your process for the team

Week 4+: Iterate and Improve

1. Add more test cases to your evaluations
2. Set up scheduled evals in a Preview environment (if you have one)
3. Refine your pipeline with approval gates
4. Train your team on the process

The Payoff

When this is set up correctly, promoting your agent is a single pipeline action. The same logic runs against the correct endpoints, credentials, and data for each environment automatically. Secrets rotate without redeployment. Platform updates are validated early. Emergency fixes have a clean path that preserves ongoing development work.

The setup takes a few hours. The confidence it provides compounds every week the agent is in production.

You’ll stop worrying about “did I break something?” and start focusing on “how can I make this better?” That’s the real value of a solid environment strategy.

Final Thoughts

The environment strategy for Copilot Studio isn’t about following a rigid template. It’s about creating a foundation that lets you build safely, test thoroughly, and deploy confidently. The Dev-Test-Prod pattern is your starting point. Add Preview and Prod-Aligned Dev as your needs grow.

The key is to start early. Don’t wait until you’ve built five agents and realize you have no way to manage them. Set up your environments, create your solution, and build your first agent inside it. Make environment variables your default. Run evaluations before every deployment. Use the pipeline instead of manual exports.

These habits become second nature quickly. And when you need to make that emergency fix or validate that a platform update won’t break anything, you’ll be grateful you did.

If you’re building Copilot Studio agents for real users, this is the foundation you need. Everything else — advanced tools, complex orchestration, multi-channel deployment — builds on top of this.

I’m going to walk you through exactly how generative AI powers Copilot Studio agents, in plain English. No jargon, no fluff, and definitely no assumption that you have a developer background. Whether you’re an HR manager, a business analyst, a team lead, or just someone curious about what this whole AI agent thing is about, this tutorial is written for you.

Let’s go.

What Is Generative AI, Really?

Before we talk about Copilot Studio specifically, let me give you a quick, honest explanation of generative AI — because most articles either oversimplify it or make it sound more mysterious than it is.

Generative AI is a type of artificial intelligence that can create new content — text, answers, summaries — based on what it has learned from massive amounts of data. Think of it like a very well-read colleague who has absorbed thousands of documents, FAQs, manuals, and articles. When you ask them a question, they don’t just look up a saved answer. They actually compose a response on the spot, based on what they know.

That’s the key difference between old-school chatbots and generative AI.

Old-style chatbot: You ask a question. It matches your question to a predefined answer from a list. If your phrasing doesn’t match exactly, it fails.

Generative AI-powered agent: You ask a question. It understands the meaning behind your words and composes a fresh, relevant answer — even if it hasn’t seen that exact question before.

Microsoft Copilot Studio uses generative AI (specifically GPT models from Azure OpenAI — the same technology behind ChatGPT and Bing) to make your agents smarter, more flexible, and much easier to build.

What Is Copilot Studio, and Where Does AI Fit In?

Microsoft Copilot Studio is a low-code platform that lets you build AI agents — basically smart assistants that can answer questions, help users complete tasks, automate workflows, and integrate with your Microsoft 365 environment.

Before generative AI came along, building one of these agents meant manually creating “topics” — conversation flows where you’d define every possible question and every possible answer. It was like writing a giant decision tree. Very tedious. Very limited.

Now, with generative AI baked in, Copilot Studio can:

• Automatically answer questions from your company’s documents and websites — without you writing a single topic manually
• Understand what a user is asking even when they phrase it in unexpected ways
• Pick the right topic, action, or knowledge source based on context — automatically
• Generate natural, conversational responses instead of robotic pre-written ones

This is a genuinely big shift. Let me break down exactly how it works inside the platform.

The Four Pillars of Generative AI in Copilot Studio

There are four main ways generative AI appears in Copilot Studio. Understanding these four things will give you a solid mental model of how it all fits together.

1. Generative Answers

This is the most commonly used generative AI feature, and it’s the one that surprises people most when they first see it in action.

Here’s the idea: instead of manually writing topics for every possible question your users might ask, you connect your agent to a knowledge source — like your company’s SharePoint site, a public website, a PDF document, or a set of files. The agent then uses generative AI to read through that content and compose answers in real time.

Example: Let’s say you’re building an HR bot for your company. You upload your company’s HR policy document (leave policy, expense claims, code of conduct) to the agent as a knowledge source. Now when an employee asks “How many days of sick leave do I get per year?”, the agent reads through that document, finds the relevant section, and generates a clear, conversational answer — without you ever writing that Q&A pair manually.

This is called Generative Answers in Copilot Studio. It’s what makes it possible to build a useful agent in hours, not weeks.

Where it shows up: In the Topics section under System Topics, you’ll find a topic called Conversation Boosting. This is what handles generative answers. It triggers when the agent doesn’t recognize the user’s intent in any manually created topic. At that point, it reaches out to your knowledge sources and generates an answer on the fly.

You can control this completely — you can turn it on or off, decide whether to use only your own data or also allow public AI knowledge, and set how strictly it moderates content.

2. AI General Knowledge

This is a setting that lets your agent answer general questions using the AI’s broader training — even when the question isn’t related to any of your uploaded documents.

Think of it this way: your knowledge sources are like your company’s internal library. AI General Knowledge is about letting the agent also draw on its understanding of the wider world.

Example: A user asks your IT support agent, “What is a VPN?” — you probably haven’t uploaded a document explaining what a VPN is, but the AI already knows. If you have AI General Knowledge enabled, the agent will answer it.

This is useful for internal-facing agents where users might ask both company-specific questions and general questions in the same conversation. Just be mindful — if you’re building an agent that should only answer from your own data (for compliance reasons, for example), you’d want to keep this turned off.

3. Topic Authoring with AI

This one is a time-saver for anyone building agents, including non-developers.

When you want to create a new conversation topic manually — say, a flow where the agent collects information, asks follow-up questions, and then takes an action — you no longer have to build each step node by node. Instead, you just describe what you want in plain English, and Copilot Studio’s AI generates the topic structure for you.

Example: You type: “Ask the user for their name and email address, confirm the details with them, and then say you’ll get back to them within 24 hours.”

Copilot Studio will create a complete topic with message nodes, question nodes, and a confirmation message — all in a few seconds. You can then tweak it, add branching logic, or leave it as is.

This doesn’t mean the AI does everything perfectly every time. You’ll still review and adjust things. But it cuts out the grunt work of building from scratch, especially for people who aren’t familiar with the node-based editor.

4. Generative Orchestration

This is the most advanced of the four, and once you understand it, it completely changes how you think about building agents.

In Classic mode (the older way), an agent would look at what the user says, match it to a trigger phrase, and run the corresponding topic. Simple enough — but limited. If a user’s message matched multiple intents at once, the agent would struggle.

Generative Orchestration (also called Generative mode) flips this. Instead of using keyword matching, the agent uses AI to read the full context of a user’s question and then decide — at runtime — which topic, action, or knowledge source is the best match. It’s not looking for exact phrases. It’s understanding the meaning.

Example: A user messages your HR agent: “I want to apply for leave next week and also check my remaining balance.” In classic mode, this might confuse the agent because it’s two intents in one message. In generative orchestration mode, the AI understands both intents and can handle them intelligently — either by running two separate topics in sequence or by pulling information from both the leave application flow and the balance knowledge source.

To turn this on: go to Settings → Generative AI → switch the mode from Classic to Generative.

How the AI Actually “Reads” Your Documents

One question I get a lot is: “Does the AI memorize my documents?” The answer is: not exactly — and understanding this properly helps you set realistic expectations.

When you add a knowledge source to your agent (such as a SharePoint site or a PDF), Copilot Studio doesn’t permanently store the entire document in the AI’s memory. Instead, it uses a technique called Retrieval Augmented Generation (RAG).

Here’s how RAG works in simple terms:

1. A user asks your agent a question
2. The agent searches your connected knowledge sources to find the most relevant sections
3. Those relevant chunks of content are then passed to the AI model as context
4. The AI reads that context and generates a natural language answer based on it

So the AI isn’t “remembering” your document. It’s reading relevant parts of it in real time, every single time a question is asked, and composing an answer based on what it finds.

This is why the quality of your knowledge sources matters a lot. If your document is well-organized, clearly written, and up to date, the agent will give great answers. If the document is full of scanned images, tables that don’t paste well, or outdated information, the agent will struggle.

Practical tip: Use clean, text-based documents. Break information into clear sections with headings. Avoid embedding important information only in images or charts.

Knowledge Sources You Can Connect

One of the things that makes Copilot Studio genuinely useful for businesses is the range of sources you can connect. You’re not limited to uploading PDFs. Here’s what’s supported:

• Public websites — paste a URL and the agent will crawl and index it
• SharePoint sites and documents — perfect for internal knowledge bases
• Uploaded files — Word documents, PDFs, text files
• Dataverse — great if you’re using Dynamics 365 or custom data models
• Custom connectors — for advanced scenarios, pull data from external APIs

You can have multiple knowledge sources active at the same time. The agent will search across all of them and pull the most relevant content to answer each query.

When both your private knowledge sources and AI General Knowledge are enabled, the agent prioritizes your own data first. If it doesn’t find a relevant answer there, it falls back on the AI’s general knowledge. You control this priority.

The Conversation Boosting Topic — What It Is and Why It Matters

Let me spend a moment on this because it confuses a lot of people.

When you look at your Topics list in Copilot Studio and click on System topics, you’ll see one called Conversation Boosting. This is the system topic that handles generative answers.

The trigger condition is: On unknown intent — meaning, whenever the agent receives a message that doesn’t match any manually created topic, this system topic kicks in.

Within this topic, there’s a special node called “Create Generative Answers”. This node is what connects to your knowledge sources and generates the AI response.

Inside the data source configuration of this node, you have two choices:

1. Search from connected knowledge sources — this uses your own uploaded content
2. Allow AI to use its general knowledge — this opens up the broader AI training

You can choose one or both. If you choose both, the agent searches your knowledge first. This is the right setup for most business scenarios.

Why does this matter? Because it gives you control. You’re not just flipping an AI switch and hoping for the best. You decide exactly what the agent is allowed to draw from.

Setting Up Generative Answers — Step by Step

Let me walk you through how to actually enable and configure generative answers in Copilot Studio, even if you’ve never opened the tool before.

Step 1: Create or open your agent
Go to copilotstudio.microsoft.com and either create a new agent or open an existing one.

Step 2: Add a knowledge source
In the left navigation, click on Knowledge. Then click + Add knowledge and choose your source type — website URL, SharePoint, files, or Dataverse. Follow the prompts to connect it.

Step 3: Enable generative answers mode
Go to Settings → Generative AI. Here you can switch between Classic and Generative mode. For a beginner setup, keeping it on the default settings works fine. For more control, switch to Generative mode.

Step 4: Check your Conversation Boosting topic
In the Topics section, click System and open Conversation Boosting. Make sure it’s turned on. Click the Edit option inside the Create Generative Answers node and confirm your data source settings match what you want.

Step 5: Test it
Click the Test button (usually a chat icon in the top right). Ask a question that should be answered from your knowledge source. See what happens. If the answer isn’t quite right, check if the document has the relevant content in a clear, readable format.

What Makes a Good Generative AI Response vs. a Bad One

Once you’ve set everything up, you’ll notice some answers are great, and some are not so great. Here’s what makes the difference.

Things that lead to good answers:

• Your knowledge source has clear, well-written content that directly addresses common questions
• You’ve connected the right documents — not just anything, but the content that’s actually relevant to what users will ask
• You’ve tested with realistic questions, not just obvious ones
• Topic descriptions are clear and specific (for generative orchestration to work well)

Things that lead to poor answers:

• Documents with scanned text that wasn’t OCR-processed properly
• Outdated content that contradicts itself
• Knowledge sources that are too broad or unrelated to the agent’s purpose
• Over-relying on AI General Knowledge when you actually need your own data to take priority

One thing I always tell clients: garbage in, garbage out. The AI is genuinely good at synthesizing and presenting information — but it can only work with what you give it.

Responsible AI — What Guardrails Does Microsoft Put In?

This is a question that comes up often, especially from compliance teams and management.

Microsoft has built responsible AI principles into Copilot Studio. Here’s what that looks like practically:

• Content moderation: You can set how strictly the AI screens responses. There are options ranging from low to high moderation. High moderation will refuse to generate anything that looks potentially harmful, offensive, or inappropriate — even if the question itself seems innocent.
• Grounding: When using your knowledge sources, the agent is grounded to your content. It won’t make up facts that aren’t in your documents. If it can’t find an answer, it should tell the user it doesn’t know — rather than inventing something.
• Transparency: Microsoft is transparent about the fact that these agents are AI-powered. You can configure your agent to say it’s an AI when asked.
• Data privacy: Your internal documents connected via SharePoint or file upload are not used to train the AI model. They’re used only to answer questions for your users, within your tenant.

That last point matters a lot for organizations concerned about data leakage. Your company’s HR policy isn’t being sent to OpenAI to improve future models. It stays within your Microsoft 365 environment.

Real-World Scenarios Where This Shines

Let me give you some concrete examples of where generative AI in Copilot Studio actually delivers value:

HR Self-Service Agent
Upload your HR policy documents. Let employees ask questions about leave balance, expense processes, holiday schedules, and onboarding steps — all answered automatically from your official documents.

IT Helpdesk Agent
Connect your IT knowledge base articles. Users can troubleshoot common issues like password resets, VPN problems, and software installation — without raising a ticket or waiting for a human.

Customer Support Agent (External)
Connect your product documentation, FAQs, and pricing pages. Customers visiting your website get instant answers without waiting for a support agent.

Procurement & Vendor Queries (Internal)
Connect your vendor contracts, procurement policies, and supplier lists. Employees can ask about approval thresholds, preferred vendors, and ordering processes without emailing the procurement team.

In all of these cases, you haven’t written a single Q&A pair manually. The agent figures out the answers from your connected content, powered by generative AI.

Common Misconceptions I Keep Hearing

Before I wrap up, let me quickly address the things I hear most often that aren’t quite right.

“The AI will give wrong answers and embarrass us.”
This is a valid concern, but it’s manageable. If your knowledge sources are accurate and your content moderation is set properly, the agent is actually quite reliable. Always test before going live, and start with a narrower scope.

“We need a developer to set this up.”
Not anymore. Copilot Studio is genuinely low-code. If you can navigate Microsoft Teams and SharePoint, you can build a basic generative AI agent yourself. You might need a developer for advanced integrations — like custom connectors to external APIs — but for most business use cases, no coding is needed.

“Once we set it up, it runs forever without maintenance.”
Not quite. If your underlying documents change, your agent’s answers will change too — or become outdated if you don’t refresh the knowledge sources. Plan for regular reviews of your connected content.

“The AI is reading everything in real time from the live document.”
Depends on the source type. Some sources are indexed periodically (not always live), so there can be a lag between updating a document and the agent reflecting that update. Check the indexing schedule for your specific source type.

Quick Recap: The Key Things to Remember

• Generative AI in Copilot Studio uses GPT models (Azure OpenAI) to generate natural language answers
• Generative Answers lets your agent answer questions from your own documents and websites — no manual topic authoring needed
• Conversation Boosting is the system topic that controls when and how generative answers are triggered
• Generative Orchestration (Generative mode) makes the agent smarter about choosing which topic or knowledge source to use at runtime
• RAG (Retrieval Augmented Generation) is the technique used — the agent retrieves relevant content from your sources, then generates an answer based on it
• Your data stays in your tenant and isn’t used to train the AI model
• The quality of your knowledge sources directly determines the quality of your agent’s answers

If you’re just getting started, my suggestion is simple: pick one use case (like an HR FAQ bot), upload one clean document as your knowledge source, enable Conversation Boosting, and test it. You’ll understand 80% of how generative AI works in Copilot Studio just from doing that one exercise.

It’s more approachable than it sounds. Give it a go.

This is a great foundation before you move into more advanced topics like integrating with Power Automate, Dataverse, or SharePoint.

What you will build and prerequisites

In this tutorial, you will:

• Create a new Copilot Studio agent from scratch.
• Configure a basic persona and instructions so the agent behaves like an HR assistant.
• Add a knowledge source for your agent.
• Test the agent in the built‑in test pane.
• Publish the agent to a public demo website.

Before you begin, make sure you have:

• A Microsoft 365 tenant with Copilot Studio available or a trial enabled.
• The correct license and permission to create agents in your environment.
• Access to at least one environment (for example: Dev, Test, or Default).

If you already work with Power Apps or Power Automate, you will feel at home in the interface.

Step 1: Open Copilot Studio and choose the right environment

First, sign in to Microsoft 365 and open Copilot Studio (https://copilotstudio.microsoft.com/) from the app launcher or via the direct URL provided by your admin.

At the top of the Copilot Studio home page, you will see an environment selector. This works just like environments in Power Apps and Power Automate. If you have multiple environments, choose a Dev or Sandbox environment for experimentation. This keeps your test agents separate from production workloads.

If you only see a single “Default” environment, that is fine for learning and testing.

Here is a screenshot showing that I chose one development environment.

Step 2: Create a new Copilot Studio agent

On the Copilot Studio home page, click the button to create a New agent. You can see the screenshot below of how the recent Copilot Studio home page looks. Choose Agent and then click on Agent from the “Start building from scratch” option.

You will see a simple wizard:

1. Name – Give your agent a meaningful name, for example: HR FAQ Agent.
2. Description – Describe what this agent does, such as “Answers common HR and leave policy questions for employees”.
3. Language – Choose the primary language for the conversations (for example, English).
4. Region or environment settings – Keep the default for now unless your organization has specific requirements.

After you confirm, Copilot Studio will create the agent with some default system topics and capabilities. These built‑in topics handle basic greetings, conversation endings, and fallback behavior.

You can see the screenshot below for your reference. Here, the agent’s name is important.

This might take a few seconds to be ready. Wait, till you get a confirmation message like “Your agent has been provisioned”. Here is a screenshot for your reference.

You will customize the agent in the next steps.

Check out How to Monitor Token Usage by AI Model in Copilot Studio

Step 3: Update Agent details

In the Details section, you can customize the basic information for your agent:

1. Change the Agent name.
2. Upload or replace the Agent icon.
3. Provide or update the Agent description.

Configure these settings as shown in the screenshot below.

Step 4: Select your Agent’s model

In the Model section, choose the AI model that your agent will use to understand user requests, generate responses, and perform reasoning tasks.

As shown in the screenshot below, Copilot Studio provides access to multiple AI models from different providers, including OpenAI and Anthropic. You can select the model that best matches your business requirements and use case.

Some available options include:

• GPT-5 Chat – Optimized for general-purpose conversations and everyday tasks.
• GPT-5 Auto – Automatically switches between chat and reasoning capabilities as needed.
• GPT-5 Reasoning – Designed for complex problem-solving and advanced reasoning scenarios.
• GPT-5.3 Chat – Suitable for general chat-based interactions.
• GPT-4.1 – Provides fast responses and efficient analysis.
• Claude Sonnet 4.5 / 4.6 – Well-suited for content creation, question answering, and general business tasks.
• Claude Opus 4.6 / 4.7 / 4.8 – Intended for deep reasoning, complex workflows, and structured problem-solving.

Here is a screenshot for your reference. I chose the Claude Sonnet 4.6.

Note: The models available in your environment may vary depending on your organization’s licensing, region, and administrator settings. Select the model that best aligns with your agent’s expected workload and performance requirements, as shown in the screenshot below.

Step 5: Configure the agent’s persona and instructions

Every good agent needs a clear role and tone. In Copilot Studio, this is controlled by the instructions (similar to a system prompt).

In the Instructions section, click on the Edit icon and describe what the agent should do and how it should behave.

Add something like this (you can rewrite in your own words):

• “You are an HR assistant for Contoso. You help employees with general HR and leave policy questions. Use a friendly and professional tone. Keep answers short and clear.”

Then add a few simple boundaries:

• “If a user asks about technical support, politely tell them you only handle HR questions.”
• “If you are not sure about an answer, ask the user to contact the HR team via email.”

It should look like the screenshot below.

These instructions help shape the agent’s personality and provide basic guardrails. You can refine them later once you observe real conversations.

Step 6: Add a Knowledge Source to Your Agent

Knowledge sources help your agent provide accurate, context-aware responses by grounding answers in your organization’s content. In this example, a PDF document stored on the local computer is uploaded and used as the agent’s knowledge source.

Step 1: Open the Add Knowledge Dialog

Click Add knowledge from the Knowledge section of the agent.

As shown in the screenshot below, Copilot Studio provides multiple knowledge source options, including:

• Upload a file from your local device
• OneDrive
• SharePoint
• Public websites
• Azure AI Search
• Dataverse
• Dynamics 365
• Salesforce
• ServiceNow
• Azure SQL

Since the knowledge source is stored locally, select Upload file and browse to the PDF document.

Step 2: Upload the PDF Document

After selecting the file, Copilot Studio displays the uploaded document in the file list.

In this example, the Employee HR Policy Handbook.pdf file has been uploaded successfully and is ready to be added to the agent.

To continue, click Add to agent.

Note: Copilot Studio currently supports text-based files. The uploaded content is processed and indexed so the agent can use it when generating responses.

Step 3: Verify the Knowledge Source

Once the upload is complete, the document appears in the Knowledge section of the agent.

A Ready status indicates that the file has been successfully processed and is available for the agent to use when answering user questions.

In this example, the Employee HR Policy Handbook.pdf document is now connected to the agent and can be used to answer HR-related queries based on the information contained in the handbook.

Step 4: Disable Web Search

By default, you can optionally enable Web Search to allow the agent to retrieve information from public websites.

For this HR policy agent, Web Search has been disabled, as shown in the screenshot below.

Disabling Web Search ensures that:

• Responses are based only on approved internal knowledge sources.
• The agent does not pull information from external websites.
• Users receive answers that are consistent with organizational policies and documentation.
• The risk of providing conflicting or outdated public information is reduced.

This approach is recommended for scenarios involving internal policies, employee handbooks, compliance documents, standard operating procedures (SOPs), and other organization-specific content.

Step 7: Test your agent in the Test pane

Before publishing, always test the agent inside Copilot Studio.

Before testing your agent with a new query, start a fresh test session to clear the existing conversation context. This ensures that the agent responds as if it is interacting with a new user and prevents previous messages from influencing the results.

1. Open the Test your agent pane by clicking the Test button in the upper-right corner.
2. In the test pane toolbar, click the Start new test session icon (highlighted in the screenshot below).
3. A new conversation session will begin, and the agent will be ready to receive a fresh query.

This is especially useful when validating new topics, testing agent changes, or troubleshooting responses after making updates to your Copilot Studio agent.

After starting a new test session, enter a question in the test pane to verify how your agent responds using the configured knowledge sources.

In this example, the user asks:

“Explain me about the leave policy”

The agent searches the connected knowledge source and generates a response based on the information it finds.

You can see the exact response in the screenshot below:

What to Review in the Test Panel

1. Search Sources Activity

• The Search sources activity shows that the agent successfully searched the configured knowledge source.
• The Completed status indicates that the search operation finished successfully.

2. Referenced Sources

• Under Referenced sources, you can see the document that was used to generate the response.
• In this example, the agent retrieved information from:
  • Employee HR Policy Handbook.pdf
• The source preview helps you verify exactly where the answer originated.

3. Agent Response

• The response generated by the agent appears in the conversation pane.
• Here, the agent summarizes the leave policy and displays details such as:
  • Annual Leave entitlement
  • Sick Leave entitlement

4. Validate Response Accuracy

• Compare the generated answer with the referenced document to ensure the information is accurate.
• This helps confirm that the knowledge source is properly indexed and that the agent is retrieving the correct content.

Why This Is Important

Reviewing the Search sources details is one of the most effective ways to troubleshoot and validate your Copilot Studio agent. It allows you to:

• Verify that the correct knowledge source is being used.
• Understand how the agent generated its answer.
• Identify missing or incorrect information in your knowledge base.
• Improve the quality and reliability of responses before publishing the agent to users.

Step 8: Publish the agent to a demo website

Once you are happy with the basic behavior, you can publish the agent so others can try it.

• Publish the Agent

Once you have finished testing your agent, click the Publish button from the top navigation bar like in the screenshot below:

This opens the Publish this agent dialog, where you can make the latest version of your agent available to users.

• Publish the Latest Version

In the Publish this agent dialog:

1. Select the Force newest version option.
2. Click Publish.

Here is a screenshot for your reference.

This ensures users receive the most recent version of the agent and any updates you have made.

• Open the Channels Page

After the publishing process completes:

1. Navigate to the Channels tab.
2. If you see a message indicating that only Microsoft channels are available, your agent is currently using Microsoft authentication.

Here is how it appears:

To publish the agent to a public demo website, you need to change the authentication settings.

• Change Authentication Settings

1. Click Settings in the top menu.
2. Select Security from the left navigation.
3. Under Authentication, choose No authentication.
4. Click Save.

Here is a screenshot for your reference.

This allows the agent to be shared through public channels, including the Demo Website channel.

• Open the Demo Website Channel

1. Return to the Channels page.
2. Open the Demo Website channel.
3. Configure the following information:
   • Welcome message (for example, I am your HR FAQ Agent)
   • Conversation starters (optional)
4. Click Save.

Here is a screenshot for your reference.

You can also copy the generated website URL if you want to share it directly.

• Launch the Demo Website

Click Open demo website.

The demo website opens in a new browser tab, allowing you to interact with the published agent exactly as an end user would.

At this point, your Copilot Studio agent is successfully published and available through the Demo Website channel for testing and sharing.

Conclusion

Microsoft Copilot Studio makes it easy to build AI-powered agents without extensive coding knowledge. In this tutorial, you learned how to create your first AI agent, add knowledge sources, test its responses, publish it, and make it available through a demo website.

By following these steps, you can quickly build agents that answer questions, automate common tasks, and provide self-service support for employees, customers, or business users. As you become more familiar with Copilot Studio, you can further enhance your agents with topics, actions, Power Automate flows, and integrations with other Microsoft services.

Start with simple use cases, validate the responses using the testing tools, and gradually add more advanced capabilities to create intelligent agents that deliver real business value.

Token usage, Copilot Credits, billing meters — these terms get thrown around a lot, and it’s easy to ignore them until you suddenly get a notification that your environment has hit its usage limit or you’ve blown past your monthly capacity. I’ve seen it happen more times than I’d like.

In this tutorial, I’ll walk you through how Copilot Studio measures and tracks usage, where to monitor it, what the different billing rates mean, and how to keep costs under control before they spiral. I’ll also cover the specific behavior of reasoning models like GPT-5 Reasoning, which have a different billing structure that trips people up.

Let’s get into it.

First, Let’s Clear Up the Terminology

When people say “token usage” in Copilot Studio, they’re really talking about Copilot Credits — that’s the unit Microsoft uses to measure consumption. The underlying AI models do process tokens internally (the words and word-fragments the model reads and generates), but from a billing and monitoring perspective, Copilot Studio wraps everything into Copilot Credits.

Think of Copilot Credits like a prepaid data plan. You buy a pack, you spend credits based on how your agents run, and when you run out, things stop working — unless you’ve set up a pay-as-you-go fallback.

When you purchase a Copilot Studio license, your organization gets a pool of Copilot Credits. This pool is shared across your entire tenant, so every environment draws from the same bucket by default (unless you specifically allocate capacity to individual environments, which I’ll cover later).

What Consumes Microsoft Copilot Credits?

This is where a lot of people are surprised. It’s not just the AI responses that consume credits — it’s also actions, flows, and tools that your agent invokes along the way.

Here’s the breakdown of what gets billed and how much:

A single conversation turn can hit multiple of these. For example, if a user asks a question and the agent:

• Performs a generative answer → 2 credits
• Does tenant graph grounding to search your SharePoint content → 10 credits
• Total for that single response: 12 Copilot Credits

And that’s for a straightforward Q&A. The more complex and action-heavy your agent is, the more credits each session burns through.

The Reasoning Model Billing: A Special Case

If you’ve chosen one of the reasoning models — like GPT-5 Reasoning or Claude Opus 4.1 — the billing works differently from standard models. You need to understand this before you deploy a reasoning model in any agent that gets regular use.

Reasoning models are billed on two meters at the same time:

1. The feature rate — the standard rate for whatever the agent is doing (generative answer, agent action, etc.)
2. Text and generative AI tools (premium) — an additional 100 Copilot Credits per 10 responses, specifically to cover the extra compute that deep reasoning requires

So the total cost formula for a reasoning model operation looks like this:

Total cost = Feature rate + Premium AI tools rate (100 credits per 10 responses)

Let me make that concrete with an example:

Say your agent uses a reasoning model to generate a response to a complex policy question. That’s one generative answer (2 credits) plus the premium reasoning cost (100 credits per 10 responses, so 10 credits per single response). One interaction = 12 credits minimum, just for the answer — before any actions or graph grounding.

That doesn’t mean you shouldn’t use reasoning models. But it does mean you should be careful about which agents get them. Don’t put a reasoning model on an agent that handles 5,000 interactions a day unless you’ve done the math and you’re comfortable with the consumption.

Where to Monitor Copilot Credit Consumption

Now that you understand what drives consumption, here’s where to actually check it.

In the Power Platform Admin Center

This is the main place to monitor your organization’s overall Copilot Credit usage. Here’s how to get there:

1. Go to admin.powerplatform.microsoft.com
2. Sign in with your admin account
3. In the left navigation, go to Billing → Licenses or Analytics → Copilot Studio
4. Look for the Copilot Credit consumption report

This report shows you:

• How many Copilot Credits your tenant has consumed
• Which environments are using the most
• Whether you’re approaching or have exceeded your capacity limits

If you’ve allocated credits to specific environments, you’ll see per-environment breakdowns. If you haven’t allocated credits to environments, all consumption rolls up to tenant-level and environments share from the common pool.

In Copilot Studio Analytics

Within Copilot Studio itself, each agent has an Analytics section that gives you engagement and session-level data. To access it:

1. Open your agent in Copilot Studio
2. Click the Analytics tab in the left navigation
3. Review the Summary, Engagement, and Billing tabs

The Billing tab is particularly useful. It shows you session counts, message volume, and can help you estimate your ongoing credit consumption for that specific agent. It’s not a real-time credit counter, but it gives you enough data to spot trends and flag agents that are consuming more than expected.

Using the Copilot Studio Usage Estimator

Before you deploy an agent, it’s worth using Microsoft’s Copilot Studio agent usage estimator to forecast your credit consumption. You can find this tool through the Microsoft Copilot Studio licensing documentation.

You plug in:

• Agent type (generative, classic, or mixed)
• Estimated daily/monthly traffic
• Orchestration mode
• Knowledge sources (graph grounded or not)
• Whether it uses tools or flows

The estimator then gives you a projected Copilot Credit usage figure, which you can use to check whether your current capacity covers it. This is especially valuable before launching a new agent in production.

Understanding Quotas vs. Credits in Copilot

These are two different things, and it’s worth being clear on the difference.

Copilot Credits are about how much capacity you’ve purchased. Run out of credits, and your agents stop working until you top up.

Quotas are about how fast your agents can process requests — measured in requests per minute (RPM) or requests per hour (RPH). These exist to protect the platform from traffic spikes.

Here’s what the quotas look like depending on your capacity:

If your agent hits the RPM quota, users will see a failure message when they try to send a message. This is separate from running out of credits — it’s a throttle, not a shutdown. Once traffic drops back within the limit, the agent works again automatically.

So if you’re building an agent that you expect to handle high-traffic periods (like a lunch-hour HR helpdesk spike), make sure your capacity tier supports the throughput you need.

What Happens When You Hit Your Limit?

This is the part no one wants to learn the hard way.

When your tenant reaches 125% of its prepaid Copilot Credit capacity, enforcement kicks in. Here’s what that means in practice:

• Custom agents are disabled — but not mid-conversation. Any active conversation finishes, then no new conversations are accepted.
• Users see an error message like: “This agent is currently unavailable. It has reached its usage limit.”
• Your admin gets an email notification, and a banner appears in the Power Platform admin center.

To recover, your admin can do one of three things:

1. Reallocate unused capacity from another environment
2. Purchase additional Copilot Credits
3. Set up a pay-as-you-go meter for overage handling

The pay-as-you-go option is worth considering for unpredictable workloads. Instead of your agent going dark when credits run out, consumption continues and gets billed on a usage basis. It costs more per credit, but it keeps your agent running.

How to Allocate Credits to Specific Environments

By default, all your environments share from the tenant-level credit pool. This works fine when you have one or two agents, but when you have multiple environments — development, testing, production — it creates a risk: a poorly optimized test agent could eat through credits and impact production.

To prevent that, you can allocate a specific credit budget to individual environments.

Here’s how:

1. Go to Power Platform Admin Center
2. Navigate to Resources → Capacity
3. Select the environment you want to allocate capacity to
4. Set a Copilot Credit allocation for that environment

Once an environment has its own allocation, it only consumes from that pool. If it runs out, it can draw from the tenant pool — but if you want strict isolation, you can configure it so that tenant-level fallback doesn’t apply.

In the example from Microsoft’s documentation: if you allocate 10,000 credits to Environment A, that environment runs independently until it burns through those 10,000. Only then does it start drawing from the shared tenant pool.

Practical Tips to Keep Usage in Check

Here are the habits I’d recommend building if you’re running multiple agents or managing an environment for a team:

1. Use classic answers where you don’t need AI
Classic answers (manually authored responses) cost just 1 credit vs. 2 credits for generative answers. For highly predictable questions with fixed answers — think FAQs, standard procedures — stick to classic topics. Save generative AI for the queries that actually need it.

2. Be selective with graph grounding
Tenant graph grounding costs 10 credits per response on top of everything else. It’s powerful, but it adds up fast. Use it only in agents that genuinely need to search across your organization’s data, not as a default “just in case” setting.

3. Don’t deploy reasoning models for high-volume, simple tasks
GPT-5 Reasoning or Claude Opus 4.1 for a Q&A bot that handles 10,000 questions a month is going to burn through a disproportionate amount of credits. Match the model to the task. Simple questions don’t need premium reasoning models.

4. Check the analytics weekly
The Copilot Studio Analytics tab gives you session and message volume trends. Build a habit of looking at it once a week during rollout. Spotting a spike early is much easier than explaining an overage to finance after the fact.

5. Use the estimator before every new agent launch
Run the usage estimator before you publish a new agent to production. It takes five minutes and can save you from an unexpected bill or a hard shutdown.

6. Allocate credits per environment in production setups
If you’re running multiple environments, allocate budgets explicitly. It gives you clear visibility into which environments are spending what, and prevents a dev environment from accidentally draining your production capacity.

A Quick Example to Put It All Together

Let me run through a real scenario to show how the pieces fit.

You’re running a customer support agent on your company website. Here’s its average configuration per session:

• 4 classic answers (for standard return policy questions): 4 × 1 = 4 credits
• 2 generative answers (for troubleshooting): 2 × 2 = 4 credits
• Total per session: 8 credits
• 900 customer interactions per day: 8 × 900 = 7,200 Copilot Credits per day

Over 30 days, that’s roughly 216,000 Copilot Credits for that one agent.

Now, imagine you switch the agent to use a reasoning model for those generative answers. Each generative answer now costs 2 credits (feature rate) + 10 credits (premium reasoning, amortized at 100/10). So those 2 generative answers become 2 × 12 = 24 credits per session instead of 4. Your daily cost goes from 7,200 credits to over 25,000 credits — just by changing the model.

That’s a 3.5× increase in credit consumption for the same workload. Sometimes a reasoning model is worth it. For a customer support FAQ agent? Almost certainly not.

Wrapping Up

Monitoring token (Copilot Credit) usage in Copilot Studio isn’t complicated once you know what to look for and where to look. The key places are:

• Power Platform Admin Center for tenant-wide and per-environment credit consumption
• Copilot Studio Analytics for per-agent session and billing data
• Microsoft’s usage estimator for pre-launch forecasting

The most important habit is to check these regularly and match your model choice to your workload. Use generative AI where it adds value, use classic responses where it doesn’t, and be especially careful with reasoning models in high-volume scenarios.

If you haven’t already, explicitly allocate credits to your environments — it gives you much cleaner visibility into where spending is occurring and protects your production environment from surprises.

In this tutorial, I’ll walk you through everything you need to know about AI model selection in Copilot Studio — what each model does, when to use it, how to switch models, and what your admin needs to set up before you can use the newer ones. I’ll also cover some real practical scenarios so you know exactly which model fits which situation.

Let’s get into it.

Why Does AI Model Choice Even Matter?

Think of the AI model as the brain powering your Copilot agent. When a user asks a question, the model is what decides how to understand that question and frame a response.

Different models are built differently — some are faster, some are more thorough, some are better at following complex instructions, and some are particularly good at reasoning through multi-step problems.

Picking the wrong model won’t break your agent, but it can lead to:

• Slow responses when a lightweight model would do the job just fine
• Shallow or incomplete answers when your use case needs deeper reasoning
• Higher message consumption than you expected
• Inconsistent formatting, even when you’ve given detailed instructions

So yes, model choice genuinely matters, and now that Copilot Studio lets you switch, it’s worth understanding what each option brings to the table.

How to Change the AI Model in Copilot Studio

Before we dive into which model to pick, let me show you how to actually change it. It’s simpler than you’d think.

1. Open your agent in Copilot Studio
2. Go to the Overview tab of your agent
3. In the Model section, you’ll see a dropdown showing your current model
4. Click the chevron (the small arrow icon) to expand the model list, you can see all the models in the screenshot below:

5. Select the model you want to use
6. A confirmation message will appear, letting you know the model has been updated

That’s it. You can switch models at any time, even after your agent is already built and tested. This makes it easy to experiment — build your agent with the default model, then try swapping to a different one and compare the responses.

One important thing: the model you see in that dropdown depends on what your admin has enabled. If you only see GPT-4.1, it probably means preview and experimental models haven’t been turned on for your environment. More on that in the admin settings section below.

Understanding the Model Tags

When you look at the model list, each model comes with a couple of tags. Understanding these tags saves you from picking a model that’s not ready for what you’re building.

Tag 1: Model Use Category

This tells you what kind of tasks the model is optimized for:

• General — Fast and cost-efficient. Best for everyday chat, FAQs, summarization, translation, and simple question-answer scenarios. If you’re building a basic helpdesk bot or an internal FAQ agent, a General model is your go-to.
• Auto — Handles a mixed bag of tasks intelligently. It routes queries dynamically, so it’s great when you have an agent that might need to handle a mix of simple questions and more complex actions. Think of it like a smart router that adjusts based on what the user is asking.
• Deep — Built for complex, multi-step reasoning. If your agent needs to analyze long documents, work through policy-heavy scenarios, or perform multi-hop reasoning (where the answer depends on combining information from several places), this is your model. It’s slower and costs more, but for the right use case, it’s worth it.

Tag 2: Availability Status

This tells you how production-ready the model is:

• Default — This is the currently recommended model for most agents. Copilot Studio periodically upgrades the default model as better ones become generally available. Right now, GPT-4.1 is the default.
• No tag (GA) — Generally Available. Fully tested, stable, and ready for production use at scale.
• Preview — Works well but isn’t officially recommended for production yet. You can use it in test environments or non-critical scenarios. Performance is generally good, but Microsoft is still gathering feedback.
• Experimental — Early access only. These models are there for you to explore and provide feedback on. Don’t deploy them in production. You might experience slowdowns, timeouts, or variable quality.
• Retired — The model has been replaced but is still available for up to 30 days after retirement. More on this below.

The OpenAI Models Available in Copilot Studio

Here’s a breakdown of the current OpenAI models you’ll find in Copilot Studio:

GPT-4.1 (Default)

This is the default model for all new agents right now. It replaced GPT-4o as the default in late 2025. GPT-4.1 is a text-only model with strong accuracy and reasoning — it’s particularly good at analyzing detailed documents, complex knowledge-base Q&A, and scenarios where precision matters.

Best for: Document analysis agents, policy Q&A, knowledge management bots, and scenarios where you need reliable and consistent responses.

Availability: Generally Available (GA) — safe for production.

GPT-5 Chat (General)

GPT-5 Chat is the conversational upgrade from GPT-4.1. It handles context better across long conversations and produces more natural, human-like dialogue. If your agent needs to maintain context across a multi-turn conversation or feel genuinely conversational, GPT-5 Chat performs noticeably better than GPT-4.1 in that department.

Best for: Employee self-service chatbots, IT/HR helpdesk agents, customer-facing agents where natural conversation flow matters.

Availability: Generally Available — production ready.

GPT-5 Auto (Auto)

This is where it gets interesting. GPT-5 Auto isn’t just a chat model — it’s built to orchestrate multi-step workflows. It can automate actions across multiple systems, not just respond to questions. Think of it as a “digital project manager” that can figure out what needs to happen, in what order, and kick off those steps.

Best for: End-to-end process automation, ticket creation to resolution flows, multi-step task sequences that touch several apps or systems.

Availability: Preview — good for testing and non-critical environments, not recommended for production yet.

GPT-5 Reasoning (Deep)

If you need serious analytical power, this is it. GPT-5 Reasoning is trained specifically for complex reasoning tasks — the kind where the model needs to think carefully through the problem, not just retrieve an answer. It scores high on document understanding and structured problem-solving.

Best for: Compliance auditing, financial analysis, interpreting complex multi-part data, and advanced planning scenarios where you need thorough, carefully thought-out responses.

Availability: Preview — test it, but hold off on deploying it in production.

GPT-5.2 Chat and GPT-5.2 Reasoning (Experimental)

These are the most cutting-edge models in the lineup right now. GPT-5.2 builds on GPT-5 with improved context awareness and reasoning depth. They were made available in late 2025 in early release environments.

Best for: Experimenting with the latest capabilities. Use these if you want to stay ahead of the curve and test what the newest model can do before it hits GA.

Availability: Experimental — strictly for testing. Do not use in production.

The Anthropic (Claude) Models

This is the big news from 2025. Microsoft opened up Copilot Studio to external models from Anthropic, meaning you can now power your agents with Claude models, not just OpenAI ones.

These are “external” models — meaning they’re hosted outside Microsoft’s infrastructure, on Anthropic’s side. Because of that, your admin needs to explicitly enable them, and you need to accept Anthropic’s data handling terms before using them. More on that in a moment.

Claude Sonnet 4.5 (General)

Claude Sonnet 4.5 is Anthropic’s latest coding and agent-focused model. It’s exceptional at tool use, step-by-step reasoning, and handling complex multi-step agent workflows. In practice, when I’ve seen it tested for response formatting tasks — like following specific date format instructions — it consistently does better than GPT-4.1 at following detailed instructions.

Best for: Advanced software development assistance, building multi-step autonomous agents, tasks that require integration with external tools and systems, and scenarios where following complex formatting instructions precisely is important.

Availability: Preview (Frontier Program) — available for early experimentation, not recommended for production.

Claude Opus 4.1 (Deep)

Claude Opus 4.1 is Anthropic’s reasoning powerhouse. It’s designed for intensive analysis and structured problem-solving. If you have a scenario that needs very thorough, methodical reasoning — think compliance auditing, elaborate planning, or synthesizing information from long documents — this is worth testing.

Best for: In-depth data analysis, research summarization, complex reasoning tasks where depth and thoroughness are more important than speed.

Availability: Experimental — use only for exploration and testing.

A Quick Side-by-Side Comparison

Here’s a summary to help you match your use case to the right model:

What Your Admin Needs to Enable

This part catches a lot of makers off guard. If you open the model dropdown and only see GPT-4.1, it doesn’t mean other models don’t exist — it means your admin hasn’t turned on the settings for them.

There are three key admin controls:

1. Allow Preview and Experimental Models

Your admin needs to go into the Power Platform admin center and turn on the “Preview and experimental AI models” setting for your environment. Without this, you’ll only see Generally Available models.

To check or change this:

1. Go to Power Platform admin center
2. Select your environment
3. Go to Settings → Features
4. Enable Allow Preview & Experimental AI models

2. Move Data Across Regions

Experimental models may not run in the same data center as your environment. For example, if your environment is in Europe but the experimental model is hosted in the US, your data needs to cross regions to use it.

Your admin needs to enable Move data across regions in the Power Platform admin center. If this is off, experimental model features simply won’t work.

3. Enable Anthropic as a Microsoft Subprocessor (for Claude Models)

To use Claude Sonnet 4.5 or Claude Opus 4.1, a Global Administrator needs to go to the Microsoft 365 Admin Center and enable the setting:

“Enable Anthropic as a Microsoft subprocessor subject to the above terms”

If this isn’t enabled, the Anthropic models won’t appear in your dropdown at all — not even as an option. Once it’s enabled, users also need to accept Anthropic’s data handling terms in Copilot Studio before they can start building with Claude.

What Happens When a Model Gets Retired?

Microsoft periodically upgrades the default model. When that happens, the old model gets a “Retired” tag. You can still use a retired model for up to 30 days after the upgrade.

Why would you want to do that? A few real reasons:

• Your agent’s downstream systems expect a specific response format or style, and the new model’s output is structured differently
• You’re in the middle of a product launch or critical event, and stability is more important than getting new features right now
• Your compliance team needs to vet the new model before it processes sensitive data in your environment

To keep using a retired model:

1. Go to your agent’s Settings page
2. In the Generative AI tab, find the Model section
3. Toggle on “Continue using retired models”

This gives you up to 30 days to update and test your agent with the new model before the old one is fully removed. After 30 days, the retired model is gone — so don’t wait too long.

My Practical Recommendation: How to Actually Decide

Honestly, the best approach is to start with GPT-4.1 and test your way to a better model if needed. Here’s how I’d approach it:

Step 1: Build your agent with GPT-4.1 (the default)
It’s stable, production-ready, and handles most scenarios well. Don’t overthink the model before you’ve even built the thing.

Step 2: Test it with real questions
Put in 10–15 realistic prompts that represent what your users will actually ask. Look at the quality, depth, and structure of responses.

Step 3: Identify what’s missing
Is it too shallow? Too slow? Not following your formatting instructions precisely? That tells you what to look for in another model.

Step 4: Test one alternative
If conversations feel robotic or context is getting lost, try GPT-5 Chat. If your agent needs to reason through complex multi-step problems, try GPT-5 Reasoning in a dev environment.

Step 5: Compare side by side
Ask the same question with two different models and compare the responses for depth, structure, tone, and accuracy. Copilot Studio makes this easy since you can switch models and start a new test session instantly.

A Real Example: HR Recruitment Agent

Let me put this in context with a real scenario. Say you’re building an HR recruitment agent that:

• Summarizes candidate resumes
• Suggests interview questions based on job criteria
• Answers employee policy questions

Here’s how the models perform differently for this:

• GPT-4.1 will return structured summaries. It’s reliable but sometimes misses nuanced formatting instructions (like specific date formats).
• GPT-5 Chat generally follows formatting instructions more precisely and provides richer, more contextual responses with natural suggestions.
• Claude Sonnet 4.5 tends to produce more concise responses and is notably better at consistently following detailed response formatting rules.

In testing, Claude Sonnet 4.5 correctly formatted dates using a specific MMM dd, yyyy format when the other models occasionally slipped up. For a scenario where precise formatting matters — like structured candidate reports — that’s a meaningful difference.

Check out How to Monitor Token Usage by AI Model in Copilot Studio

One More Thing: You Can Mix Models in Multi-Agent Systems

If you’re building multi-agent systems in Copilot Studio (where one orchestrator agent calls specialized sub-agents), you don’t have to use the same model for everything. You can give different agents different models based on their role.

For example:

• Your orchestrator agent uses GPT-5 Auto for intelligent routing
• Your document analysis agent uses GPT-5 Reasoning for deep document comprehension
• Your chat-facing agent uses GPT-5 Chat for natural conversation

With the prompt tools in Copilot Studio, you can even mix Anthropic and OpenAI models across different tasks in the same workflow. This is powerful when you have diverse workloads with very different requirements.

Wrapping Up

Choosing the right AI model in Copilot Studio doesn’t have to be complicated. The short version:

• GPT-4.1 is your solid, production-ready default for most agents
• GPT-5 Chat is the upgrade for more natural, conversational experiences
• GPT-5 Auto is what you want for complex automation workflows
• GPT-5 Reasoning / Claude Opus 4.1 are for deep analytical and reasoning tasks
• Claude Sonnet 4.5 shines at agentic workflows, code, and following detailed instructions

Start simple, test with real data, compare responses, and don’t be afraid to switch. The model dropdown is right there on your agent’s Overview tab — use it.

If you’re using experimental or Claude models, loop in your admin early to make sure the environment settings are in place. Nothing is more frustrating than building out an agent only to find out your environment doesn’t have preview models enabled.

That is exactly the kind of thing a component is good at. So in this tutorial, I’m going to keep the focus on components inside a canvas app, and I’ll build the explanation around one realistic example: a reusable Header component that shows “Welcome” and the logged-in user name on the left side, and on the right side shows the user image and the user name again.

Why I Use Components in Power Apps

When I build Power Apps, I usually notice the same pattern very quickly. I create one screen, then another, and then I end up copying the same controls across both screens. Maybe it is a header, maybe a footer, maybe a filter bar, maybe a popup.

That works at first, but it becomes painful later.

If I manually build the same header on five screens, and then I decide to change the layout, font size, spacing, or colors, I need to update all five versions. That is exactly the kind of repetitive work I try to avoid.

A component solves that problem.

I create the header once, design it properly, and then reuse it wherever I want. If I need to make a change later, I update the component once, and the rest of the app stays consistent.

That is the simplest reason to use components:

• Less duplicate work.
• Cleaner app design.
• Easier maintenance.
• More consistency across screens.

And honestly, that last one matters a lot. Users may not know what a component is, but they do notice when one screen looks slightly different from another.

What Are Components in Power Apps

A component in Power Apps is a reusable building block that can contain controls, formulas, styles, and custom properties. Think of it as a self-contained mini app element that you can design once and use many times.

Instead of placing ten labels, five icons, and a few buttons separately on every screen, I can wrap them into a component and reuse that component wherever needed. That saves time, keeps the design consistent, and makes future changes much easier.

Components are most useful in canvas apps, where you often build reusable UI patterns such as:

• Headers.
• Side navigation.
• Dialog boxes.
• Tabs.
• Cards.
• Status indicators.
• Search bars.
• Date or filter selectors.

The component can contain:

• Labels.
• Icons.
• Images.
• Shapes.
• Buttons.
• Formulas.
• Custom properties.

That last part is important. Custom properties are what make the component flexible. They let me pass different values into the component or get values out of it.

The big idea is simple: build once, reuse everywhere.

Check out Data Table Control in Power Apps Canvas App

Components vs Component Libraries in Power Apps

This is where many people get confused, so I like to keep it very simple.

A component is the reusable object itself.

A component library is a container where components can be stored and reused across multiple apps in Power Apps.

If you only need a reusable element inside one Power Apps app, a local component may be enough. But if you want to reuse that same component in several apps in Power Apps, a component library is usually the better choice.

Here is the practical difference:

In real projects, I often start with a local component while designing. Once the pattern proves useful, I move it into a library so I can reuse it across future apps too.

Power Apps Component Example

To make this practical, let’s use your exact scenario.

I want to create a Header component with this layout:

Left side

• Text: Welcome
• Logged-in user name

Right side

• Logged-in user image

So visually it might look like this:

Left side:
Welcome {User Name}

Right side: [User Photo]

This is actually a very useful example because it covers the most common things people want to do with components:

• Reuse a header on multiple screens.
• Show logged-in user information.
• Control layout inside a component.
• Keep the app clean and consistent.

And the nice part is that Power Apps already gives us the user details we need through the User() function.

The most useful values are:

• User().FullName
• User().Email
• User().Image

That means I can use the current user’s name and image directly inside the component without making the app complicated.

When I would use a component for this header

This header is a perfect case for a component if:

• I want the same header on multiple screens.
• I want the same look and spacing everywhere.
• I may change the design later.
• I want a cleaner structure in the app.

If the app has only one screen and the header will never be reused, I could build it directly on the screen. But in most real-world apps, especially business apps, the header appears repeatedly.

Examples:

• Home screen.
• Dashboard screen.
• Request form screen.
• Approval screen.
• Details screen.

If the same header appears in these places, I almost always turn it into a component.

What this header component should contain

Before building any component, I like to decide what belongs inside it.

For this header, I would include:

• A background shape, usually a rectangle or container.
• A label for “Welcome”.
• A label for the user’s full name on the left side.
• An image control for the user’s photo on the right side.

You can keep it simple at first. The point is not to make the header fancy. The point is to make it reusable.

A clean header is usually better than an overloaded one.

Step-by-step: Create the Header component

Now let’s build it.

Step 1: Open your canvas app

Open your app in Power Apps Studio. Here, I have created a responsive Canvas app.

Step 2: Make sure components are available

In most apps, components are available by default. If you don’t see the Components area, check the app settings and confirm components are enabled.

Step 3: Create a new component

In the tree view, create a new component.

I would rename it immediately to something meaningful, such as:

• cmpHeader
• cmpAppHeader
• cmpUserHeader

I prefer names that clearly tell me what the component does.

For this example, I’ll use cmpHeader. You can see the screenshot below. I have created a component.

Step 4: Set the size

Set the component width and height.

A common starting point could be:

• Width: App.Width
• Height: 80 or 90

If I want the header to stretch across the app, using App.Width is usually a good option.

Optionally, you can set a background color for the header using the Fill property. I chose a dark blue color for the header component background.

Step 5: Add the “Welcome” label

Insert a label on the left side.

Set the Text property to:

"Welcome" & User().FullName

Here, User().FullName gives the logged-in user’s full name.

Here, I used the Font color property to change the font color to white.

Step 6: Add the user image on the right

Insert an Image control on the right side.

Set its Image property to:

User().Image

This shows the logged-in user’s profile image, as long as it is available in Microsoft 365.

Here, I adjusted the X property as:

Parent.Width-Self.Width-5

Then make the size to 80 * 80.

If you want to give the image a rounded look, change the Border radius to 50.

You can see the screenshot below of how the header component looks:

At this stage, the component is already functional. And we can use it on our screens.

Read Set Control Value in Button Click on Power Apps

How to Use the Component on a Power Apps Screen

Now, let me show you how to use the component on a Power Apps screen.

• Open the screen where you want to add the component. In our case, I want to add the component to the header container.
• Click the + icon, then under the Custom category, select the component, as shown in the screenshot below.

• Once you have added successfully, you can see the header component appears as below. In the same way, you can add the component to other screens also.
• You can also adjust the width if it overlaps, like the Width property as App.Width-40

This is how to create and use components in Power Apps.

Power Apps Component Properties

The real power of Power Apps components comes from custom properties. These allow the parent app and the component to communicate with each other.

Component properties are what make a component flexible.

Without properties, a component is mostly fixed.
With properties, a component becomes reusable in different ways.

There are three property types a beginner should know:

• Input properties
• Output properties
• Behavior properties

Let me explain each one simply.

Input Properties

An input property is a value that goes into the component.

In simple words, the screen gives something to the component.

For example:

• A greeting text
• A title
• A color
• A true/false value
• A name
• An image

So if I want the header to show different greetings on different screens, I should not hardcode “Welcome” forever. Instead, I can create an input property.

Example

Suppose I create an input property called:

• GreetingText

Now, instead of setting the label text to:

"Welcome"

I can set it to:

cmpHeader.GreetingText

Then from one screen I can pass:

"Welcome"

And from another screen I can pass:

"Hello"

Same component, different text.

Where to Create an Input Property

Here is the exact flow:

• Select the component itself, not a label or image inside it. Go to the option for custom properties. Here is the screenshot for your reference.

• Click New custom property. Enter the property name, such as GreetingText.
• Choose Input as the property type.
• Choose the data type, such as Text. Save it. Here is the screenshot for your reference.

The property is now available for the component.

For this header example, you can add more useful input properties:

• GreetingText – Text
• HeaderFillColor – Color
• HeaderTextColor – Color
• ShowUserPhoto – Boolean

Now, we need to change the greeting message. In the same component, select the Text label and change the Text property to this:

Parent.GreetingText&" " & User().FullName

• Now, go to the screen where you have used the component, and change the GreetingText property to “Welcome”. Now, you can see how it appears below:

• Now, you can see I have added two components, and you can see I can give different GreetingText. Here is a screenshot for your reference.

This is how to use the input component properties in Power Apps.

Output Properties

An output property is a value that comes out of the component.

In simple terms, the component returns something to the screen.

This is useful when something happens inside the component, and the screen needs that result.

For example:

• A text entered inside the component
• A selected item
• A chosen tab
• A value calculated inside the component

A very simple way to understand it

If input means:

“Screen gives data to component”

Then output means:

“Component gives data back to screen”

Example output property idea

Suppose the component had a search box.

Then I could create an output property called:

• SearchText

And return the text entered in the text input.

That way, the parent screen can use:

cmpHeader.SearchText

to filter a Power Apps gallery.

Where to create an output property

1. Select the component.
2. Go to Custom properties.
3. Click New custom property.
4. Give it a name like SearchText.
5. Choose Output.
6. Choose the data type, such as Text.
7. Save it.

Then link that property to the control value inside the component.

For a fresher, the easiest way to remember it is:

• Input = screen to component
• Output = component to screen

Behavior Properties

A behavior property is used when the component needs to trigger an action.

This one is slightly different from input and output.

It is not mainly for passing data.
It is for doing something.

For example:

• Clicking a button
• Opening a popup
• Navigating somewhere
• Running logic on select

A Practical Example

Suppose I add a small icon in the header for profile settings.

When the user clicks it, I want the parent screen to decide what should happen.

Maybe:

• Open a popup
• Navigate to Profile screen
• Show a menu

In that case, I create a behavior property like:

• OnProfileClick

Then I connect that property to the icon’s OnSelect.

So the component handles the click, but the screen decides what action should happen.

Where to create a behavior property

1. Select the component.
2. Go to Custom properties.
3. Click New custom property.
4. Name it something like OnProfileClick.
5. Choose Behavior or Event, depending on what the studio shows.
6. Save it.

Then use that property in the control’s behavior formula.

An easy way to remember behavior properties

If input and output are about data, behavior is about actions.

That is the simplest way to think about it.

Check out Power Apps Concatenate Strings

A Beginner-Friendly Way to Remember All Three Properties

This is the easiest explanation I use:

• Input property = I send something into the component.
• Output property = I get something back from the component.
• Behavior property = I make the component do something.

If you remember just that, you are already in a good place.

A Better Version of This Header with Input Properties

Now let me make the example a little smarter, but still beginner-friendly.

Instead of hardcoding everything, I can add these input properties:

• GreetingText
• HeaderFillColor
• HeaderTextColor
• ShowUserPhoto

Then I can use them like this

For the welcome label:

cmpHeader.GreetingText

For the background fill:

cmpHeader.HeaderFillColor

For label text color:

cmpHeader.HeaderTextColor

For the image visibility:

cmpHeader.ShowUserPhoto

Now this same component becomes much more flexible.

On one screen, I can say:

• GreetingText = “Welcome”

On another screen:

• GreetingText = “Hello”

And I still use the same component.

That is exactly why custom properties are so important.

How to Use the Component on a Screen

Once the component is ready, here is what a beginner should do next.

1. Go to any screen in the app.
2. Insert the component.
3. Place it at the top of the screen.
4. Resize it if needed.
5. Set any custom input properties you created.

For example, if you created GreetingText, select the component on the screen and set:

"Welcome"

If you created HeaderFillColor, set it to a color such as:

RGBA(0, 120, 212, 1)

Now the component is working from the screen level.

This is the point where most beginners suddenly understand components. They see that the component is not stuck with one design. It can be reused and configured.

Check out Patch Function in Power Apps

When to Use User() Directly and When to Use Input Properties

This is another question beginners often have.

Use User() directly inside the component when:

• You always want the logged-in user’s details
• You want the simplest setup
• The component is specifically meant for the signed-in user

Use input properties when:

• You want the parent screen to control the values
• You may reuse the component for another person later
• You want more flexibility

For this beginner header example, using User().FullName and User().Image directly is perfectly fine.

It keeps the example simple and easy to follow.

Conclusion

Power Apps components are a simple but powerful way to make your apps cleaner, more reusable, and easier to maintain. In this tutorial, I showed how a Header component can display a welcome message, the logged-in user name, and the user image in a neat layout that you can reuse across screens.

The main idea is to build once and reuse many times. Once you get comfortable with components, you will spend less time repeating the same controls and more time building better app experiences. Do let me know in the comments below if this helps to you.

You may also like the following tutorials:

• Power Apps Modern Checkbox Control
• Power Apps Modern Date Picker with Time
• Sequence Function in Power Apps