But if you open the model picker and only see GPT 5.5, the problem may not be your Cowork license or the rollout.
There is one Microsoft 365 admin setting you need to check first.
OpenAI must be enabled as a Microsoft subprocessor before users can access the new OpenAI-operated models.
Before OpenAI is enabled as a Microsoft subprocessor, the Copilot Cowork model picker may show GPT 5.5 but not GPT 5.6 Sol or Terra.
The hidden dependency behind GPT-5.6 in Cowork
Microsoft now supports OpenAI-operated models in Microsoft 365 Copilot experiences. That is different from OpenAI models operated by Microsoft through Azure OpenAI.
For GPT-5.6, Microsoft’s documentation is direct: if you want to use GPT-5.6, you need to enable OpenAI-operated models.
That means the model picker is not the first place to troubleshoot. Start in the Microsoft 365 admin center.
Where to enable OpenAI as a subprocessor
You need to be a Global Administrator or AI Administrator to change this setting.
Go to the Microsoft 365 admin center and follow these steps:
Open Copilot.
Select Settings.
Select View all.
Open AI providers operating as Microsoft subprocessors.
In the Microsoft 365 admin center, go to Copilot > Settings > View all, then open AI providers operating as Microsoft subprocessors.
Choose who gets access
Expand OpenAI. From there, choose which users can access OpenAI-operated models:
All users
No users
Specific users and groups
Then select Save.
OpenAI is disabled by default in the current admin experience. Admins can enable it for everyone or scope access to specific users and security groups.
For a pilot, I would start with Specific users and groups.
This setting is applied at the provider level across supported Microsoft 365 Copilot and Copilot Studio experiences. Scoping it to a security group gives you a clean way to test the new models with a small group before expanding access.
What users see after the setting is enabled
After the setting is saved, go back to Copilot Cowork and open the model picker again.
In my tenant, the new choices appeared as:
GPT 5.6 Sol — the most capable GPT-5.6 model for complex work.
GPT 5.6 Terra — the balanced GPT-5.6 model for high-volume work.
After enabling OpenAI as a Microsoft subprocessor, GPT 5.6 Sol and GPT 5.6 Terra appear in the Copilot Cowork model picker.
That is the before-and-after test.
If GPT-5.6 is missing, check the provider setting before you spend time troubleshooting the user, the browser, or Cowork itself.
The governance detail admins should not skip
Enabling this setting is not just a feature toggle. It is a data-processing decision.
Microsoft says OpenAI operates these models as a Microsoft subprocessor under contractual safeguards and appropriate technical and organizational measures. Microsoft Product Terms, the Microsoft Data Protection Addendum, and Enterprise Data Protection apply, subject to Microsoft’s documented exclusions.
There are also two details worth reviewing with your governance team:
OpenAI-operated models are currently excluded from in-country processing commitments where those commitments apply.
They are not currently available in GCC, GCC High, DoD, or sovereign clouds.
Do not turn this on just because the new model names look interesting. Decide who needs access, document the data-processing change, and start with a controlled group.
One rollout date to pay attention to
Microsoft says OpenAI-operated models are currently disabled for customers. Starting July 24, 2026, they will be enabled for all users in eligible commercial tenants unless an admin explicitly selects No users.
That makes this a setting every Microsoft 365 Copilot admin should review, even if the organization is not ready to use GPT-5.6 yet.
The question is no longer just, “How do I turn GPT-5.6 on?”
It is also, “Who should get it, and what should our policy be before the default changes?”
The practical rollout pattern
Confirm the Global Administrator or AI Administrator who owns the setting.
Review the OpenAI subprocessor terms and data-processing notes.
Create a security group for the first Cowork users.
Enable OpenAI for that group.
Confirm GPT 5.6 Sol and Terra appear in the Cowork model picker.
Test real work with a small group before expanding access.
Review the setting again before the July 24 default change.
The technical step takes a minute.
The admin decision behind it deserves more attention.
If GPT-5.6 is missing in Copilot Cowork, start with the OpenAI subprocessor setting.
Copilot Cowork browsing is a powerful capability, but there is one admin setting you need to turn on first.
If you want Copilot Cowork to complete browser-based work using Microsoft Edge, browser access must be enabled in the Microsoft 365 admin center.
Where to enable Copilot Cowork browsing
Go to the Microsoft 365 admin center and follow these steps:
Open Copilot
Select Settings
Select View all
Find Cowork
Turn on Allow browser access
Select Save
Copilot Cowork browser access setting in the Microsoft 365 admin center.
This setting is off by default.
Once enabled, Copilot Cowork can use Microsoft Edge to interact with web apps and services on behalf of users. That means it can navigate pages, enter data, and complete browser-based tasks when APIs are not available.
What users see before using browsing
After browsing is available, users still see a confirmation screen before starting. The prompt explains that Cowork browsing is in preview, can perform tasks on the user’s behalf, and may make mistakes or misinterpret instructions.
The confirmation screen users see before starting Copilot Cowork browsing.
This is the right pattern for enterprise use. Admins control whether browser access is available. Users acknowledge the risks before using it. Cowork asks for approval before sensitive actions.
Why this matters
A lot of business work still happens inside web applications that do not have clean APIs, connectors, or automation-friendly interfaces. Browser access gives Copilot Cowork another way to help users complete real work across those systems.
Examples I would test first
The best Copilot Cowork browsing scenarios are the annoying business tasks trapped inside web apps.
Portals. Admin screens. Expense systems. Vendor sites. Internal tools. Places where the work still requires a person to open a browser, navigate pages, enter data, review details, and decide what happens next.
Here are the types of scenarios I would start testing.
1. Expense reports in a web expense system
This is one of the cleanest examples because the work is structured, repetitive, and still needs human review.
Cowork could gather receipt context from Outlook or OneDrive, open the expense system in Edge, fill in the draft expense report, ask for missing details, and stop before submission.
Prompt idea:
File my expense report for last week's trip.
Use receipts from Outlook and OneDrive as the source of truth.
Open the expense portal in Edge and draft the report.
Ask me for anything missing.
Do not submit until I approve the final details.
2. Vendor portal status checks
A lot of finance and operations work happens inside vendor portals. Invoice status, payment status, shipment updates, support tickets, contract renewals, and order details are often sitting behind a web login.
Cowork browsing could open the vendor portal, search for the right invoice or order, capture the current status, and draft a response for the internal team.
Prompt idea:
Check the vendor portal for invoice 10482.
Find the current status, payment date if available, and any open notes.
Summarize what you found.
Then draft a short Teams message to finance with the update.
Do not send it until I review it.
3. Customer portal research
Customer service teams often need to check external portals before replying to a customer. That could mean checking an order, subscription, case, shipment, license, claim, or account record.
This is a strong Cowork browsing scenario because it combines browser work with communication work.
Prompt idea:
Open the customer portal and check the status for customer Contoso.
Look for the latest open request, current status, owner, and next action.
Summarize the findings.
Then draft a customer-ready email response.
Do not send the email until I approve it.
4. HR onboarding portal updates
Onboarding work is full of small browser tasks. Create a profile. Fill out required fields. Check what is missing. Update a checklist. Confirm access requests.
Cowork browsing could help prepare those steps while keeping the human in control for sensitive actions.
Prompt idea:
Open the HR onboarding portal for the new hire listed in this email.
Review what fields are required.
Draft the onboarding profile using the source email and attached documents.
Flag anything missing.
Stop before saving or submitting changes.
5. Municipal or government web form work
This is where I think browsing gets very interesting for public sector and municipal scenarios.
There are still many web forms, portals, service request systems, permit lookups, inspection pages, and public-facing intake tools that require browser-based work.
Cowork browsing could help collect information, check status, prepare form entries, and draft the next action while keeping final submission under human approval.
Prompt idea:
Open the permit status portal and check application PR-2026-0142.
Capture the current status, last update, required action, and any missing documents.
Summarize the result.
Then draft an internal update for the service team.
Do not submit any forms or make changes without approval.
The pattern
The pattern is simple.
Use Cowork for browser tasks that are repetitive.
Use it where the user already has access.
Use it where the work involves checking, entering, preparing, or summarizing information.
Keep human approval in place before anything sensitive is submitted.
I would not start with high-risk demos like payments, account changes, or anything that feels too close to personal data. Start with business workflow examples where the value is obvious and the review step is clean.
Before testing Copilot Cowork browser-based scenarios, check the admin setting first.
One checkbox can completely change what Copilot Cowork is able to do.
But before you run into the tenant, turn everything on, and let users start throwing goals and long-running tasks at it, you need to understand the billing side.
Copilot Cowork runs on Copilot Credits. That means the admin work is not just, “Can the user access it?” It is also, “Who can spend credits, how much can they spend, which billing method gets charged, and who gets warned before usage goes sideways?”
Turning Copilot Cowork on is easy. Turning it on responsibly is where the real admin work starts.
In this walkthrough, I am setting up Copilot Cowork billing from the Microsoft 365 admin center and showing the choices I would pay attention to before giving users access.
What changed with Copilot Cowork GA
Microsoft announced Copilot Cowork general availability on June 16, 2026. Cowork requires a Microsoft 365 Copilot user subscription license, and Cowork usage is billed separately on a usage basis using Copilot Credits.
That matters because Copilot Cowork is not just another chat surface. It is designed for complex, long-running, multi-tool work. It can retrieve context, call tools, use models, create artifacts, and keep working through a task. All of that value has a meter behind it.
Microsoft’s current Cost Management experience for usage-based billing applies to Copilot Cowork and Work IQ API right now, with more agents and services expected to come into that experience over time.
Cost Management in the Microsoft 365 admin center is where Copilot Cowork and Work IQ API usage-based billing is configured.
Start with the right mental model
Access and consumption are two different things.
Access lets a user get into the experience. Consumption happens when the experience starts doing work. If Cowork runs a goal, uses a model, retrieves context, calls tools, or performs longer-running work, that activity can consume Copilot Credits.
That is why billing policies matter. Without them, you are basically handing out an AI gas card and hoping the bill looks reasonable at the end of the month.
That is not a strategy.
The better approach is billing plus governance. Set the billing method, define the spending policy, decide who is in scope, add limits, configure alerts, and then expand once you understand real usage.
Check your admin roles before you start
If you do not see the option in the admin center, check your role first.
Billing setup and policy governance may not be handled by the same person in a real organization. Your Microsoft 365 admin, AI admin, Power Platform admin, billing admin, and finance owner might all be different people.
That matters because the person configuring the billing method needs the right permissions, and the person managing policy limits and alerts also needs the right permissions. Do not discover that halfway through the rollout call. Get the right people in the room before you begin.
Choose the billing method intentionally
In the setup flow, you may see more than one billing method. In my tenant example, I had Capacity Packs available and also had the option to use a pay-as-you-go subscription.
Capacity Packs let you bill against prepaid Copilot Credit capacity. Pay-as-you-go can keep services running once capacity pack credits run out, but it also means the meter can keep running against the connected subscription.
Neither option is automatically good or bad. The point is to make the choice on purpose.
Select the billing method intentionally. Capacity Packs and pay-as-you-go behave differently when credits run out.
For a personal tenant or a controlled pilot, I would usually start with the most bounded option. For a production rollout where interruption would be a problem, you may choose to include pay-as-you-go, but that decision should involve the billing owner.
What if you have no Copilot Credits?
If your tenant does not already have Copilot Credits available, do not let that push you into an unlimited rollout. Start with pay-as-you-go, but treat it like a metered pilot, not an open tab.
Microsoft lists PayGo for Copilot Cowork at $0.01 per Copilot Credit. That means 25,000 credits would be about $250 if you let usage land entirely on pay-as-you-go.
That is the point where the economics should make you stop and re-check the licensing path. Microsoft lists Copilot Studio credit packs at 25,000 Copilot Credits for $200 per pack per month. So if you expect usage to get anywhere near 25,000 credits in a month, PAYG is no longer just a convenient starter option. It may be more expensive than buying a capacity pack.
The practical setup I would use is this: enable PAYG to get started, set the monthly policy limit at 25,000 credits, turn alerts on well before that point, and review usage before the policy hits the cap.
At 10,000 credits, check whether the pilot group is using Cowork the way you expected.
At 20,000 credits, start the capacity pack conversation because the $200 pack economics are already close.
At 25,000 credits, do not just increase the PAYG limit without a decision. Buy a P3 or Copilot Credit capacity pack if monthly usage is becoming predictable.
PAYG is still useful. It is the fastest way to start when you have no credits, and it is a good safety net for overages. But once usage becomes steady, capacity packs are the cleaner budgeting conversation.
Do not assume the visible credit pool is unused
This is the part admins need to slow down on.
In my example, the Cost Management setup showed 50,000 credits available. But in the Power Platform admin center, 10,000 of those Copilot Studio messages were already allocated to a specific environment.
Before assigning a Cowork policy, check whether Copilot Credits are already supporting other Power Platform or Copilot Studio workloads.
The lesson is simple: do not treat the number in one setup panel as the whole story.
Copilot Credits can support more than one AI workload. If your organization is already using Copilot Studio, Dynamics 365, Power Platform, or other metered AI capabilities, make sure you understand what that credit pool is already expected to cover.
The last thing you want is for a Cowork pilot to burn through credits that another production agent was relying on.
Do not start unlimited
The setup flow gives you the choice to limit monthly spending or leave monthly spending unlimited.
My recommendation for most organizations starting with Copilot Cowork is simple: do not start unlimited.
Launch it like a controlled pilot. Give it a monthly policy budget, watch usage, learn what normal looks like, then increase the limit later if the usage is healthy.
In my example, I set the policy budget to 40,000 credits because I wanted to keep 10,000 credits available for other Copilot Studio usage in the tenant. Your number will be different. The principle is the same.
Set a per-user monthly limit
The per-user monthly spending limit is optional, but I would seriously consider enabling it.
Without a user limit, one person can potentially consume a large chunk of the available credits. They may not be doing anything malicious. They might just be experimenting, running long tasks, testing browser automation, asking for big research outputs, or sending Cowork work that should have stayed in regular Copilot Chat.
That kind of experimentation is a sign adoption is happening. But adoption without guardrails becomes waste.
Set a policy-level monthly budget, consider a per-user monthly limit, and configure alerts before activating the policy.
In the demo tenant, I used a 40,000 credit policy limit and a 20,000 credit per-user limit because the pilot only had two users. That is an example, not a universal recommendation.
The right number depends on how many users are in scope, what tasks they will run, how much existing Copilot Credit capacity is already committed, and how much risk you are willing to tolerate during the first rollout.
Turn alerts on before usage surprises you
Do not wait until the end of the month to learn usage went sideways.
Cost Management lets you define alerts so the right people get notified when usage reaches a threshold. That could be the Microsoft 365 admin, billing owner, finance stakeholder, platform owner, or whoever is accountable for the pilot.
In my example, with a 40,000 credit monthly policy limit, I used a 30,000 credit alert threshold. That gives the owner time to investigate before the policy hits the cap.
This is how you move from reactive admin to proactive admin.
Do not activate for everyone by default
This is the part of the setup that is easy to rush.
If you activate broadly, you may be enabling access across the whole organization depending on how the policy is configured. For some organizations, that might be fine. For most first rollouts, I would not start there.
Customize the setup configuration and scope the policy to a security group.
Create a clear security group for the pilot, such as Copilot Cowork Access, instead of starting with the entire tenant.
Use a clear name like Copilot Cowork Access or Copilot Cowork Pilot Users. Add a small group of trusted users first: admins, builders, business champions, finance, operations, or the people who will give you useful feedback.
Think of this like a pilot program. You want people who will use it seriously, report what worked, report what wasted credits, and help you understand whether the budget is realistic.
Scope the policy to specific groups so you know exactly who can consume Copilot Credits through Cowork.
Review the policy before you activate it
Before clicking activate, review the setup like a change request:
Which services are enabled by the policy?
Which billing method will be charged?
Is the monthly spending limit set?
Is the per-user limit set?
Who receives alerts?
What threshold triggers those alerts?
Which users or groups are in scope?
Are other workloads already using the same credit pool?
In my setup, the final shape was:
Billing method: Capacity Packs
Policy monthly limit: 40,000 credits
Per-user monthly limit: 20,000 credits
Alert threshold: 30,000 credits
Access scope: a specific security group for Copilot Cowork access
Again, those are demo values. Do not copy them blindly. Copy the pattern: limit, alert, scope, observe, then scale.
The rollout pattern I would use
If I were rolling out Copilot Cowork in a tenant, I would not start with the whole organization. I would use this pattern:
Confirm the admin roles needed for billing and policy management.
Review existing Copilot Credit usage in Microsoft 365 and Power Platform.
Choose the billing method with the billing owner involved.
Create a bounded monthly spending policy.
Add a per-user limit for the pilot group.
Set alerts before the policy limit is reached.
Create a security group for pilot access.
Add a small number of serious users.
Monitor usage and identify what tasks burn credits.
Increase limits or expand access only after you understand normal usage.
This gives you control. You know who has access, what they can consume, which budget they are under, and when someone needs to pay attention.
That is how you test Copilot Cowork without turning the tenant into a free-for-all.
Final thought
Copilot Cowork is powerful because it can take on real work. But the more real the work gets, the more important the admin controls become.
Cost Management is not the boring part of Copilot Cowork. It is the part that lets you adopt it without surprising finance, burning shared credits, or giving every user an unlimited meter on day one.
Start controlled. Learn the usage. Then scale with confidence.
In this example I am going to use the existing agent I created from Part 1.
Modify or create the agent with a meaningful name, description, and icon. (You can use the one I provided from above or use your own)
Name: MS Docs Agent
Description: MS Docs Agent is your on-demand mentor for Microsoft technologies—built with Copilot Studio and powered by the Microsoft Learn MCP server. Every answer comes from the live, authoritative docs that Microsoft publishes each day, so you never rely on stale model memories or web-scraped content.
Orchestration = Enabled
For your Instructions for the agent, we don’t want to add too much. After much testing I found that in its current state the Docs MCP server handles the instructions well and having too much instructions causes the response to fail. So its better to leave instructions blank for now.
Web Search – This should be Disabled. We only want the agent to query the docs which it does through the MCP server.
Knowledge should be empty, the only thing we want this agent to do is query the Docs MCP server, so this should be the only Tool that the agent has access to.
When users interact with the agent in M365 chat (Copilot) we can show suggested prompts to help guide the user in what is possible with this agent. Here are a bunch of samples you can give your agent:
Title
Prompt
Dev Env for Power Apps
Set up a developer environment for Power Apps—step-by-step.
Rollup vs Formula
Rollup fields vs Formula columns in Dataverse—when to use each?
Flow 502 Fix
Power Automate flow fails with 502 Bad Gateway—how do I resolve it?
Cert Path Finder
Fastest certification path for a Dynamics 365 functional consultant.
PL-200 Module List
List every Microsoft Learn module covered by the PL-200 exam.
Managed Env Enable
Turn on managed environments and approval gates in Power Platform.
Finance DLP Policy
Best-practice DLP setup for finance data in Power Platform.
Power Fx Date Filter
Sample Power Fx to filter a gallery to today’s records.
OpenAI Flow Sample
Minimal example: call Azure OpenAI from Power Automate.
Secure Env Vars
Secure environment variables with Azure Key Vault in flows.
Pipeline Checklist
Checklist to deploy a solution through Power Platform pipelines.
PCF Chart Control
Build a PCF control that renders a chart on a model-driven form.
New PA Features
Summarize new Power Apps features announced this month.
Preview Connectors
List preview connectors added to Power Automate in the last 30 days.
Explain to a Child
Explain Dataverse to a five-year-old.
You can only add 6 Suggested Prompts. So choose carefully.
Agent Settings
Next we want to configure some settings on the agent.
Click the Settings button on the top right.
(Optional) If you want the agent to have reasoning capabilities > Under Generative AI turn on: Deep reasoning **Note that this is a premium feature**
Scroll down to Knowledge, make sure Use general knowledge and Use information from the Web are both OFF
Make sure to click Save once done.
Turn Off Pointless Topics
Next we will turn off the topics we don’t want the agent to use.
Click on Topics tab > Under Custom > Only leave Start Over topic On.
Under System > Turn Off: – End of Conversation – Escalate – Fallback – Multiple Topics Matched
Next, lets modify the Conversation Start to make it sound better. Click Conversation Start topic > Modify the Message node:
Click Save.
Now we are ready to Publish and Package for Teams!
Publish & Package for Teams
Next we need to Publish our agent.
Click on the Channels tab > Click Publish
Once your agent is published > Click on the Teams and Microsoft 365 Copilot channel.
A sidebar opens > Check the Make agent available in Microsoft 365 Copilot > Click Add channel.
After the channel has been added > Click Edit details.
This is where we configure the agent in Teams. We will modify the icon, give a short description, long description and allow for the agent to be added to a team and meeting chats. Under Teams settings > Check both: – Users can add this agent to a team – Use this agent for group and meeting chats
Click Save
Submit Agent for Approval
Now because we want our organization to easily find and use this agent. We will submit the agent to the Agent Store. To do this follow these steps:
First Publish your agent, to make sure you have the newest version you are pushing to Teams admin for approval.
Next click on the Channels tab > Select the Teams and Microsoft 365 Copilot channel.
Now click Availability options.
Now we will configure the Show to everyone in my org.
Than click Submit for admin approval. Now we will look at what a Teams Admin has to do.
Approve Agent App (As a Teams Admin)
A Microsoft Teams Admin will have to approve the Agent app before your org can use it. As a Teams Admin follow these steps:
Note:: You will need Admin Approval each time you want to publish an update to the agent.
How to Use the Agent
Once your agent is approved by an Admin. You can easily find it in the Agent Store. Another easy way to get to your agent is to open it from Copilot Studio:
Click Channels tab > Select Teams and Microsoft 365 Copilot channel > Click See agent in Teams.
You will be brought to Teams with the agent open. You can now add it:
Adding Agent to a Meeting or Chat
There are a few ways to add the agent to a meeting. One easy way is to @mention the agent in the chat.
**Note to start typing the name of the agent, and it should show up**
Troubleshooting
There are a few things to note that I ran into: 1) If your getting an error on the MCP Server, remove all custom instructions
2) Sometimes your agents details can be cached and showing old metadata. In this case you can resubmit the app approval.
3) Always test the Agent inside Copilot Studio Test Pane with tracking topics and Activity Map turned On.
UPDATE—August 8, 2025: You no longer need to create a custom connector for the Microsoft Learn Docs MCP server. Copilot Studio now includes a native Microsoft Learn Docs MCP Server under Add tool → Model Context Protocol. This guide has been updated to show the first-party path. If your tenant doesn’t yet show the native tile, use the Legacy approach at the bottom.
What changed
No YAML or custom connector required
Fewer steps, faster setup
Model Context Protocol (MCP) is the universal “USB-C” port for AI agents. It standardizes how a model discovers tools, streams data, and fires off actions—no bespoke SDKs, no brittle scraping. Add an MCP server and your agent instantly inherits whatever resources, tools, and prompts that server exposes, auto-updating as the backend evolves.
Zero-integration overhead – connect in a click inside Copilot Studio or VS Code; the protocol handles tool discovery and auth.
Future-proof – the spec just hit GA and already ships in Microsoft, GitHub, and open-source stacks.
Hallucination killer – answers are grounded in authoritative servers rather than fuzzy internet guesses.
What the Microsoft Learn Docs MCP Server delivers
Tools:microsoft_docs_search – fire a plain-English query and stream back markdown-ready excerpts, links, and code snippets from official docs.
Always current – pulls live content from Learn, so your agent cites the newest releases and preview APIs automatically.
First-party & fast — add it in seconds from the Model Context Protocol gallery; no OpenAPI import needed.
Bottom line: MCP turns documentation (or any backend) into a first-class superpower for your agents—and the Learn Docs server is the showcase. Connect once, answer everything.
Prerequisites
Copilot Studio environment with Generative Orchestration (might need early features on)
Environment-maker rights
Outbound HTTPS to learn.microsoft.com/api/mcp
Step 1 – Add the native Microsoft Learn Docs MCP Server
Choose the connection (usually automatic) and click Add to agent.
Confirm the connection status is Connected.
Copilot Studio Add tool panel showing Model Context Protocol category and Microsoft Learn Docs MCP Server tile highlighted.
The MCP server should now show up in Tools.
Click the Server to verify the tool(s) and to make sure: – ✅ Allow agent to decide dynamically when to use this tool – Ask the end user before running = No – Credentials to use = End user credentials
Step 2 – Validate
In the Test your agent pane. Turn on Activity map by clicking the wavy map icon:
Now try a prompt like: – What MS certs should I look at for Power Platform? – How can I extend the Power Platform CoE Starter Kit? – What modern controls in Power Apps are GA and which are still in preview? Format as a table
Note that currently the Learn Docs MCP server does NOT require authentication. This will most likely change in the future.
If Model Context Protocol is not shown in your Tools for Copilot Studio. You may need to create an environment with Early Features turned on.
Do NOT reference the MCP server in the agents instructions, you will get a tool error.
Check Activity tab for monitoring
Legacy approach (if the native tile isn’t available)
Grab the Minimal YAML
Open your favorite code editor or notepad. Copy and paste this YAML to a new file.
swagger: '2.0'
info:
title: Microsoft Docs MCP
description: Streams Microsoft official documentation to AI agents via Model Context Protocol
version: 1.0.0
host: learn.microsoft.com
basePath: /api
schemes:
- https
paths:
/mcp:
post:
summary: Invoke Microsoft Docs MCP server
x-ms-agentic-protocol: mcp-streamable-1.0
operationId: InvokeDocsMcp
consumes:
- application/json
produces:
- application/json
responses:
'200':
description: Success
Save the file with .yaml extension.
Import a Custom Connector
Next we need to create a custom connector for the MCP server to connect to. We will do this by importing our yaml file we created in Step 1.
Go to make.powerapps.com > Custom connectors > + New custom connector > Import OpenAPI.
Upload your yaml file eg: ms-docs‑mcp.yaml, using the Import an OpenAPI file option.
General tab: Confirm Host and Base URL. Host: learn.microsoft.com Base URL: /api
Security tab > No authentication (the Docs MCP server is anonymously readable today).
Definition tab > verify one action named InvokeDocsMcp is present. Also add a description.
Click Create connector. Once the connector is created, click the Test tab, and click +New Connection. (Note, you may see more than 1 Operation after creating the connector. Don’t worry and continue on)
When you create a connection, you will be navigated away from your custom connector. Verify your Connection is in Connected Status. Next we will wire this up to our Agent in Copilot Studio.
Many Power Automate users encounter issues with the dateDifference() function when calculating the difference between two dates. The problem arises when the output format varies depending on the duration, causing errors in extracting Days, Hours, Minutes, and Seconds.
This blog provides a robust and easy-to-implement solution that works seamlessly in all scenarios, including durations less than a day. Learn how to use a single expression with conditional logic to avoid these common pitfalls and ensure your date calculations are accurate every time. This is your ultimate fix for handling dateDifference() errors!
Compose action: named StartDate = 2024-12-10T15:58:28
Compose action: named EndDate = 2024-12-10T19:22:20
Compose action: uses dateDifference() expression. see below
Below is the expression used in the ‘Date Difference’ compose action. It dynamically handles all scenarios—when days are included and when they are not (same with hours and minutes).
The if() function checks if the dateDifference() result contains a . (dot).
If it does, it means the result has a days component (e.g., 1268.04:15:30), so we parse out Days, Hours, Minutes, and Seconds accordingly.
If it does not, it means the result is less than a day (e.g., 12:57:47.2544602), so we treat Days as 0 and parse Hours, Minutes, and Seconds directly from the string.
Result:
This will produce a JSON object like: { "Days": 1268, "Hours": 4, "Minutes": 15, "Seconds": 30 } Or { "Days": 0, "Hours": 12, "Minutes": 57, "Seconds": 47 }
Steps to Access Each Value
If you use the fixed expression directly in a Compose action (e.g., named Date_Difference), you can reference the fields like this:
Days:outputs('Date_Difference')?['Days']
Hours:outputs('Date_Difference')?['Hours']
Minutes:outputs('Date_Difference')?['Minutes']
Seconds:outputs('Date_Difference')?['Seconds']
Use these expressions in subsequent actions (like another Compose, a Condition, or Apply to Each) to reference the specific values.
Download my Flow
You can easily copy and paste actions in Power Automate. Allowing you to copy and paste my example.
We have all been there, we need to check the difference between 2 dates, and if you ever had to implement this you would need to use some crazy mathematical equations using the ticks() expression. But now..
I’m not sure when this expression got added, but we can now use dateDifference() expression instead of using ticks().
The dateDifference() expression is a powerful tool in Power Automate and Logic Apps for calculating the difference between two dates.
Allowing to easily determine the number of days, months, or years between two dates, which can be useful in a variety of scenarios.
The result is in the format of: Days.Hours:Minutes:Seconds
Note:: If the dates passed in have no time interval, the result shows zeros for the hours, minutes, and seconds. We can extract the different parts of the return by using some expressions inside a Compose action, which we will do next.
Extracting the Result
If you need to extract certain parts of the result into the hours, minutes, or even seconds, you can use the split() expression. Below you will find the explanation on the extraction, as well as the exact expressions to use.
The split() function splits the output of dateDifference() at the period (‘.’) into an array with two elements: days and the rest (hours:minutes:seconds).
The [0] indexer retrieves the first element of the array, which represents the number of days.
The int() function converts the days from a string to an integer.
If your like me, you test your Flows over and over again. This results in sending unwanted emails, creating items in SharePoint or Dataverse, Creating files on OneDrive or SharePoint. Every time you test your Flow, these actions inside our Flow get executed and cause unwanted behavior when Testing.
Wouldn’t it be nice if we can Test our Flows without executing these actions? Guess what we can! And its very easy to do. Check this out!
Scenario
For example, I have a Flow that Create a new row in Dataverse, and then send an email to the person who created the new row. That is fine, but what happens when we have other actions in our Flow that we want to test to make sure they are correct. I may want to test the Flow multiple times if I am doing some data manipulation, but this will result in Creating multiple unwanted rows (records) in Dataverse, as well as send emails every time.
We can clean up the testing process easily.
How?
We can utilize a feature called Static Result.
First click the 3 dots on the action, and select Static Results.
Next we can configure the static results. For easy example click the radio button to enable, select your Status, and the Status Code.
Click Done.
Now the action will have a yellow beaker, indicating that the action is using Static results.
Things to note: – Static Result are in ‘Preview’ so it could change at any time – Not all actions will be able to use them – If the option is greyed out, and you’re certain the action is able to use it, save the Flow and re open
This is only the beginning, as you can create a custom failed response, or create any result you want. This can help troubleshooting and testing certain scenarios.
REMEMBER!! To turn off static results when you want to execute the actions like normal.
Examples
Some examples on when to use static results:
Flow runs without sending emails
Flow runs without Approvals needed
Flow runs that need to test errors on certain actions
I have used this feature for awhile now, and noticed not many know about it. It’s so useful in many testing scenarios. Just remember to disable the static results once your done testing!
If you have any questions or want to add anything please leave a comment and like this post! Thank you!
You may have run into an issue when creating Power Apps that needs to submit data to SharePoint, Dataverse, etc. But did not want to give everyone in the app access to these. The problem is, Power Apps uses the connections of the user using the app, meaning if the app writes to a SharePoint List, the user will need Read/Write access. The same goes for Power Automate if we try to send the data to Power Automate from Power Apps, it still uses the users connection who triggered the Flow. How can we get around this? Read below!
If you block the HTTP Request connector via data loss prevention (DLP), child flows are also blocked because child flows are implemented using the HTTP connector. Work is underway to separate DLP enforcement for child flows so that they are treated like other cloud flows.
You must create the parent flow and all child flows directly in the same solution. If you import a flow into a solution, you will get unexpected results. Call Child Flows – Power Automate | Microsoft Docs
Prerequisites
The Flows must be created inside the same Solution, so a Dataverse database must be configured on the Power Platform Environment
The Scenario
In this scenario, I will be showing how a user can use Power Apps to create items in a SharePoint List without being a member of the Site. This will allow us to use a specific Service Account to create the data in SharePoint without giving the user in the app any permission at all!
First we will build the Child Flow, then Parent Flow, and lastly customize the Power App
Child Flow
Inside your Solution create a new Cloud Flow.
For our trigger we use a Manual Button, and add the data we are expecting from Power Apps to put inside our SharePoint List (In my example I am only bringing in one field for Title)
Next, I add a Create Item action for my SharePoint List, and add the Parameters from the trigger inside the action.
Lastly, I add a ‘Respond to PowerApp or flow’ action, I create an Output called Success, and some details about what was created.
Child Flow
Make sure to use the Connection you want users of the App to use for the SharePoint Create item action.
Save and go back to the Flow dashboard screen (where you see the Details and run history screen).
There will be a Card on the right side called ‘Run only users’ click Edit
Run only users
Under Connections Used, switch ‘Provided by run-only user’ to the connection you want to be used by users of the App (They wont have access to this Connection outside this Flow)
Run only user
Click Save,
Now onto the Parent Flow
Parent Flow
Go back to the Solution and Create another Cloud Flow.
For our trigger we use the PowerApps button trigger.
As best practice, create Variables for your data that is coming from Power Apps. Don’t forget to name them, as this will be the parameter name in Power Apps, Use the ‘Ask in PowerApps‘ dynamic content for your variable values.
Next we use a action called ‘Run a Child Flow’ (If you do not see this action, your Flow was not created inside a Solution) Add the parameters (these were the input parameters from the last Flow that we just created).
Lastly, add ‘Respond to a PowerApp or flow’ action. For this demo I am adding the parameter ‘Success’ this is from the child Flow.
Click Save.
Power App
Now onto the Power App, I am going to create a simple Power App with 1 TextInput for Title, and a Button to Pass the data to Power Automate. Here are my controls for reference:
TextInput_Title Button_SendToFlow
For the Button: 1. Add the Flow to the button by clicking on the Button, 2. Clicking Action tab on top of page, 3. Clicking Power Automate 4. Select the Flow
Next add the parameters for the Flow, in my case I am adding the TextInput_Title.Text
Now, I want to add a Notification that the Item has been added, which will confirm my Flow has Run correctly. Ill be using the ‘Success’ Output parameter from the Flow for this.
To add this, I put my Flow run inside a Variable inside Power Apps. Ill call my variable Results, and IO add this to the OnSelect property of the Button where my Flow is:
Now I use the ‘Notify’ function to notify the user of the item being created, I add this after the semicolon. So my function looks like this in the end:
Is your Condition not working as expected? The problem is when we use a Condition action inside Power Automate, we cannot see the “equation” that is being evaluated when looking into the run.
The problem affects how we can troubleshoot, the following solution will show what is happening inside the Condition action during the run.
Scenario
In this scenario, I am checking: If one value is greater than a second value
Now during a test run, I expect to see this condition true, but in my run it is always showing false and going in the If no branch.
The big problem is though, I cannot see what the values being evaluated look like. Take a look below
Clicking on the “Show raw inputs” is also not helpful..
Solution
So what is this quick and easy solution to see the condition results? A simple ‘Compose‘ action.
Lets take a look: First add a Compose under your Condition
Next copy the values that are in the Condition to the Compose. My Compose now looks like this:
Now make sure the Compose is above your Condition. I am just dragging the Condition below the Compose
Next, we can run the Flow again, and see what the Compose can tell us:
Yikes! We can see our 2 values that are being evaluated are both 15. And 15 is not greater than 15. This is why its returning false.
My Thoughts
In my opinion, this should be already visible inside the Condition action. To get this feature added to Power Automate, we can vote on this feature. Head over to the Community Forum and vote for this idea.
Flow Alt Delete - Josh Cook [Microsoft MVP] 
