Connecting data

Most confusion about managed apps comes from treating two different things as one. While you build, the agent works inside your session: it can read your mail and files, search the web, use plugins and call connectors as you. None of that travels into the app. The published app runs later, as each person who opens it, and it can reach only the sources that were bound into it. A data-source binding is the only bridge between the two layers. OD

The practical rule: if you want the app to show something, ask for it to be bound, then ask which screens are still running on sample data. If you only want the agent to look something up while it builds, say so, and nothing is added to the app.

Figure 3 is shown at the top of this part.

Copy link

Copy link

Every source the app uses at run time is bound in one of two modes. Table mode exposes one table of a tabular connector (a SharePoint list, a SQL table or a Dataverse table) as a typed create, read, update and delete service. Action mode exposes a connector's operations as typed methods. Binding writes a connection reference into ms.config.json and generates typed models and services under generated/. Code does this with its data-source tools; the CLI does it with ms app add data-source. OD

Copy link

Every app built on Copilot Managed Runtime inherits a default environment-group policy with four rules: routing (each maker gets a personal developer environment), connectors and MCP servers, sharing, and content security. D

• Connectors: 18 Microsoft first-party connectors that authenticate only through Entra ID: SharePoint, OneDrive for Business, Word Online (Business), OneNote (Business), Microsoft Teams, Office 365 Outlook, Office 365 Groups Mail, Office 365 Users, Office 365 Groups, Microsoft Planner, Microsoft To Do, Microsoft Bookings, Microsoft Forms, Excel Online (Business), Dataverse, Power BI, Yammer/Viva Engage and Azure DevOps. D
• MCP servers: 12 in the default allow-list: the Work IQ Copilot, Teams, Outlook Mail, Outlook Calendar, Word, User, OneDrive and SharePoint servers, the Power Apps MCP Server, Fabric MCP, Microsoft Learn Docs MCP and an entry listed as Microsoft MCP Servers. D
• Blocked actions inside allowed connectors: "Send an HTTP request" style actions, Office Scripts, freeform DAX queries and arbitrary Dataverse custom APIs. D
• Sharing: sharing with everyone in the organization is allowed; guest sharing can be switched on but guests can't open apps yet (a known issue). D
• Content security policy: same-origin by default for scripts, fonts, images and network calls; no web workers or service workers; admins can add specific origins, ideally in report-only mode first. D

Two consequences matter for makers. First, a connector can show as allowed by your Power Platform DLP policy and still be unavailable to apps, because the runtime policy is a second filter. Second, no service workers means no offline mode or installable web app today. DI

Decide this in the setup → Step 6: Integrations

Copy link

A connector has to clear two separate policies before an app can call it: your tenant's Power Platform data policies, and the managed-app runtime policy of the app's environment group. Then it runs only as the signed-in user. D

Figure 4 is shown at the top of this part.

• When Code lists connectors, it shows each one's tier (Standard or Premium) and its data-policy verdict, and it can include the blocked ones on request. In an example tenant, Power BI, SharePoint, Excel Online (Business), Teams, Standard approvals, SQL Server, Dataverse and Microsoft Copilot Studio were allowed, while the Logic flows connector, the one an app would use to call a Power Automate flow, was blocked. O
• The same list showed Microsoft's MCP servers as connectors: the Work IQ family (Copilot, Mail, Calendar, Teams, Word, OneDrive, SharePoint and User, plus a standard Work IQ server), Microsoft 365 Admin Center, Azure DevOps, Dynamics 365 Sales, Contact Center and Customer Insights, Fabric IQ Ontology, Microsoft Learn Docs and Microsoft Sentinel. Almost every third-party MCP server, from Zapier to DocuSign, was blocked by that tenant's policy. O
• An allowed verdict there is necessary but not sufficient: the runtime allow-list must also include the connector or server, and individual actions can still be blocked inside it. Microsoft notes that discovery and code generation leave out blocked operations, so a missing method in generated/ usually means policy, not a bug. D

Copy link

By default each person runs the app on their own connection, so they see only what they could already see in the source. The first time someone opens the app they may be asked to approve a connection. An app can deliberately use a shared connection (a service account) with only specific actions allowed, but Microsoft is explicit that allowing a table read does not by itself restrict which rows each person can read. If rows must differ by person, enforce it in the source: Dataverse security roles or SharePoint item permissions. D

Connections age. A connection can be connected, stale (it says connected but has expired), expired or missing, and a stale one needs the owner to sign in again. Ask Code to check connection health before a release and after any password or policy change. O

Finally, anything the app downloads is visible to the person using it. Microsoft notes that people can inspect request and response payloads in the browser, so hiding a column in the UI is not security. D

Copy link

• "List the connectors I can use in this app, including the ones blocked by policy, and mark which are on the managed-runtime allow-list."
• "Bind the Partner Opportunities list on https://contoso.sharepoint.com/sites/Sales in table mode. Show me the generated fields before you build any screen."
• "Use Office 365 Outlook in action mode. Draft only; never send without my click. Add a test that fails if any path sends without the send checks."
• "Add Work IQ through its MCP connector for the meeting brief. Time out after 3 minutes, retry once on 429 or 5xx, and cache the last answer per user for 24 hours."
• "Before you publish, list every screen and dataset that is running on sample data."

Copy link

• Table mode binds one list or library as a typed create, read, update and delete service; action mode binds the connector's operations as typed methods. Both write the binding into ms.config.json and generate code under generated/, which you never edit by hand. After any column change, ask for the data source to be refreshed and the app rebuilt. D
• Where the list can live: in the session tested, a table binding needed the full URL of a site or subsite under /sites/ or /teams/. The tenant root site and personal OneDrive sites were refused, as were site names with characters other than letters, digits, spaces and ._~-. Give app data a plainly named site. O
• Schema reads before you build: Code can read a list's columns (up to 200 fields per read) through your own connection, so the app uses real internal names from the first prompt. O
• Let Copilot create the list: Cowork can generate a data schema in supported connectors, and community demos show Cowork turning an Excel sheet into a SharePoint list and reconnecting the app to it. DC SharePoint's own import from a spreadsheet takes tables of up to 5,000 rows and keeps the uploaded workbook in Site Assets, where other people with access can open it; delete it if the data is sensitive. D

Copy link

Copy link

• Pick the site by boundary. A dedicated site is not required, but use one whenever the app's owners, sensitivity, external sharing or lifetime differ from the site you were about to reuse. Team sites inherit permissions from their Microsoft 365 group; communication sites use Owners, Members and Visitors. DI
• Fix internal names on day one. A column's internal name is set when it is created and never changes. Create it as RequestStatus, then give it a friendly display name. Spreadsheet imports produce awkward internal names, so record the real ones in DESIGN.md. C
• Use real types. Number, currency and date columns, single choice for small fixed sets, lookups for maintained related lists, Person for people. Changing a column's type later can corrupt existing data. D
• Index before you grow. List settings, Indexed columns, Create a new index, for every column the app filters or sorts on, such as status, owner and dates. Test with realistic volume, not an empty demo list. DI
• Validate in SharePoint, not only in the app. Required columns and column validation (formula plus user message) still apply when someone edits outside the app. D
• Turn on versioning (List settings, Versioning settings) and content approval if records need sign-off. D
• Formatting is not logic. JSON column and view formatting change only how SharePoint displays data; none of it reaches the app or protects anything. D
• Keep lists generic. Custom list templates cause trouble for connectors and flows; build from a plain list. D

Copy link

Climb this ladder only as far as the business rules require. I

• SharePoint connections can't be shared. The standard SharePoint connection is marked not shareable, so there is no "service account" shortcut for a SharePoint binding. Every user needs real rights on the list. D
• Cosmetic controls are not security. Hidden lists, "[Me]" views, disabled grid editing and stripped application pages reduce accidental edits but leave the user's rights intact. C
• Allowing reads doesn't filter rows. Microsoft is explicit that allowing a table's read actions does not restrict which rows each person can read; only source permissions do. D

Copy link

• Containers: sensitivity labels on the site govern external sharing, unmanaged devices and authentication context, but list items don't inherit labels. Restricted Access Control adds a group gate to the site; Restricted Content Discovery only hides content from search and Copilot, and does not change access. Keep confidential app data on a site with external sharing off. D
• Policy: managed apps don't use the business and non-business connector grouping of classic data policies; with advanced connector policies and classic policies both active, the most restrictive setting wins. Purview data loss prevention protects files, not individual list cells. D
• Recovery: version history restores earlier values; the recycle bin keeps deleted items for 93 days in total across both stages; Microsoft 365 Backup restores a site to a point in time. Rehearse restoring a list, its schema and its permissions, separately from rolling back app code. DI
• Retention: list items are covered by retention labels, not retention policies. D
• Audit: Purview records SharePoint list and sharing operations. Managed-app sharing events are not documented in a published catalog yet, so keep your own access inventory (Part 15). D

Copy link

• Filter and sort on the server on indexed columns, request only the columns a screen needs, page through results and debounce search boxes. DI
• Cache small reference lists per session and refresh them after writes; never preload a whole list or look up related items one by one. I
• Test the published app, not just the local loop: one builder reported SharePoint calls working locally but failing after publishing because of a Conditional Access challenge. C

Copy link

Treat these as triggers for a design review, not hard thresholds: many related tables, transactions that must succeed or fail together, row- or field-level security, heavy concurrent writing, or around 10,000 items with complex filters. Move to Dataverse (in the app's environment; it isn't provisioned until a maker or admin adds it) or SQL (not on the default allow-list, so ask first). Never use an Excel workbook as a multi-user database: Microsoft says concurrent edits through the connector are unsupported and cause conflicts. DI

Copy link

• Name the data owner, site, list ids, audience, sensitivity and the trigger for moving off SharePoint. I
• Record internal column names, types and relationships in DESIGN.md. C
• Choose the permission level from the ladder and test it with an ordinary user's account. DI
• Add indexes, required columns, validation, versioning and, if needed, approval and retention labels. D
• Prove that paging returns every row beyond the first page at realistic volume. I
• Try editing outside the app as a normal user, and confirm what that person can and can't change. I
• Rehearse a restore and review group membership and access every quarter. I

Copy link

Copy link

• Binding: table mode binds one table by its logical name; action mode exposes the connector's organization-scoped operations when the table is chosen at run time. There is no procedure mode, and custom APIs (bound and unbound actions) are blocked by default, so don't put the app's core logic there. D
• What works: guidance written for Power Apps code apps, the same lineage, covers create, read, update and delete, choice labels, metadata, lookups, file and image columns (preview), and server-side filter, sort and top with paging. Polymorphic lookups, schema changes, FetchXML and alternate keys are not supported. Assume the same for managed apps and test. DI
• Security: with per-user connections, security roles, business units and column-level security all apply to every request (system administrators bypass column security). A shared connection would collapse everyone onto one identity, so don't use one for Dataverse. DI
• Where the tables live: default personal developer environments start without Dataverse; a maker or admin adds it in the Power Platform admin center. In an example tenant, the builder's developer environment already had a Dataverse database. Other users need a security role in that environment and premium licensing, which is one more reason not to run production apps from a maker's personal environment. DO
• Moving: moving an app to another environment doesn't move its Dataverse tables; recreate them there, ideally through a solution, before moving. DI
• At build time: Code sees every environment you can see, so pick the target explicitly. It can run read-only, SQL-style queries against Dataverse, Microsoft 365 and Business Central data you have access to, and inspect real tables and sample rows while designing. Copilot Studio Apps binds only existing tables. OD

Copy link

• In Code, Excel Online (Business) binds in action mode, row create, read, update and delete included; the CLI offers a table-mode picker instead. Either way the connector returns 256 rows per call by default, and you should let the picker discover the workbook rather than pasting a file URL. OD
• Microsoft says concurrent changes through the connector and by hand are not supported and can cause merge conflicts and inconsistent data. Use Excel to import, to export, or for a prototype one person uses; then move the data to a list or table. D

Copy link

• SQL Server is allowed by policy in many tenants but isn't on the managed-runtime allow-list, so ask for an exception first (section 16.7). It binds in table mode with the dataset as 'server,database' and the table as '[schema].[table]'. DO
• Stored procedures can't be bound; expose what you need as views or tables. An early SDK bug that returned 404 for SQL actions was fixed in later versions. DC
• A shared connection is possible for SQL Server with SQL authentication; it must declare allowed actions and still doesn't restrict rows (section 11.6). Fabric Warehouse and the SQL analytics endpoint don't support SQL authentication, so they run per user and each user needs item permissions. D

Copy link

• The SharePoint and OneDrive connectors separate items from files: binding a library's metadata doesn't mean table operations upload file bytes. Use the file actions for content, and keep attachments under the connector's 90 MB. D
• A small JSON file in each user's OneDrive is a good home for per-user settings, saved filters and drafts; it follows the person across devices and needs no shared list. OI

Copy link

• Most apps run on each user's own connection. A shared connection makes the app use one account's credentials for everyone, through a proxy that enforces the actions declared in ms.config.json; deployment fails if they're missing. D
• Only shareable authentication types qualify, such as SQL Server authentication or API keys. Microsoft 365 connectors (SharePoint, Teams, Planner, Power BI and others) authenticate only through Entra ID and are not shareable, so Microsoft 365 data is always reached as the signed-in user. D
• Allowing a table's read actions on a shared connection doesn't restrict which rows each person can read; filter rows in the source or don't share the connection. Shared identities also blur who changed what, so log the real user in the record. DI

Copy link