Flow Alt Delete – Josh Cook [Microsoft MVP]

Category: Power Platform

  • Copilot Cowork First Month: How Admins Should Check July Consumption

    Copilot Cowork First Month: How Admins Should Check July Consumption

    The first month of Copilot Cowork is a baseline, not a verdict.

    For Microsoft’s qualifying Frontier grace-period cohort—and for the tenant in this guide—July was the first full billed calendar month of Copilot Cowork consumption.

    But opening one dashboard, copying the big number, and calling it “usage” will give you an incomplete story.

    There are really two questions:

    1. What did Cowork consume?
    2. Are people adopting it in a healthy, valuable way?

    Microsoft answers those questions in two different areas of the Microsoft 365 admin center. The Cost Management report shows Copilot Credit consumption. The Cowork Usage report shows adoption, tasks, activity, and retention.

    They use different definitions, date controls, and refresh cycles.

    This guide walks through both, shows what I found in a real first-month tenant, and gives admins a practical checklist for configuring and reviewing month one.

    Important July context: Copilot Cowork became generally available on June 16, 2026. Tenants with at least one user who used Cowork during the Frontier period from March 30 through June 16 received a billing grace period through June 30, with billing beginning July 1. That makes July the first full billed month for that cohort—not automatically for every tenant. Confirm your own activation and billing dates before labeling July “month one.”

    In this guide

    The two dashboards answer different questions

    Admin viewBest forDate behaviorRefresh behavior
    Copilot > Cost ManagementCredits, limits, policies, users, groups, agents/services, prepaid versus PayGoSupports an exact month such as July 2026Overview refreshes every 4 hours; Consumption refreshes every 2 hours
    Copilot > Cowork > UsageActive users, tasks, scheduled versus user-initiated work, retention, adoption trendsRolling 7, 28, 90, or 180 days; default is 28 daysCheck the report’s visible Last updated timestamp

    That distinction matters. The Cowork Usage report I reviewed on August 5 offered a 28-day range of July 5 through August 2. It did not offer a calendar-month July option. I could use it to understand adoption near the end of July, but I could not honestly present it as an exact July report.

    Cost Management Consumption page with summary cards for users, groups, and agents and services
    Cost Management can report the exact July 2026 consumption period.

    How to check July Copilot Cowork consumption

    1. Start in Cost Management, not the generic Copilot credits report

    In the Microsoft 365 admin center, go to:

    Copilot > Cost Management > Consumption

    For Cowork, this is the useful consumption surface. It lets you move between Users, Groups, and Agents and services.

    Do not confuse it with Reports > Usage > Microsoft 365 Copilot > Credits. That report has a different scope and is not the report I would use to isolate Cowork consumption.

    2. Select July 2026

    Open Time period and select July 2026.

    July month selector
    Use the calendar-month selector in Cost Management when you need an exact July baseline.

    Here is the small trap I saw in the August 5 tenant UI: changing between Users, Groups, and Agents and services reset the time period to Month to date. Re-select July on every view and confirm the label before recording a number or exporting data.

    3. Use Agents and services to isolate Cowork

    Start with Agents and services. This is the cleanest way to separate Cowork from Work IQ API or another consumptive service covered by the same policy.

    Cowork service consumption for July
    The Agents and services view is the best starting point for the Cowork total.

    Record at least:

    • Cowork Credits used
    • Active users
    • Sessions
    • The report period
    • The time and date you captured the report

    That last item is not busywork. Microsoft says the Consumption tab refreshes every two hours, while exported reports are point-in-time snapshots. A dashboard and an export taken at different moments can temporarily disagree.

    4. Review users for concentration and limit pressure

    Move to Users, re-select July, then inspect:

    • Credits used
    • Monthly credit limit
    • Percentage of the limit consumed
    • Sessions
    • Last activity date
    • Assigned spending policy
    • Daily credit usage
    User consumption details with spending policy and monthly limit
    The user drawer connects total usage to the assigned policy, service access, and individual limit.
    Daily user credit usage
    Daily usage shows when concentration occurred. Pair it with Cowork task data or Purview audit evidence before deciding why it occurred.

    Do not just chase the largest user. Ask whether the work was intentional, repeatable, and valuable. A heavy user may be delivering the best ROI in the tenant. The useful signal is high consumption without an understood scenario, owner, or outcome.

    5. Review groups, then re-check the period

    The Groups view helps you compare the audiences targeted by spending policies. It is useful for spotting:

    • One group consuming most of the credits
    • A group with low consumption after you compare the Consumption view with its enabled scope under Configuration
    • A pilot team whose limits are too low for its intended workload
    • Overlapping memberships that make policy behavior harder to explain
    July consumption by group
    Group totals help admins compare the audiences governed by different spending policies.

    User and group totals do not always match perfectly. Users can belong to multiple groups and policies, and policy changes during a billing period can affect what appears at user level. Treat these views as different analytical cuts, then reconcile material differences against exports and policy history.

    6. Check the July spending trend separately

    Return to Cost Management > Overview and set the Spending trend card to July.

    July cumulative spending trend
    The Spending trend card has its own period control. Do not assume the page-level cards and chart are showing the same month.

    Look for:

    • Large daily spikes
    • A steady upward ramp after enablement
    • Weekend spikes to compare with scheduled-task history
    • A shift from prepaid capacity into PayGo
    • A sudden drop that coincides with a limit or access change

    In the tenant reviewed for this guide, July was spiky rather than smooth. The largest single day used more than 12,000 credits, while several days were below 1,000. That is a prompt to investigate which scenarios or scheduled tasks ran on the high days—not proof that the spikes were waste.

    What the first full month looked like in this tenant

    The following numbers are an anonymized, point-in-time snapshot captured on August 5, 2026.

    Exact July consumption

    • 136,956 Cowork Credits in the Agents and services view
    • 19 active Cowork users in that service view
    • 260 sessions across the user rows
    • 18 users with non-zero recorded credits at capture time
    • 6,150 median credits across the 19 user rows
    • 7,208 average credits across the 19 user rows
    • 526.7 credits per session across the user rows
    • The largest user represented 22.0% of user-level credits
    • The top five users represented 59.8% of user-level credits
    • 6 users had consumed at least half of their individual limit
    • 0 users had consumed 80% or more of their individual limit

    The service, group, user, and trend views differed by a few hundred credits at capture time: roughly two-tenths of one percent. That is small enough to be consistent with refresh timing and aggregation differences, but it should still be documented. Use one defined source for the headline number—here, the Cowork row under Agents and services—and preserve exports when you close the month.

    Do not turn credits directly into an invoice unless you know the billing path

    Microsoft lists PayGo at $0.01 USD per Copilot Credit. At pure retail PayGo, 136,956 credits would be a $1,369.56 USD usage equivalent.

    That is not automatically the tenant’s invoice. This tenant’s policies used prepaid capacity. When capacity packs and a subscription with P3/pay-as-you-go are both selected, Microsoft documents the order as capacity packs first, then P3 prepaid credits, then PayGo. Discounts, prepaid commitments, shared capacity, and billing arrangements can all change the actual cost. Report credits and billing source together.

    Now check adoption—but label the date range honestly

    Go to:

    Copilot > Cowork > Usage

    Cowork Usage rolling date selector
    Cowork Usage uses rolling ranges. The 28-day view here covers July 5 through August 2, not calendar July.

    The report’s four headline metrics are:

    • Active Cowork users
    • Total Cowork tasks
    • Average tasks per active user
    • Retained Cowork users
    Cowork adoption cards
    Always capture the date range and Last updated timestamp with the headline metrics.

    Microsoft defines a task as one Cowork conversation thread, including user-initiated conversations and scheduled task executions. Follow-up questions in the same thread remain part of the same task.

    The same report defines a retained user as someone active in both the previous seven-day period and the most recent seven-day period. It is a useful continuity signal, but it is not a conventional month-over-month cohort retention rate.

    Microsoft's task definition in the report
    A task is not the same thing as a prompt, run, or Cost Management session.

    The report was viewed on August 5 and displayed Last updated: August 3. For the rolling 28 days from July 5 through August 2, this tenant showed:

    • 18 active users
    • 332 total tasks
    • 18.44 average tasks per active user
    • 18 retained users
    • 103 user-initiated tasks
    • 229 scheduled tasks

    That means about 69% of tasks were scheduled. It is a valuable operational signal: Cowork was being used as automation, not only as a conversational tool.

    Daily active users and task mix
    Read daily active users beside the task-type mix to understand how engagement is occurring.
    Scheduled and user-initiated task trend
    The late-July scheduled-task increase deserves a scenario-level review before changing limits.

    But the average hid a highly concentrated pattern: one user accounted for 206 of the 332 tasks, or about 62%. The median active user had only 6 tasks. Fifteen users were active on two days or fewer.

    This does not mean the rollout failed. It means the first-month story is a scheduled-heavy tenant and a highly concentrated user-level pattern, plus a low-frequency long tail. Month two should validate the dominant user’s scenarios while improving repeat, intentional use across the rest of the pilot.

    The first-month admin playbook

    Days 1–3: Prove the plumbing

    • Confirm each intended user has a Microsoft 365 Copilot license.
    • Confirm usage-based billing is enabled and tied to the correct subscription or prepaid capacity.
    • Confirm Cowork is discoverable to the intended audience.
    • Confirm the intended security groups are assigned to an active spending policy.
    • Run a controlled task and verify it appears after each report updates. Use the visible Last updated timestamp for Cowork Usage and allow for Cost Management’s documented refresh window.
    • Capture the initial policy, billing method, and access configuration before changing anything.

    Discoverability and access are separate controls. The discovery setting controls tenant-wide visibility, while Cost Management controls scoped access and spend. Microsoft says usage-based billing setup overrides the discovery setting for users covered by that setup, so validate both the tenant-wide experience and the intended scoped audience.

    Week 1: Establish safe limits and alerts

    Start with group-based policies that match the rollout audiences. A practical pilot configuration should include:

    • A policy-level monthly cap
    • A per-user monthly cap
    • Alerts well before the hard cap
    • Named operational and financial owners for those alerts
    • Explicit agents and services included in the policy
    • A documented billing method

    Also make an explicit decision about Allow new services and agents as they become available. Microsoft’s current policy setup selects that option by default. That can be convenient, but a controlled pilot should not inherit future service access without an owner and review process.

    Spending policies impose access and consumption limits; they do not reserve or allocate a slice of the underlying Copilot Credit capacity to a group. Treat policy limits as guardrails, not as capacity reservations.

    Policy precedence warning and configuration
    When multiple policies apply, Microsoft enforces the most permissive applicable policy; settings are not combined.

    Microsoft’s current precedence order for overlapping policies is:

    1. Highest per-user limit
    2. If tied, highest overall policy limit
    3. If still tied, newest policy

    That is easy to get wrong. Adding a “special” policy can accidentally make someone less restricted than intended.

    Monthly hard-cap behavior
    A hard cap blocks covered services for the rest of the month and resets on the first day of the next month.
    Policy alert threshold
    Set an early threshold so an alert creates time to investigate instead of merely announcing that the budget is gone.
    Per-user monthly cap
    Per-user caps protect a shared policy from one runaway or misunderstood workload.

    When the run rate is unknown, I start the first alert at 50%. Once you understand the run rate, use multiple operational checkpoints outside the platform—such as weekly reviews at 50%, 70%, and 85%—even if the product sends a single configured alert threshold.

    Use least privilege for the operating team. AI Administrators and License Administrators can create spending policies, manage limits and alerts, and view Cost Management. Selecting or overriding the billing method requires a Global Administrator or Billing Administrator. After a spending policy is created, its billing method cannot be changed; Microsoft requires deleting and recreating that policy.

    Week 2: Review adoption, not just activation

    Ask five questions:

    1. How many targeted users became active through a direct prompt or a scheduled execution?
    2. How many came back in the next seven-day period?
    3. Is work primarily user-initiated or scheduled?
    4. Is usage concentrated in one person, team, or scenario?
    5. Which enabled users have no visible activity and need a use case, training, or removal from the pilot?

    The Usage table lists people with Cowork activity dating back to April 1, 2026, while its summary cards respond to the selected rolling period. Do not use the total table row count as your active-user count. Also remember that an active user can be counted because they prompted Cowork or because a scheduled task executed on their behalf. Active-user coverage is not identical to direct human adoption.

    Week 3: Connect consumption to scenarios

    For the top users and largest days, document:

    • Business scenario
    • Owner
    • Frequency
    • User-initiated or scheduled
    • Inputs and data sources
    • Outputs and downstream actions
    • Credits consumed
    • Time saved or risk reduced
    • Whether a lower-cost model or tighter scope can produce an acceptable result

    Consumption alone is not value. A 5,000-credit task that replaces two days of expert work may be excellent. A 500-credit task running every hour with nobody reading the output may not be.

    Week 4: Freeze the baseline and decide month two

    • Re-select the exact July period in every Cost Management view.
    • Export users, groups, and agents/services after the reporting refresh.
    • Record the Cowork Usage rolling range and Last updated timestamp.
    • Preserve policy settings and group membership as of month-end.
    • Explain material differences between views.
    • Review users near limits and compare the configured audience with users showing no repeat activity.
    • Classify scheduled tasks as keep, tune, pause, or investigate.
    • Set month-two targets before raising budgets.

    The metrics I would put on an admin scorecard

    MetricFormulaWhat it tells you
    Active coverageActive users ÷ enabled target usersHow much of the intended audience generated direct or scheduled activity
    Retained-to-active ratioRetained users ÷ active usersA simple continuity signal, not a conventional cohort-retention rate; retained users compare the two most recent seven-day periods while active users cover the selected range
    Scheduled-task shareScheduled tasks ÷ total tasksHow much usage is recurring automation versus direct interaction
    Credits per active userCowork credits ÷ active usersOverall consumption intensity when the periods align
    Credits per sessionCowork credits ÷ Cost Management sessionsRelative session intensity within the consumption report
    Limit utilizationCredits used ÷ applicable policy limitHow close a user or policy is to its cap; the limit does not reserve underlying capacity
    Top-five concentrationCredits from top five users ÷ total user creditsWhether the rollout depends on a few users
    Average-to-median gapAverage usage compared with median usageWhether a small number of heavy users are distorting the average

    Only combine figures whose date ranges and definitions match. A Cowork task is not a Cost Management session. In this review, the adoption report covered July 5 through August 2 while the consumption report covered July 1 through July 31, so I did not calculate credits per task.

    Month-one red flags worth investigating

    • A view silently returned to Month to date after you changed tabs.
    • The Overview headline cards and Spending trend chart are showing different periods.
    • A user or group is above 80% of its cap with time left in the month.
    • Scheduled work dominates consumption but has no named owner or reviewed output.
    • Average usage is high while median usage is low.
    • A service other than Cowork is consuming credits under the same policy.
    • A group has access but almost no activity.
    • A spending policy includes new services automatically without a review process.
    • Several groups overlap, producing a more permissive policy than expected.
    • Finance is treating credits multiplied by retail PayGo as the invoice even though prepaid capacity or P3 applies.
    • Security assumes all Microsoft Purview controls apply identically to Cowork. As of this writing, Microsoft documents DLP for general Cowork AI interactions as unsupported, even though auditing, sensitivity labels, eDiscovery, data lifecycle, communication compliance, and other controls have documented support. Cowork’s local Edge browser tasks are narrower: Microsoft says they inherit existing browser DLP, Conditional Access, and site policies. Review both control paths rather than inheriting assumptions from another Copilot surface.

    What I would change for month two

    For this tenant, I would not start by cutting the heavy user or scheduled workload. I would first confirm whether that automation is producing a real business outcome. If it is, preserve it and establish an owner, expected run rate, and value measure.

    Then I would:

    1. Create a repeat-use goal for the low-activity users.
    2. Review the five largest credit consumers and the largest daily spikes.
    3. Audit scheduled tasks for frequency, duplicate runs, and unused output.
    4. Separate Cowork and Work IQ API policy reporting wherever the rollout design allows it.
    5. Keep alerts early enough to react before a hard cap blocks work.
    6. Raise limits only for a documented scenario with evidence of value.
    7. Review plugins, model availability, browser use, audit coverage, and Purview support as part of the same operating rhythm—not as a one-time launch checklist.

    Final thought

    The goal of month one is not to prove that every user became a power user. It is to leave with a trustworthy baseline: who used Cowork, what they ran, what it consumed, which work repeated, and which controls need to change next.

    That is the admin story July can tell—if you use both dashboards and keep their definitions straight.

    Sources

  • GPT-5.6 Is Missing in Copilot Cowork? Turn On This Admin Setting

    GPT-5.6 Is Missing in Copilot Cowork? Turn On This Admin Setting

    GPT-5.6 is available in Copilot Cowork.

    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.

    Copilot Cowork model picker before GPT-5.6 models are enabled
    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:

    1. Open Copilot.
    2. Select Settings.
    3. Select View all.
    4. Open AI providers operating as Microsoft subprocessors.
    Microsoft 365 admin center Copilot settings showing 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 subprocessor access settings in the Microsoft 365 admin center
    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.
    Copilot Cowork model picker showing GPT 5.6 Sol and GPT 5.6 Terra
    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.

    Sources

  • Copilot Cowork Browser Use

    Copilot Cowork Browser Use

    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:

    1. Open Copilot
    2. Select Settings
    3. Select View all
    4. Find Cowork
    5. Turn on Allow browser access
    6. 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.

  • Copilot Cowork Billing Setup: Turn On GA Without Opening the Credit Floodgates

    Copilot Cowork Billing Setup: Turn On GA Without Opening the Credit Floodgates

    Copilot Cowork is generally available.

    That is the headline.

    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.

    Microsoft 365 admin center Cost management page showing Copilot Cowork and Work IQ API usage-based billing
    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.

    Billing method options for Copilot Credits showing Capacity Packs and pay-as-you-go subscription
    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.

    Power Platform admin center Capacity add-ons page showing Microsoft Copilot Studio messages allocated from a 50,000 credit pool
    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.

    Microsoft 365 admin center security group creation screen with the name Copilot Cowork Access
    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.

    Cost Management access group configuration scoped to specific security groups
    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:

    1. Confirm the admin roles needed for billing and policy management.
    2. Review existing Copilot Credit usage in Microsoft 365 and Power Platform.
    3. Choose the billing method with the billing owner involved.
    4. Create a bounded monthly spending policy.
    5. Add a per-user limit for the pilot group.
    6. Set alerts before the policy limit is reached.
    7. Create a security group for pilot access.
    8. Add a small number of serious users.
    9. Monitor usage and identify what tasks burn credits.
    10. 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.

    Sources

  • Copilot Cowork Dataverse Plugin Setup

    Copilot Cowork Dataverse Plugin Setup

    I finally got Dataverse MCP working inside Copilot Cowork as a custom plugin.

    This guide walks through the setup in a way I wish I had when I started.

    The goal is simple:

    • Register an app in Entra
    • Enable Dataverse MCP for your Power Platform environment
    • Create the OAuth registration in Teams Developer Portal
    • Build a Copilot Cowork plugin that points to your Dataverse MCP endpoint
    • Deploy it
    • Give Cowork enough schema context to understand your Dataverse tables

    If you are a low-code builder, the confusing part is not Dataverse.

    The confusing part is the setup across multiple portals.

    You will touch Entra, Power Platform admin center, Teams Developer Portal, the plugin manifest, and Copilot Cowork.

    That sounds worse than it is. You just need to know which value goes where.

    I have a video going over the same steps as the blog:

    What we are building

    We are building a Copilot Cowork plugin that connects to the Dataverse MCP endpoint.

    Once installed, Cowork can use that plugin to query Dataverse through MCP.

    The basic flow looks like this:

    1. User asks Copilot Cowork a question
    2. Cowork uses the custom plugin
    3. The plugin points to the Dataverse MCP endpoint
    4. Dataverse returns the data
    5. Cowork uses schema guidance to make sense of the tables
    6. Cowork returns a useful answer, summary, dashboard, or audit notes

    I recommend keeping this setup in two parts:

    • The plugin: gives Cowork access to the Dataverse MCP connector
    • The schema skill: tells Cowork which Dataverse tables, columns, relationships, and rules matter

    That split makes the setup easier to maintain.

    If your schema changes, you can update the schema skill without rebuilding and redeploying the entire plugin package.

    Before you start

    You will need:

    I created a checklist for this because the setup has a few values that are easy to mix up.

    The setup order

    This is the order I recommend:

    1. Create the App Registration
    2. Configure the Power Platform environment
    3. Create the OAuth registration in Developer Portal
    4. Build the plugin
    5. Deploy the plugin
    6. Create the schema skill
    7. Test everything in Copilot Cowork

    Do not start with the plugin manifest.

    Get the identity, environment, and OAuth pieces ready first. The manifest is much easier once you already have the right values.

    Step 1: Create the App Registration

    Start in Microsoft Entra.
    https://entra.microsoft.com/

    Create an app registration that will be used for the Dataverse MCP connection.

    Capture these values:

    • Tenant ID
    • Application / Client ID
    • Client secret
    • Secret expiry date

    You will use the Client ID more than once, so copy it somewhere safe.

    Add the Dataverse MCP permission

    In the app registration, add the required API permission for Dataverse MCP.

    1. Open the app registration
    2. Go to API permissions
    3. Select Add a permission
    4. Select Microsoft APIs
    5. Select Dynamics CRM
    6. Add the permission:
    mcp.tools

    Grant admin consent if your tenant requires it.

    Add the redirect URI

    1. For the OAuth flow, add this redirect URI if your setup requires it:
    https://teams.microsoft.com/api/platform/v1.0/oAuthRedirect

    Important: the Application / Client ID is not the same as the OAuth registration ID you will create later.

    Keep those two values separate.

    Step 2: Configure the Power Platform environment

    Next, configure the Power Platform environment that contains your Dataverse data.

    You need the Dataverse environment to allow MCP clients.

    Open Power Platform admin center and go to the target environment.

    1. Open Power Platform admin center
    2. Go to Manage
    3. Select Environments
    4. Open your target environment
    5. Open Settings
    6. Go to Product
    7. Open Features
    8. Find the Dataverse MCP setting
    9. Allow MCP clients to interact with Dataverse MCP server
    10. Only check the GA version of the MCP server > Click Save

    The exact wording may change because this area is still moving, but the goal is the same: allow MCP clients for that environment

    Add the allowed MCP client

    Now add your Entra Application / Client ID as an allowed MCP client for the environment.

    1. Click “Go to Advanced Settings” link under Step 2
    2. Click +New > fill in the details like this:
      – Name: Cowork Dataverse MCP – <env name>
      – Unique Name: new_CoworkDataverseMCP<envName>
      – Application Id: Paste your application Id from the App Registration you created in section 1
      – Is Enabled: Yes
    3. Click Save & Close

    That part matters.

    The value you add here is the Entra Application / Client ID.

    Also make sure the allowed MCP client is enabled.

    If this step is wrong, the plugin can look fine but still fail when Cowork tries to use Dataverse.

    Before leaving the admin center, grab the Environment URL.

    Capture the Dataverse URL

    You need your Dataverse Org URL

    It looks like this:

    https://yourorg.crm.dynamics.com

    The MCP server URL is the same URL with /api/mcp added to the end.

    https://yourorg.crm.dynamics.com/api/mcp

    Step 3: Create the OAuth registration in Teams Developer Portal

    Now open Teams Developer Portal.
    ( https://dev.teams.microsoft.com/ )

    Create an OAuth client registration for the plugin.

    This registration stores the OAuth configuration and gives you the OAuth registration ID that your plugin manifest will reference.

    In the OAuth registration, you will enter values from the Entra app and your Dataverse environment.

    1. Click Tools > OAuth client registration
    2. + New OAuth client registration

    Base URL

    Use your Power Platform Environment URL

    https://<yourorg>.crm.dynamics.com

    Restrict usage by Teams app: select Any Teams app (for now, since we don’t have a Teams app ID yet)

    Authorization endpoint

    Use your Tenant ID in this format:

    https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/authorize

    Token endpoint

    Use your Tenant ID in this format:

    https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token

    Scope

    The scope should use your Dataverse Org URL.

    Use this format:

    https://yourorg.crm.dynamics.com/.default offline_access

    Example:

    https://kavoracrm.crm.dynamics.com/.default offline_access

    Client ID and secret

    Use the Client ID and secret from the Entra app registration you created earlier.

    After saving the OAuth registration, copy the OAuth registration ID.

    You will use that value in the plugin manifest as the connector referenceId.

    Important: the OAuth registration ID goes into the plugin manifest.

    Step 4: Build the plugin

    For this approach, the plugin should stay focused on the Dataverse MCP connector.

    To make this even easier, I created a Cowork-Plugin skill to assist in building the Plugin with a template.

    Import Plugin Builder skill

    1. Download my /cowork-plugin-builder skill
    2. In Copilot Cowork > attach the skill and prompt: Add this skill
    3. After import refresh your browser

    Build Dataverse Plugin with Template

    We will use the skill you just imported to help build the plugin.

    1. Inside Copilot Cowork craft a prompt and add the cowork-plugin-builder skill
    2. Add these details or Copilot Cowork will ask you for these values
      (NOTE: If your using the Checklist app I created to track progress, click the Copy setup summary. Paste this into the prompt as well)

    Prompt to use:

    /cowork-plugin-builder to build a Dataverse plugin using this template:‌
    Organization name: 
    Connector display name: 
    description: 
    Tenant ID: 
    Client ID: 
    Org URL:
    MCP URL:
    OAuth registration ID:
    OAuth scope: 
    Connector referenceId:

    Fill in everything you can.

    I created a Dataverse-style icon with a Cowork badge so the plugin is easy to recognize when it appears in Cowork.
    (Included in the template)

    When Copilot Cowork is done, you should receive a zip file.

    Download the zip file.

    Step 5: Deploy the plugin

    After the package is ready, deploy it to a test user or test group first.

    1. M365 Admin Center > Agents > All agents > Upload custom app > pick dataverse-<pluginname>.zip
    2. Publish to users: add yourself first
    3. Install (optional): add yourself so it auto-appears
    4. Accept permissions > Review & finish
    • Apply Template (default should be fine)
    • Review Permissions (should be none, since permissions are done through the App registration)
    • Publish

    Keep the first deployment small.

    Connect Plugin

    1. Open a fresh Copilot Cowork session
    2. Click + > Manage Plugins
    3. Click … Browse Plugins
    4. Find the Plugin > Click Add
    5. Scroll down and click Connect

    Start with a simple prompt like this:

    Use the <Plugin name> to confirm you can access the Dataverse MCP server.

    Important: when you change the plugin package, update the version before uploading again.

    Also start a fresh Cowork session after deployment changes.

    Otherwise, you can end up testing against a stale session and thinking the plugin is broken.

    Step 6: Create a schema-aware skill

    This is the step that makes the plugin more useful.

    The plugin gives Cowork access to Dataverse.

    The schema skill helps Cowork understand what to do with that access.

    In the schema skill, give Cowork the details it needs to query your model properly.

    • Table logical names
    • Table purpose
    • Primary columns
    • Lookup columns
    • Relationships between tables
    • Status fields
    • Rules for what matters
    • Data-quality checks
    • Example prompts

    We can use this skill to create a personal skill to query certain tables, etc.

    In the example, I ask Copilot Cowork what tables are used in a certain Model-Driven App.
    Prompt:

    What tables are apart of Kavora Equipment Hub
    /dataverse-schema-

    Copilot Cowork responds with a tables and logical names.
    Next I ask for all the logical columns for those tables.
    (NOTE: This will help Copilot Cowork query your data quicker)

    My follow-up prompt:

    Yes pull all logical columns.
    I want to build a skill around these tables and data.
    Name the Skill Kavora Equipment IQ

    Then Copilot Cowork drafted the skill for me.
    I reviewed it and said “Looks good”

    Copilot Cowork built the skill

    Step 7: Test with a real scenario

    Now run an actual test.

    Do not only ask Cowork to connect.

    Ask it to use the Dataverse model.

    A good test should include:

    • One known record
    • At least one related table
    • At least one lookup relationship
    • Some output Cowork needs to organize
    • A data-quality check or business rule

    Example prompts:

    List records

    use /<skill you just built>
    List all the  <table>

    Add records

    use /<skill you just built>
    can you add 3 more <assets>
    1. Blue Yeti mic, Regional Office, value (you look this up in USD)‌
    2. Red dragon Keyboard (RGB), lookup value, put in the HQ
    3. Surface Arc Mouse, lookup price, put in HQ

    Details on a record

    use /<skill you just built>
    list all the <table> who  <condition>

    Build Dashboard

    use /<skill you just built>
    give me a full dashboard of <record>.
    Surface all details relating to <record>

    Create report

    use /<skill you just built>
    now create a report with each <Employee>
    on what they have left VS what they have used for budget

    Send Email with context

    use /<skill you just built>
    Email <James chen> asking about the <assets>

    Create PPT with context + Brand

    (NOTE: the branding is a separate skill not included in the plugin)

    use /<skill you just built>
    Now put this information inside a PPT
    using </branding-skill> for Kavora branding.
    This PPT is for Kavora Executives.
    Make it look polished with graphs and charts and pop.

    This is where the setup starts paying off.

    Cowork can query the data, follow relationships, and return a useful answer instead of forcing you to manually pull everything together.

    Common mistakes

    Mistake 1: Mixing up the IDs

    There are two important IDs:

    • Entra Application / Client ID: used in Power Platform as the allowed MCP client
    • OAuth Registration ID: used in the plugin manifest as the referenceId

    If you paste the wrong one in the wrong place, the setup will fail.

    Mistake 2: Wrong MCP URL

    The MCP URL should look like this:

    https://yourorg.crm.dynamics.com/api/mcp

    Watch for missing /api/mcp.

    Mistake 3: Wrong OAuth scope

    The scope should use your Dataverse Org URL:

    https://yourorg.crm.dynamics.com/.default offline_access

    Mistake 4: Testing with a user that cannot access the data

    Make sure the user testing the plugin has access to the Dataverse tables you are querying.

    Mistake 5: Re-uploading the same version

    If you change the package, update the version number before uploading again.

    Download the checklist

    I built a simple HTML checklist for this setup.

    It lets you track the values, check off steps, auto-fill the scope from your Dataverse URL, and generate the connector snippet.

    Download the Dataverse MCP Connector for Copilot Cowork setup checklist

    Official docs

    Final take

    NOTE: When you have tested and validated you can connect to Dataverse. You will want to add the Teams App ID from the Agent Plugin we deployed and add it to the Teams Developer OAuth Registration.

    1. Go to Teams Admin center > Teams apps > Manage apps
    2. Find your Plugin you deployed > Copy the App ID
    3. Go back to Teams Developer Portal and open the OAuth registration tool that was created
    4. Paste the App ID into the “Restrict usage by Teams app” field as an Existing Teams app

    This setup is still early, and there are rough edges.

    But once it works, the direction is obvious.

    Dataverse already has the business model.

    Copilot Cowork gives users a work surface.

    The MCP connector connects the two.

    Add a schema-aware skill, and Cowork can start working through real Dataverse data in a way that feels practical for actual business scenarios.

    That is the part worth paying attention to.

    Let me know what other Plugins you want to see in Copilot Cowork.

  • Copilot Cowork to Prep for a Board Meeting Under Pressure

    Copilot Cowork to Prep for a Board Meeting Under Pressure

    How Executives Can Use Copilot Cowork When Board Prep Turns Into a Fire Drill

    A board meeting gets moved up by 48 hours.

    Now the executive needs the story fast.

    Finance has numbers. Operations has risks. Strategy has updates. AI transformation has progress, blockers, and governance questions. The deck is not ready. The briefing memo is not ready. The board will still expect clear answers.

    That is exactly the kind of pressure where Copilot Cowork starts to make sense.

    For this scenario, I used a fictional company called Kavora Industries. I stepped into the role of Chief Strategy Officer, and the ask was simple: prepare a board-ready package under pressure.

    The company is fictional. The work pattern is very real.

    Executive takeaway: Copilot Cowork is strongest when it helps leaders turn scattered business context into decision-ready artifacts.

    Insert screenshot here: Cowork prompt asking for the board meeting briefing package.

    The Real Executive Problem

    Board prep is not just about creating a PowerPoint deck.

    The harder part is knowing what matters.

    What changed since the last update? Where are the risks? Which numbers are final and which are preliminary? What decisions does the board need to make? What questions are they likely to ask?

    That is where executive prep gets expensive.

    The information already exists, but it is spread across too many places:

    • Executive emails
    • Strategy notes
    • Finance workbooks
    • Leadership updates
    • AI transformation reports
    • Draft presentation content
    • Q&A notes

    An executive does not need another place to search. They need the scattered pieces pulled into one clean operating picture.

    The Cowork Approach

    I gave Copilot Cowork a focused executive task:

    Prepare for a board meeting that was moved up by 48 hours using the provided source material, then create the artifacts needed to walk into the meeting prepared.

    The Prompt

    The prompt followed a simple structure:

    Role:
    Act as my executive strategy assistant for Kavora Industries.
    Goal:
    Help me prepare for a board meeting that was moved up by 48 hours.
    Sources:
    Use the provided executive emails, strategy notes, finance workbook,
    AI transformation report, and leadership updates.
    Task:
    Create a board-ready briefing package that includes:
    1. Executive summary
    2. Key risks and decisions
    3. AI transformation progress
    4. Financial and operational issues
    5. Likely board questions
    6. Recommended talking points
    Outputs:
    - Create a Word briefing memo
    - a PowerPoint board deck
    - a Q&A prep sheet
    Guardrails:
    - Keep the tone executive-ready, concise, factual, and decision-focused.
    - Do not invent facts outside the source material.
    - Use Kavora branding when creating files.

    This is the part executives should pay attention to.

    The prompt is not asking Cowork for a generic answer. It assigns a job. It points Cowork at the source material. It defines the output. It adds guardrails. It asks for files the business can actually use.

    The move: Do not ask for a summary when the real need is a briefing package. Ask for the work product.

    Insert screenshot here: Cowork task progress showing the memo, deck, and Q&A prep sheet being created.

    What Copilot Cowork Created

    Cowork created three core board prep artifacts and packaged them into a reviewable executive workflow.

    1. Board Briefing Memo

    The briefing memo became the anchor document.

    It pulled the scattered business context into a single executive narrative: current state, key numbers, strategic signals, risks, and decisions needed.

    This matters because executives need more than information. They need the story behind the information.

    The memo made the situation easier to review, challenge, and sharpen before the board meeting.

    2. Board Deck

    Cowork also created the board deck.

    The deck organized the material into a board-level flow: performance, division signals, risks, AI transformation progress, and decisions requested from the board.

    The important part was not just that slides were created. The important part was that the slides were structured around the meeting the executive actually needed to lead.

    One slide showed division performance and risk signals. Another brought the board back to the required decisions.

    That is exactly what an executive needs. Less noise. Clearer framing. Decisions visible.

    3. Board Q&A Prep Sheet

    This was the strongest artifact in the workflow.

    Cowork created a Q&A prep sheet with likely board questions, direct answers, anchor phrases, and source references.

    That is real executive value.

    The board is going to ask sharper questions than the internal team. Preparing for those questions before the meeting changes how the executive shows up.

    Instead of walking in with slides only, the executive walks in with prepared answers.

    4. Executive Review Email

    I prompted Cowork to also prepare and send an email with the board packet attached.

    Work does not end when the file is created. The package still needs to move to the right people with the right context.

    The email summarized what was included, called out the wording discipline applied, and highlighted the decision priority order.

    That is a complete workflow: source material to artifacts to communication.

    The executive shift: Cowork gets the leader to the decision point faster, with better context and real artifacts already in motion.

    That is the agent boss pattern in practice.

    The human stays accountable. The agent does the heavy lifting around gathering, synthesis, drafting, formatting, and first-pass artifact creation.

    That is how an executive should think about Copilot Cowork.

    The Executive Workflow

    This board prep scenario follows a workflow executives can reuse:

    1. Define the pressure moment.
    2. Point Cowork at the right source material.
    3. Ask for decision-ready artifacts.
    4. Review the output like an executive.
    5. Tighten the narrative.
    6. Send the right package to the right people.

    That workflow applies beyond board meetings.

    You could use the same pattern for quarterly business reviews, operating reviews, customer escalations, strategy offsites, town halls, finance reviews, and AI transformation steering committees.

    The structure stays the same. Pressure, sources, task, outputs, guardrails, review.

    What I Like About This Scenario

    This scenario works because it feels like real executive pressure.

    No gimmick. No fake magic. No perfect blank-page setup.

    Just a leader with scattered information, limited time, and a meeting that requires clear judgment.

    That is where AI at work becomes useful.

    Not when it sounds impressive in a chat window. When it produces the memo, the deck, the Q&A sheet, and the email that move the work forward.

    Best use case: Use Copilot Cowork to reduce the cost of preparation, then spend your human time on judgment.

    Final Thought

    Executives do not need AI that only sounds smart.

    They need AI that helps them get ready.

    That means finding the signal, organizing the story, creating the artifacts, and helping the leader walk into the room prepared.

    This is where Copilot Cowork gets practical.

    Board prep under pressure is not a productivity trick. It is a clear example of how executives can start working differently with AI agents inside the flow of work.

  • Copilot Cowork Is Coming: Here’s How to Get Your Tenant Ready on Day 1

    Copilot Cowork Is Coming: Here’s How to Get Your Tenant Ready on Day 1

    Get Your Tenant Ready for Day 1: Joining Microsoft 365 Frontier for Copilot Cowork

    If you’ve been following the buzz around Copilot Cowork, you already know it’s going to change how we work inside Microsoft 365. But here’s the thing — Day 1 readiness doesn’t happen on Day 1. It happens now.

    In this post, I’ll walk you through exactly how to get your tenant set up: the right licenses, how to join the Frontier program, enabling the Anthropic sub-processor, configuring pilot groups, and locking down governance before you open the floodgates.

    Copilot Cowork is expected to be available for Frontier customers late March or later.

    Step 1: Make Sure You Have the Right Licenses

    Before you can enable anything, your tenant needs the right foundation.

    RequirementDetails
    Microsoft 365 Copilot licenseRequired for all end users who will access Copilot Cowork. Available as an add-on on E3, E5, Business Standard, and Business Premium plans.
    AI Administrator roleRequired to make changes in the Copilot settings area of the Admin Center.
    Microsoft Entra ID P1 or P2Needed for group-based access control and conditional access (P1 minimum).
    SharePoint OnlineIncluded in most M365 plans — required for Cowork’s document grounding.

    Admin tip: Before you go further, run a license audit. In the Microsoft 365 Admin Center, go to Billing > Licenses and confirm Copilot licenses are assigned — unassigned licenses won’t show up in Frontier eligibility checks.

    Step 2: Join Microsoft 365 Frontier

    Microsoft 365 Frontier is the early adopter program that gives your tenant access to upcoming Copilot features before general availability — including Copilot Cowork.

    What you’ll need first

    You must have AI Administrator access to complete this setup. If you don’t have this role, work with your Global Admin to get it assigned before you start.

    How to join Frontier

    1. Start from office.com and open the Admin Center.
    2. Navigate to Copilot → Settings → Frontier.
    3. On the Frontier settings page, enable early access.
    4. Under Web Apps, select the users who should be included.
    5. Click Save.

    That’s it — your tenant is now enrolled in Frontier.

    Step 3: Enable Anthropic as an AI Provider

    After Frontier is enabled, you need to turn on the AI providers that power the new Copilot experiences. This is the step most admins don’t realize is required.

    How to enable Anthropic

    1. From the same Copilot settings area, navigate to Data access.
    2. Enable the available AI providers — the recommendation is to enable as many as possible.
    3. Specifically, find Anthropic and enable it for Copilot.

    Step 4: Set Up Pilot Groups (Optional)

    Don’t roll Frontier out to your entire organization on Day 1. A phased pilot protects your environment and gives you time to validate the experience before broad deployment.

    Recommended pilot structure

    PhaseGroupPurpose
    Wave 1 — Champions5–10 power users (IT, Copilot champions)Validate setup, surface issues early
    Wave 2 — Early Adopters50–100 users across key departmentsReal-world workflow testing
    Wave 3 — Broad RolloutAll licensed usersFull deployment

    How to configure

    1. Create security groups in Microsoft Entra ID — for example, SG-CopilotCowork-Wave1 and SG-CopilotCowork-Wave2.
    2. In the Frontier settings from Step 2, assign early access to your Wave 1 group first using the Web Apps user selection.
    3. Expand to Wave 2 once Wave 1 has validated the experience.

    Pro tip: Set up a Microsoft Teams channel for your pilot group — something like #cowork-pilot-feedback — so you have a central place to collect issues and wins before you scale.

    Step 5: Governance — Lock Down Oversharing Before You Start

    This is the step most organizations skip — and regret. When Copilot can surface content from across your tenant, oversharing becomes a data exposure risk, not just a governance annoyance. Lock this down before you enable Cowork broadly.

    Key controls to review

    ControlWhere to set itRecommendation
    External sharingSharePoint Admin Center → Policies → SharingSet to “Existing guests only” or “Only people in your org” during Frontier rollout
    Default sharing linksSharePoint Admin Center → Policies → SharingChange from “Anyone with the link” to “People in your organization”
    Site-level permissionsIndividual site settingsAudit “Everyone except external users” — this is the #1 oversharing culprit
    Sensitivity labelsMicrosoft PurviewApply labels to classify and restrict access to confidential content
    Guest access expirationEntra ID → External collaboration settingsSet guest access to expire after 90 days

    SharePoint Admin Agent Prompt: Oversharing Audit

    Use this prompt directly with the SharePoint Admin agent in the Microsoft 365 Admin Center to get a fast, prioritized oversharing assessment:

    Review my SharePoint environment for oversharing risks before a Copilot rollout. Specifically:
1. Identify all sites that have 'Everyone' or 'Everyone except external users' granted any level of access.
 2. List sites where external sharing is enabled but shouldn't be (e.g., HR, Finance, Legal).
 3. Show me any files or folders shared via 'Anyone with the link' in the last 90 days.
 4. Flag any sites with more than 500 unique permissions (permission explosion).
 5. Recommend which sites should have sensitivity labels applied but currently don't.
Format results as a prioritized remediation list — highest risk first.

    This gives you an actionable list to work through before any end user asks Copilot Cowork a question about a document they shouldn’t be able to see.

    Your Day 1 Readiness Checklist

    • [ ] M365 Copilot licenses assigned to target users
    • [ ] AI Administrator role confirmed
    • [ ] Tenant enrolled in Frontier (Copilot → Settings → Frontier)
    • [ ] Early access enabled and Web Apps users selected
    • [ ] Anthropic enabled under Data access → AI providers
    • [ ] Pilot security groups created (Wave 1, 2, 3)
    • [ ] SharePoint oversharing audit completed using Admin agent prompt
    • [ ] External sharing policies tightened
    • [ ] Sensitivity labels deployed for confidential content
    • [ ] Pilot feedback channel set up in Teams

    Final Thought

    Copilot Cowork is a new way of working. The organizations that will get the most out of Day 1 are the ones doing this prep work right now. Join Frontier, enable Anthropic, run your oversharing audit, and start small with a tight pilot group.

    The foundation is simple: Frontier starts with admin enablement and provider access. Once that’s in place, you’re ready for everything that comes next.

  • Build Your Agent Factory: 10 Moves That Ship Fast (and Scale)

    Build Your Agent Factory: 10 Moves That Ship Fast (and Scale)

    Build Your Agent Factory: 10 Moves That Ship Fast (and Scale)

    Agents at scale. Not POCs.

    Here’s the playbook I’d hand any exec or builder who wants working agents in production—without turning the org into a science fair.

    1) Stand up an AI Agents Workforce

    What it is: A small cross-functional crew with authority to hunt repetitive work and ship agents.

    Who’s in:

    • 1 product owner
    • 1 engineer (Copilot Studio/Power Automate)
    • 1 data person
    • 1 security/governance lead
    • 1 domain SME.

    Ship this week: Write a one-page charter with scope, decision rights, and a 30-day roadmap (first 5 agents + metrics).

    2) Win with horizontals first, then go vertical

    Horizontals (1-hour wins): drafting, summarizing, policy Q&A, meeting notes to actions, form-fill helpers.

    Verticals (outsized ROI): pick 1–2 per business unit where there’s money, risk, or SLA pain.

    Guardrail: don’t start with the hardest workflow; start where you can close the loop and measure value inside two weeks.

    3) Make an Agents Directory the front door

    Why: Ideas die in email. A directory turns “we should build X” into spec and governance.

    Minimum intake fields:

    • use case name
    • goal
    • users
    • decision rights
    • data sources + who owns it
    • tools
    • PII/sensitivity
    • KPIs
    • business owner
    • risk level
    • rollout plan.

    Outcome: Every request auto-generates a lightweight PRD (goal, inputs, outputs, metrics, guardrails) and a yes/no gate.

    4) Create the 1-Hour Agent template

    Template anatomy:

    Goal + success criteria Input schema (what the user provides) Tools (actions/connectors) and permissions Knowledge sources (files, sites, indexes) Safety rules (allowed/blocked actions, escalation) Evaluation set (10–20 test prompts with expected outcomes) Deploy script (Dev → Test → Prod)

    Rule: If a use case can’t fit this page, it’s not a 1-hour agent—park it for later.

    5) Tie every agent to a visible scorecard

    Metrics to publish: time saved, cost avoided, error rate, CO₂/efficiency (where relevant), user satisfaction.

    Simple formula: monthly users × average minutes saved × loaded cost = value.

    Make it public internally: green/red status, owner, last review, next improvement.

    6) Run on a secure, managed agent runtime

    Non-negotiables: identity passthrough, content safety, audit logs, tool call restrictions, data boundary controls, environment isolation.

    Practical tip: standardize a “sensitive sources” policy and block tools by default; allow case-by-case.

    7) Split the stack to move fast without breaking things

    Experience layer: Copilot Studio for UX, channels, and connectors.

    Agent runtime/orchestration: managed agent service for threads, tool calls, safety, and evaluations.

    Why it works: builders ship quickly at the edge; platform team keeps shared guardrails, monitoring, and upgrades stable.

    8) Mix knowledge + action (or you’ll stall)

    Knowledge: structured grounding (SharePoint/Fabric/Search), doc versioning, citations-on by default.

    Action: flows/Logic Apps, Graph, line-of-business APIs; always ship with a dry-run mode first.

    Design pattern: Answer → show sources → propose actions → execute on approval. When confidence is high and stakes are low, allow auto-execute.

    9) Keep humans in the loop—by design

    HITL patterns that work:

    Shadow mode (observe only) → suggest mode → execute with approval → auto-execute.

    Confidence thresholds where low confidence routes to a human. Escalation logic when guardrails trip or data is missing.

    UX rule: one click to approve, one click to undo.

    10) Plan to scale on day one

    Pipelines: Dev → Test → Prod with approvals and rollback.

    Evals: pre-ship test set per agent; weekly drift checks; quarterly red-team.

    Ops: central logging, cost dashboards, incident playbook.

    Program ritual: a quarterly “Agent Backlog Day” to harvest new ideas and retire underperformers.

    Starter Architecture (fast and boring)

    Experience: Copilot Studio (web, Teams, M365, chat, plugins)

    Actions: Power Automate/Logic Apps + custom APIs

    Knowledge: SharePoint/Fabric/AI Search with retrieval policies

    Runtime: managed agent service for tool orchestration, identity, safety

    Observability: evaluations, telemetry, and a simple agent scorecard per app

    Security: Entra ID RBAC, private endpoints, DLP, approval gates

    Prompts and policies that save you pain

    Prompt contract (keep it in the repo): role, goals, inputs, allowed tools, forbidden actions, decision rights, escalation, output format, citation rules.

    Data contract: what sources are permitted, freshness expectations, sensitivity tags.

    Failure modes: what the agent must do when unsure (ask for clarification, route to human, or stop).

    Anti-patterns I keep seeing

    • Starting with an “AI strategy deck” instead of shipping 3 agents.
    • Agents that answer but can’t act—users stop coming back.
    • No owner, no scorecard, no sunset date.
    • Canary-testing in production without a rollback plan.
    • Letting one giant use case block 20 small wins.

    Your first week mapped

    Day 1: Form the team and publish the charter.

    Day 2: Launch the Agents Directory (intake + PRD autogeneration).

    Day 3–4: Build two 1-hour agents (drafting + policy Q&A) with eval sets.

    Day 5: Ship to a pilot group with scorecards visible. Book the first backlog day.

  • Part 2 – Build & Ship a “Docs Agent” to Microsoft Teams

    Part 2 – Build & Ship a “Docs Agent” to Microsoft Teams

    (Companion guide to “Spin-Up the Microsoft Learn MCP Server”)

    Make sure you have read and setup the Docs MCP custom connector from part 1

    What you’ll build

    A Copilot Studio agent that queries the Microsoft Learn MCP server for live docs, then answers teammates inside a Teams chat or Meeting.

    Prerequisites

    NeedNotes
    Docs MCP custom connector from Part 1Already in your environment.
    (https://flowaltdelete.ca/2025/06/26/how-to-spin-up-the-microsoft-learn-mcp-server-in-copilot-studio/)
    Copilot Studio (preview) tenantGenerative orchestration enabled. (Early Features)
    Teams admin rights (or approval from your Teams Admin)To upload a custom app or publish to the org.
    Copilot Studio LicenseMessage packs or sessions
    prereq table

    Icons to Download (optional)

    Below are icons you can use for the Agent and the MCP custom connector.

    Microsoft-Learn-Docs-Agent-Logo-SmallDownload
    ms-docs-mcp-icon1Download

    1 – Create the Agent in Copilot Studio

    In this example I am going to use the existing agent I created from Part 1.

    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)
    2. Name: MS Docs Agent
    3. 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.
    4. Orchestration = Enabled

    5. 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.
    6. Web Search – This should be Disabled. We only want the agent to query the docs which it does through the MCP server.
    7. 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.
    8. To recap, the only Tools and Knowledge this agent should have is the MCP Server (custom connector) that we created in the first blog post. If you need help setting this up refer to Part 1.

    Add Suggested Prompts

    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:

    TitlePrompt
    Dev Env for Power AppsSet up a developer environment for Power Apps—step-by-step.
    Rollup vs FormulaRollup fields vs Formula columns in Dataverse—when to use each?
    Flow 502 FixPower Automate flow fails with 502 Bad Gateway—how do I resolve it?
    Cert Path FinderFastest certification path for a Dynamics 365 functional consultant.
    PL-200 Module ListList every Microsoft Learn module covered by the PL-200 exam.
    Managed Env EnableTurn on managed environments and approval gates in Power Platform.
    Finance DLP PolicyBest-practice DLP setup for finance data in Power Platform.
    Power Fx Date FilterSample Power Fx to filter a gallery to today’s records.
    OpenAI Flow SampleMinimal example: call Azure OpenAI from Power Automate.
    Secure Env VarsSecure environment variables with Azure Key Vault in flows.
    Pipeline ChecklistChecklist to deploy a solution through Power Platform pipelines.
    PCF Chart ControlBuild a PCF control that renders a chart on a model-driven form.
    New PA FeaturesSummarize new Power Apps features announced this month.
    Preview ConnectorsList preview connectors added to Power Automate in the last 30 days.
    Explain to a ChildExplain 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.

    1. Click the Settings button on the top right.

    2. (Optional) If you want the agent to have reasoning capabilities > Under Generative AI turn on: Deep reasoning
      **Note that this is a premium feature**

    3. Scroll down to Knowledge, make sure Use general knowledge and Use information from the Web are both OFF

    4. 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.

    1. Click on Topics tab > Under Custom > Only leave Start Over topic On.

    2. Under System > Turn Off:
      – End of Conversation
      – Escalate
      – Fallback
      – Multiple Topics Matched

    3. Next, lets modify the Conversation Start to make it sound better.
      Click Conversation Start topic > Modify the Message node:

    4. Click Save.

    Now we are ready to Publish and Package for Teams!

    Publish & Package for Teams

    Next we need to Publish our agent.

    1. Click on the Channels tab > Click Publish

    2. Once your agent is published > Click on the Teams and Microsoft 365 Copilot channel.

    3. A sidebar opens > Check the Make agent available in Microsoft 365 Copilot > Click Add channel.

    4. After the channel has been added > Click Edit details.

    5. 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

    6. 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:

    1. First Publish your agent, to make sure you have the newest version you are pushing to Teams admin for approval.
    2. Next click on the Channels tab > Select the Teams and Microsoft 365 Copilot channel.
    3. Now click Availability options.

    4. Now we will configure the Show to everyone in my org.

    5. 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:

    1. Navigate to https://admin.teams.microsoft.com/policies/manage-apps
      (Click on Manage apps under Teams apps)
    2. Search for your agent name in the search bar

    3. Click the agent > Publish.

    4. 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:

    1. 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.

  • Add the Microsoft Learn Docs MCP Server in Copilot Studio

    Add the Microsoft Learn Docs MCP Server in Copilot Studio

    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.

    Why you should care

    • 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

    1. Go to Copilot Studio: https://copilotstudio.microsoft.com/
    2. Go to Tools → Add tool.
    3. Select the Model Context Protocol pill.
    4. Click Microsoft Learn Docs MCP Server.
    5. Choose the connection (usually automatic) and click Add to agent.
    6. Confirm the connection status is Connected.
    Copilot Studio Add tool panel showing Model Context Protocol category and Microsoft Learn Docs MCP Server tile highlighted.
    1. The MCP server should now show up in Tools.
    1. 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

    1. In the Test your agent pane. Turn on Activity map by clicking the wavy map icon:

    2. 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

    Use-Case Ideas

    • Internal help-desk bot that cites docs.
    • Learning-path recommender (your pipeline example).
    • Governance bot that checks best-practice-links.

    Troubleshooting Cheat-Sheet

    • 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

    1. 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
    1. 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.

    1. Go to make.powerapps.com > Custom connectors > + New custom connector > Import OpenAPI.

    2. Upload your yaml file eg: ms-docs‑mcp.yaml, using the Import an OpenAPI file option.

    3. General tab: Confirm Host and Base URL.
      Host: learn.microsoft.com
      Base URL: /api
    4. Security tab > No authentication (the Docs MCP server is anonymously readable today).
    5. Definition tab > verify one action named InvokeDocsMcp is present.
      Also add a description.

    6. 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)
    7. 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.