Copilot Playbook
Managed App Kit/Handbook/Chapter 4
Updated November 7, 2026
Managed App Handbook · Chapter 4 of 8

Power BI, Power Automate, Copilot Studio, Teams and Work IQ

How a managed app works with Power BI, flows, Copilot Studio agents, Teams, Outlook, Work IQ and MCP servers.

For makers, developers, admins and owners · 11-minute read · Facts as of 7 November 2026

Chapter 4 of 811-minute readParts 12–14Facts current as of 7 November 2026

Evidence tagsD DocumentedO ObservedC CommunityI Inference

Every claim in this handbook carries a tag, so you can tell documentation from observation from opinion.

  • DDocumented. Documented by Microsoft on Learn, Support, Message center, GitHub or an official blog, as of the dates in Appendix E
  • OObserved. Observed first-hand on 7 November 2026 in a live Copilot Code cloud session: its tools, its sandbox, an example tenant's policy verdicts, and the repository of a production partner-sales app
  • CCommunity. Reported by the community (MVP blogs, forums, videos, GitHub issues) and not confirmed by Microsoft
  • IInference. Inference or recommendation by the author; test it before you rely on it

Part 12

Power BI and Fabric

  • What it isThe routes a published app has to Power BI and Fabric data, and how Copilot reads semantic models while it builds.
  • What you doRead the model's measures first, chart operational data in the app, and link to the governed report for analysis.
  • Watch outFreeform DAX is blocked by default, embedding is unproven in managed apps, and Publish to web makes a report public.

Decide this in the setup Step 6: Integrations

Power BI is where most organizations keep their numbers, so it's the second thing people ask an app to reach. The short answer: Copilot can read your models while it builds, and the published app has several safe routes to them, but not the one people try first.

12.1

What a published app can do with Power BI today

RouteHowStatus
Chart the data the app already readsBuild charts in the app (the chat template includes a charting library)No admin change and no Power BI license; best for operational data I
Link out to the governed reportA link with URL filters, for example ?filter=Region/Name eq 'West', plus pageName for a pageDocumented; URL filters are not security, so rely on row-level security D
Connector actionsRefresh a dataset, Add rows to a dataset, Export To File for Power BI and paginated reports, goals and scorecardsOn the default allow-list; not shareable; 100 calls per minute per connection DO
Freeform DAX ("Run a query against a dataset")The connector's query actionBlocked by default; an admin can allow it per environment group DC
Fabric MCPMicrosoft's Fabric MCP serverOn the default MCP list; Fabric IQ's server is read-only, runs as the user and applies row- and object-level security D
Embed a reportAn app.powerbi.com frameBlocked by the default content security policy; needs an admin change, a Pro or Premium Per User license per viewer (unless on F64 or Premium capacity), and Microsoft warns automatic sign-in doesn't work when embedded in applications. Unproven in managed apps DI
Power BI Embedded (app owns data)Embed tokens from a service principalNeeds a backend the app doesn't have; secrets never go in the browser DI
Publish to webNever: it makes the report public on the internet D
  • In an example tenant, the Power BI connector exposed 36 operations, including Run a query against a dataset, Run a JSON query against a dataset, Refresh a dataset, Export To File for Power BI Reports, and goal and check-in actions. O
  • Whether the JSON query action is blocked like the DAX one is not documented; run ms connector list-actions --connector shared_powerbi against your policy before designing around it. D
  • If an admin allows queries, the action mirrors the Execute Queries REST API: the tenant setting and Build permission are required, each query returns at most 100,000 rows or 15 MB, each user can run 120 queries a minute, and service principals don't work with row-level security. Use it for small, pre-aggregated KPI queries. DI

12.2

Build time: let Copilot read the model first

  • Code found Power BI semantic models by name in an example tenant, and the same toolset can read a model's tables, measures, relationships and author instructions and run up to four DAX queries per call, returning up to 1,000 rows each, all as the builder. O
  • Cowork's Fabric IQ plugin queries datasets and reports as the signed-in user with row-level security; Code uses the same plugins. D
  • The sequence that works: read the model's schema and measures, design screens around the measures that already exist, then decide which few numbers the app needs at run time and which route from section 12.1 delivers them. Don't re-implement measures in TypeScript, which creates a second source of truth. I
"Find the Partner Revenue semantic model, list its measures and row-level security roles, and propose a dashboard that uses those measures as they are. For each number, say whether the app should compute it, link to the report, or read it at run time, and why."

12.3

Patterns

  • Do: chart the operational data the app already holds; link to the governed report with filters for anything analytical; read a handful of KPIs through an approved action or Fabric MCP; refresh a dataset after the app writes adjustments; export a filtered report to PDF and attach it to an Outlook draft. DI
  • Avoid: Publish to web; URL filters as security; embed secrets in the app; asking for a tenant-wide DAX unblock when one group-level action would do; copying measure logic into the app. DI

Part 13

Power Automate, Copilot Studio and Power Apps

  • What it isHow managed apps work with Power Automate flows, Copilot Studio agents and the other kinds of Power Apps.
  • What you doHave the app write a record with a status and a correlation id, and let a service-account flow react to it.
  • Watch outThere is no documented way for a managed app to call a flow, and the Copilot Studio connector needs a runtime exception.

Decide this in the setup Step 6: Integrations

These three are where most organizations already run their processes, agents and apps. A managed app can work alongside all of them, but the connections are narrower than people expect, so design the contract between them before you build.

Write, then react: how an app starts a flow

Units: steps in order; the status column carries the stateSource: section 13.1, section 13.2Evidence D I

The app writes a record and a flow reacts; the app never calls the flowUserManaged appList or tableFlow (service account)1. submits a request2. writes Pending + CorrelationId3. trigger fires on Pending4. sets Processing5. runs the approval, with retries6. upserts Done or Failed7. reads the status column8. shows progressno documented call from app to flow×

Swipe sideways to see the whole sequence, or open the data below.

  1. Pendingwritten by the app
  2. Processingset by the flow
  3. Done or Failedset by the flow
Show the data
  1. User → Managed app: submits a request in the app
  2. Managed app → List or table: creates the item with Status = Pending and a correlation id
  3. List or table → Flow (service account): the trigger condition fires only on Status = Pending
  4. Flow (service account) → List or table: sets Status = Processing
  5. Flow (service account): runs the approval, with Run after settings, try and catch scopes and retries with backoff
  6. Flow (service account) → List or table: sets Done or Failed, writing upserts keyed on the correlation id
  7. Managed app → List or table: reads the status column
  8. Managed app → User: shows the status so the user sees progress

The app never calls the flow: there is no documented way to (section 13.1).

13.1

Power Automate: calling a flow from an app

  • There is no documented way for a managed app to call a flow. The CLI has no flow command, Microsoft's plugin has no flow skill, and flow-only connectors are excluded from the runtime policy by design. Power Apps code apps document instant flows with the Power Apps trigger, but nothing says that carries over. D
  • In an example tenant, the Logic flows connector, the one an app would use to call a flow, was blocked by tenant policy anyway. O
  • A browser call to a flow's HTTP trigger needs a content security exception, and an anonymous HTTP trigger bypasses Entra ID entirely. Don't build on either. DI

13.2

The pattern that works: the app writes, a flow reacts

The app writes a record through a connector it is allowed to use; an automated flow, owned by a service account in a shared environment, reacts to it. This is how you send notifications, run approvals and make the privileged writes that users must not make themselves (Part 10). DI

  • Trigger: SharePoint "When an item is created" or "When an item is created or modified", or Dataverse "When a row is added, modified or deleted", which also lets the flow run as its owner, the row owner or the modifying user. D
  • Idempotency: the app writes a correlation id and Status = Pending; a trigger condition fires only on Pending; the flow sets Processing, then Done or Failed; writes are upserts keyed on the correlation id; concurrency is 1 where order matters. Multiple updates can trigger multiple runs, so this matters. DI
  • Reliability: use Run after settings, try and catch scopes, retries with backoff, Terminate on failure and logging; show the status column in the app so users see progress. DI
  • Identity and licensing: automated and scheduled flows run in the flow owner's license context; Microsoft 365 licenses cover standard connectors only; a service-account-owned flow that uses premium connectors needs its own premium or process license. Keep these flows in a solution, with connection references, in a shared environment, never in a maker's personal one. DI
  • Build time: Code can read a flow's definition and callable interface in your developer environment, so the app's columns and status values match the flow's contract exactly. In an example tenant, the Standard approvals connector was allowed by tenant policy. O
"Add a Requests list with a Status column (Pending, Processing, Done, Failed) and a CorrelationId column. The app only ever creates items with Status Pending. Then write the spec for a flow, triggered when an item is created with Status Pending, that runs the approval, updates Status, and posts the outcome to the requester. I'll build the flow in Power Automate."

13.3

Copilot Studio agents inside an app

  • Calling an agent: the Copilot Studio connector's "Execute Agent and wait" returns the agent's answer to the app; the fire-and-forget variant doesn't wait, and an older wait action can fail. Microsoft's plugin adds this with /add-mcscopilot. D
  • Policy: the Copilot Studio connector isn't on the runtime allow-list, so expect to need an exception; it was allowed by tenant policy in an example tenant. DO
  • Which agents: only standard agents can be called today; agents built on the newer GitHub Copilot harness can't, according to an open issue and the Agents SDK page. CD
  • More than chat: the same connector exposes agent evaluation actions (run a test set, read test runs), which makes an agent quality console a buildable app. O
  • Embedding a chat window is not documented for managed apps. The default web chat frame requires no authentication, which is wrong for internal data, and Direct Line secrets must never sit in browser code. Link to the agent in Teams or Microsoft 365 Copilot instead. DI
  • Pattern: use "Execute Agent and wait" for single-turn "ask the agent" features, pass record ids rather than documents, and keep long-running work in agent flows. Agent runs consume Copilot credits. DI

13.4

Copilot Studio Apps as a front door

  • Copilot Studio builds the same managed apps, next to agents and workflows: on Home turn on New experience, then choose the App tile or Apps (Preview), New app. D
  • It can create SharePoint lists but connects only to existing Dataverse tables, may have a subset of the connector catalog, bills app creation to the environment, and limits attachments to 10 MB and 10 files per message. D
  • Apps built in Cowork can be opened and edited in Copilot Studio, and Studio sharing grants use, never editing. D

13.5

Power Apps: which kind of app, when

KindChoose it forALM
Model-driven appDataverse-centric processes that need forms, views, business process flows and role-based UISolutions and pipelines D
Canvas appLow-code Power Fx apps, including guest access through B2BSolutions and pipelines D
Power Apps code appProfessional React apps that need solution ALM and documented flow callsSolutions (pa app push --solution-id) and pipelines D
Managed appAI-built Microsoft 365 line-of-business apps, governed in the Microsoft 365 admin center, backed by Git, payable with Copilot creditsGit commits and deploys; solutions and pipelines not documented D
  • Managed apps use the ms CLI and ms.config.json; code apps use the pa CLI. Code apps accept Premium, pay-as-you-go or App Pass; managed apps accept Premium or Copilot credits. D
  • The Power Apps MCP Server is on the default MCP list, but how an app would use it isn't documented. D
  • Users in a managed developer environment need premium licenses to run Power Platform assets, so promote apps to a shared environment before sharing widely. Unmanaged developer environments start being suspended on 15 December 2026. DI

Part 14

Teams, Outlook, Work IQ, MCP servers and AI

  • What it isUsing Teams, Outlook, Planner, Forms, Work IQ, other MCP servers and AI models from inside a managed app.
  • What you doPost to Teams only on meaningful events, keep email as drafts with an explicit Send, and give Work IQ calls a timeout, a retry and a cache.
  • Watch outWork IQ calls are billed separately even for Premium users, and third-party MCP servers are excluded from the default policy.

Decide this in the setup Step 6: Integrations

14.1

Teams

  • Posting: the Teams connector can post messages and adaptive cards as the Flow bot or as the user, but only if the Workflows app is allowed in the Teams admin center. Messages are capped at about 28 KB, private channels aren't supported, connections aren't shareable and throttling is 100 calls per minute per connection. Graph request actions are blocked by the runtime policy. D
  • Pattern: post on meaningful events (an approval, a breach, a daily digest), not on every change, or you hit throttling and the size cap; let a flow or a Cowork scheduled prompt do the posting where possible. DI
  • Hosting the app in Teams is not documented. Post the play link in a channel or pin it as a website tab at your own risk; embedding depends on the frame-ancestors content security rule. DI

14.2

Outlook

  • The Office 365 Outlook connector's actions, including Send an email (V2), are on the default allow-list; its HTTP request action is blocked. D
  • Never auto-send. Show the person a preview and require an explicit Send, or restrict the app to draft-only actions through the declared action list. A production partner-sales app studied for this guide put every send behind a switch, a recipient guard and a test that fails if any path bypasses it. DOI

14.3

Planner, To Do, Forms and Bookings

  • Planner works with basic plans only and its connections aren't shareable; Create a task is the common action. D
  • Forms is on the default allow-list, but its connector reference marks it "Not available" for Power Apps, and its only actions read a form's details and a response by id. Have a flow copy each new response into a list or table the app reads. DI

14.4

Work IQ inside the app

  • Work IQ brings grounded Microsoft 365 answers (mail, meetings, chats, files) into the app as the signed-in user. Microsoft's plugin adds it with /add-workiq, which binds the Work IQ Copilot MCP connector in action mode; your code still opens a session, reuses its id, calls tools and re-initializes when the session expires. D
  • It authenticates as the user only, and its calls are billed in Copilot credits separately, even for users with Power Apps Premium. D

Decide this in the setup Step 4: Screens and features

14.5

Other MCP servers and custom connectors

  • Two layers, two counts: 12 in the default allow-list (section 9.4), and about 20 allowed in an example tenant by its tenant policy, including Work IQ's mail, calendar, Teams, Word, OneDrive, SharePoint and user servers, Microsoft 365 Admin Center, Azure DevOps, Dynamics 365 Sales, Contact Center, Customer Insights, Fabric IQ Ontology, Microsoft Learn Docs and Microsoft Sentinel. O
  • Third-party MCP servers, custom connectors, preview and deprecated connectors, flow-only connectors and other independent publishers' connectors are excluded by design. An admin can add them only by taking full control of the policy ("Edit this policy"), which stops Microsoft's automatic updates. Advanced connector policies don't govern custom, private or HTTP connectors; classic data policies still do. DC
  • For your own APIs, the documented pattern for code apps is an Azure Function behind API Management, exposed as a custom connector; for managed apps the connector must also be admin-allowed, and runtime support for custom connectors isn't documented yet. Calling an API directly from the browser needs a per-origin content security exception, never a wildcard. Keep secrets in the function or connector, never in the app. DI

14.6

AI inside the app

  • Grounded Microsoft 365 answers: Work IQ (section 14.4). D
  • Domain logic and tools: a Copilot Studio agent called through "Execute Agent and wait" (Part 13). D
  • Your own models: the Azure OpenAI connector is premium and not on the default allow-list; its API-key authentication is shareable but has no function calling or images. Use it only behind a governed connector with declared actions, and never put keys in the app. DI
  • Safety: no Azure AI Content Safety connector exists; rely on Work IQ's and Copilot Studio's safety layers, or screen content behind a function. DI
  • At build time the options are wider: Code and Cowork can use plugins, web research, image generation and every connector you can reach to design and test the app, but none of that travels into the published app (Part 9). DO