Two integration platforms. Both promise depth, autonomy and AI. This page compares what each one actually requires of your team, across forty-four jobs.
Each line opens the row it came from, with the scenario and the documentation behind it. Read them sceptically: that is what the rest of this page is for.
Why the promises tell you nothing, in one analogy:
Two cars, both advertised as self-driving. One parks itself in your driveway. The other drives Philadelphia to Denver while you sleep. Same words on the brochure. Not the same product.
Same two words on both brochures. Two completely different products.
Integration platforms are harder: there is no test drive. Every vendor writes the same words: deep, autonomous, AI-powered, enterprise-grade. Words are free. You find out what you bought in month nine, when a customer reports a failed sync and you need to know exactly what happened. Or in year two, when the engineer who built it is gone.
So this is not a page of claims. It is a page of jobs. A real thing that has to happen. What happens on APIANT, step by step. What the same job requires on Microsoft Power Automate, in its own documentation's words.
Apply the same scepticism to us. Read the architecture, not the adjectives. And take three questions with you into every vendor conversation you have after this one:
After the AI has done the work, is there a representation a non-developer can open, read, and judge? Building something and being able to look at it afterwards are two different capabilities.
Jump to Capability 01, where it bites hardest → TEST 02Never accept a depth claim. Test it against the specific API you need: the private endpoint no catalog lists, the forty custom fields, the rate limit, the pagination quirk.
Jump to Capability 04, the uncatalogued endpoint → TEST 03Every AI gets something wrong eventually. The question is what, in the architecture, is positioned to catch a wrong result before your customer sees it.
Jump to Capability 24, the answer to it →These three tests run on every one of the forty-four capabilities on this page. By the third section you will be asking them yourself.
Integration work is where your roadmap goes to wait. Deals stall on a connector that does not exist yet, engineers get pulled off product to fix a sync, and a single "it didn't work for one customer last Tuesday" can absorb a week of senior time. Whichever platform you choose, you will live inside its architecture for years. This page shows you what each one actually requires of your team, job by job.
A note on method. Every vendor in this category claims depth, autonomy, and reliability, and you have no way to adjudicate competing claims. So this page does something else: it takes concrete jobs and shows what each platform's architecture requires to get them done. APIANT's side is a walkthrough of shipping capabilities. Microsoft Power Automate's side is derived from Microsoft Power Automate's own documentation, repositories, and pricing page, quoted where a quote beats a paraphrase. Where their design handles a job well, we say so.
How to read this page. Every row is one capability. Bright text is what you get on APIANT; muted text after the dot is what the same job costs on Microsoft Power Automate. Skim the forty-four takeaways and open any row that matters. Inside each: the problem that forced the capability to exist, a concrete scenario, how it goes on APIANT, and what the same outcome requires on Microsoft Power Automate. Skim the bold lines first. The argument is the pile, not any single row.
Their flow definitions are declarative JSON against a published schema, same as ours, so the foundation argument is not the format. It is what the format sits on: testing waits for publish ('flow changes need to be published and runnable to be tested'), a message caps at 100 MB, 1 GB where the connector supports chunking, and a dedicated compute boundary means leaving Power Automate for Logic Apps Standard on Azure billing.
Everything on this page traces back to one design decision made years before AI could build integrations: what is an integration made of? On APIANT the answer is structured data, all the way down. That choice looked like an implementation detail for a decade. It is now the whole ballgame.
Both let an AI build the integration. The difference is what the AI hands you afterwards.
Quarter-end's 80MB file clears by 4am on the same path as a normal night. Elsewhere, 100 MB per message, 1 GB where the connector supports chunking, throughput metered per 24 hours
Open the scenarioIntegrations died on large payloads, and on formats the platform had not anticipated.
Every record, file, and API response flows through a single engine with a small memory footprint. The platform does not care what shape your data arrives in or how much of it there is.
Caldera Health, a 38-clinic group. Every night at 1am, their practice-management system exports the day's claims and inventory as one file. On a normal Tuesday it is 12MB. At end of quarter it is 80MB. The integration has to parse it, reconcile it against the billing platform, and post corrections before clinics open at 7am. Nobody is awake to babysit it, which is the point.
Corrections post by 4am. Quarter end is not an incident category.
A payload over the cap does not degrade, it fails, and whether you can get past the cap is decided by whoever authored the connector rather than by you. For a SaaS company moving customer exports, attachments and bulk extracts, that is the routine case rather than the edge case.
Microsoft publishes the ceiling and its workaround in the same row: "Message size | 100 MB | To work around this limit, consider allowing chunking under the action content transfer settings. However, some connectors and APIs might not support chunking or even the default limit." Where the connector does support it, "Message size with chunking | 1 GB". The same page notes that "the overall size of the payload and not just the file needs to be under 100 MB", meters volume as "Content throughput per 24 hours | 200 MB for Low; 2 GB for Medium; 10 GB for High", and holds synchronous calls to "Outbound synchronous request | 120 seconds (2 minutes)". Where the data sits on the customer's own network, the on-premises data gateway is tighter: "The gateway has a 2-MB payload limit for write operations", and "a 2-MB request limit and an 8-MB compressed data response limit for read operations".
The documented way to move those numbers is to move product. Azure Logic Apps states the per-action maximum as "1,073,741,824 bytes (1 GB) (Default)" with "Content chunk size per action ... 52,428,800 bytes (52 MB) (Default)", and the Standard tier allows those defaults to be changed in host settings. That is Azure Logic Apps Standard, not Power Automate: a separate designer, a separate limits page, and a plan "billed for reserved capacity and dedicated resources whether or not you use them". (limits-and-config; gateway-reference, last updated 08/19/2026; logic-apps-limits-and-config, last updated 05/20/2026; logic-apps-pricing; seen 2026-08-25.)
Your syncs queue behind your own traffic, at your own domain, on a dedicated server pair from the entry paid plan. Elsewhere, environments are a boundary in the portal; dedicated compute is a different Azure product
Open the scenarioShared infrastructure means shared rate limits, shared incidents, and commingled customer data.
A 41-branch credit union circles one line in its security review: confirm member data is not commingled with other tenants, and name the domain traffic terminates on. The board votes in nine days.
Your integrations run on servers that are yours, addressed at your domain, with nobody else's traffic in the queue. You can even shut them down.
Environments give you a dev, test and production boundary in the portal and in the licensing. They are not machines you own. If you run integrations on behalf of your own customers, the compute and the throughput under those integrations are shared infrastructure, and there is no product-level control that changes that inside Power Automate. Microsoft's architecture page names the hosting model directly: "Power Automate is upgrading environments to new architecture, SelfHost Multitenant, for better performance and feature support", with each environment reporting "SelfHostMultiTenant" or "LogicApps" as its environmentFlowHostingType. The Azure Logic Apps Consumption tier says the same thing without hedging: "All logic apps across Microsoft Entra tenants share the same processing (compute), storage, network, and so on." Reaching a system inside a customer's own network is done through "a locally installed Windows client application that acts as a bridge between your local on-premises data sources and services in the Microsoft cloud", which somebody installs and patches, since "We release a new update for data gateways every month." That is a bridge to your infrastructure, not your infrastructure running the integration. The documented route to infrastructure you control leaves the product: "For scenarios where you need to use, control, and manage your own infrastructure, you can create Standard logic app workflows using the hybrid deployment model in Azure Logic Apps", which requires "An Azure Kubernetes Service cluster that is connected to Azure Arc" and "An SQL database to locally store workflow run history, inputs, and outputs for processing". Costed honestly, moving there means a second product with Azure billing, capacity "billed for reserved capacity and dedicated resources whether or not you use them", and a Kubernetes cluster plus a SQL database your team now operates. (environment-architecture; logic-apps-limits-and-config; service-gateway-onprem; create-standard-workflows-hybrid-deployment; logic-apps-pricing; seen 2026-08-25.)
Structurally invalid work is refused at build time, instead of surfacing later in production logs. Elsewhere, behaviour is exercised after publish, not before
Open the scenarioA generated integration that is syntactically fine and semantically wrong reaches production, and nobody knows until customer data is wrong.
After a hail week, 6,200 claims queue up. The integration pushing approved amounts into payments compiled and deployed cleanly. Farmers on the phone tell the claims supervisor which field it wrote.
The AI's intent passes through a constrained schema, and the compiler rejects invalid structures at the door. Ask for something malformed and watch the platform say no.
Structure is checked before you publish. Behaviour is not. A change is exercised only once it has been published somewhere, so proving one means publishing a copy and running it. Concede that Microsoft supports doing exactly that, including in place: FlowAgent's copy_flow will "Copy a flow within the same environment or to another environment", re-creating the source "as a new, standalone flow (created Stopped by default)", and Power Platform pipelines move a solution through dev and test stages before production. The cost is the publish step itself and whatever the copy lands in, not an absence. Concede the checking that does exist, because it is real and it reaches an agent. "During the design phase, use the Flow Checker and Test Flow tools to identify and fix problems with flow logic, actions, and connectors." Copilot Studio agent flows refuse the publish outright: "You can't publish a flow if it contains errors. You must correct all the errors before you can publish your flow." And Microsoft's MIT-licensed FlowAgent MCP server puts the same gate on the agent surface, with validate_flow to "Pre-validate a flow definition against PA rules" and preflight_flow, a "Pre-save sanity check: validate the definition + check connection-ref status + detect solution-wrap-will-block-publish risk ... Returns {overall: ready|warn|block ...}". That repository was pushed 2026-08-25. What those checks do not do is execute the change before it ships. Asked whether drafts can be tested, Microsoft's own FAQ answers "Not at this time. Currently, flow changes need to be published and runnable to be tested", and the same page treats a testable draft as future work: "We're exploring the concept of creating a second runtime representation of a single flow to facilitate testing." A mapping that is syntactically valid and semantically wrong therefore clears every gate above and is discovered by a run of the published copy. (drafts-versioning, last updated 03/20/2026; test-cloud-flows; flow-designer; power-platform-skills server/mcp.mjs; seen 2026-08-25, copy_flow, validate_flow and preflight_flow wording re-verified verbatim against the repo 2026-08-26.)
The asset your company accumulates is a library of inspectable building blocks that any successor can open, not a portfolio of codebases that each had exactly one fluent reader, who has since changed jobs.
Stored credentials with agent-side repair, and dynamic values and dynamic schema read from the live account, are documented parity and we delete those rows. The gap is the connector nobody has built yet: a hand-authored OpenAPI 2.0 definition ('Q: Do you support OpenAPI 3.0? A: No'), premium use rights on every user of every flow that runs it, and any trigger pattern that is not a webhook or a poll is an email to condevhelp@microsoft.com.
Connector catalogs are where integration platforms compete in public, and it is the wrong contest. The integration a deal depends on is reliably the one no catalog lists. The real questions are time-to-new-connector, and how deep the connector goes once it exists.
A niche partner API becomes a working connector in one session, and the renewal survives. Elsewhere it arrives as a Node project, times forty clients. Elsewhere, an OpenAPI 2.0 file authored by hand, and premium use rights on every user of the flow
Open the scenarioThe integration the deal depended on was never in anyone's catalog, and the catalog vendor had no incentive to add it.
Northgate, a systems integrator with forty managed clients. Their largest client runs bookings on a regional platform nobody has heard of outside its niche. The endpoints that matter, membership holds and multi-site transfers, live in the partner API, behind an NDA, in no catalog anywhere. The client's renewal is conditioned on this integration existing within the month.
The connector exists in a working session. The renewal conversation changes subject.
The integration that closes a deal is usually the one no catalog carries. On Power Automate that work lands on a developer holding a spec file in a format most API vendors stopped publishing, and on a licence attached to every user whose flow later runs the result.
The documented inputs to a custom connector are "An OpenAPI definition (formerly known as a Swagger file)", "A Postman collection", or "Start from scratch using the custom connector portal". The format is fixed: "When creating a custom connector, the OpenAPI definition must be less than 1 MB. The OpenAPI definition needs to be in OpenAPI 2.0 (formerly known as Swagger) format", and the FAQ answers "Do you support OpenAPI 3.0?" with "No, only OpenAPI 2.0 is currently supported. Support for OpenAPI 3 is in the backlog" (seen 2026-08-25 and re-verified 2026-08-26; an OpenAPI v3 item was announced in the 2025 wave 2 release plan and later removed from it, so this is worth re-reading before you rely on it). A vendor shipping 3.x means a hand down-conversion before the wizard opens.
Then the standing tolls, all on Microsoft's pages. "Regardless of the type of publisher, connectors to an external infrastructure are automatically assigned as Premium tier connectors", and "You must have a premium or trial license to run any flow that uses a custom connector", so every customer-facing integration you build sits behind premium use rights for each user of the flow. The quota is split by plan: "Free plan: one", "Office 365 and Dynamics 365 plans: one", "Per user plan: 50". Once a connector is certified, a change redeploys on a fixed clock: "Deployment takes 15 days, no matter the size or complexity of your connector, whether it's new or an update." Microsoft's own agent surface builds flows from connectors that already exist in the environment (FlowAgent's build rules work from get_connector and get_operation_details, and none of its 55 tools at v3.0.4, seen 2026-08-25, creates a connector). One documented route does skip the spec file: an agent in Copilot Studio can "Connect your agent to an existing Model Context Protocol (MCP) server" through an onboarding wizard, which serves agent tools rather than cloud flow actions and presupposes the vendor already runs an MCP server.
Every API gets a vetted way of announcing changes, so records stop going missing or arriving twice. Elsewhere, a support alias for any signalling pattern that is not a webhook or a poll
Open the scenarioEvery vendor's API announces change differently, and picking the wrong mechanism means missed or duplicated records.
Nine carrier systems, 1,400 load tenders a night. One feed replayed a status it had already sent and two trucks went to the same dock, so the night dispatcher now reconciles the tender log by hand.
Polling for new records, polling for new-or-updated, manual webhooks, self-registering webhooks, service webhooks with event filtering, and long-lived protocol listeners. Six vetted patterns; the AI picks the right one per API.
Pick the wrong change-notification mechanism for a vendor API and you either miss records or process them twice. Power Automate documents two mechanisms, and its documented route to anything else is a support alias, which puts your ship date on someone else's queue. The FAQ is explicit: "Custom connectors for Azure Logic Apps and Power Automate support webhook-based and polling triggers. Webhook-based triggers wait for an event to occur, while polling triggers call your service at a specified frequency to check for new data. If you want to request other patterns for implementation, contact condevhelp@microsoft.com with more details about your API" (seen 2026-08-25, re-verified 2026-08-26). Note that the sentence names both products, so moving the workload to Azure Logic Apps does not change the answer for custom connectors. Concede that webhooks and polling cover a large share of vendor APIs. What they cost here is developer authoring and a metered floor. The trigger behaviour is declared in the OpenAPI document through the x-ms-trigger and x-ms-notification-url extensions, so someone writes and maintains it per operation; the polling cadence bottoms out at "Minimum recurrence interval | 60 seconds"; and each check is billed as work, since "Every trigger and action in the flow generates Power Platform requests" against a per-user or per-flow daily allowance. For an API that signals change some other way, the documented answer stays the email address.
Ask the AI for an inference or a price calculation and it arrives as a step your team can open and check. Elsewhere, one call per operation, a single 1 MB script per connector, and hand-built loops for unfamiliar pagination
Open the scenarioCreate-read-update-delete alone cannot express what modern APIs do.
The photo-damage model and the fraud score in claims intake sit inside a code block whose author left in March. At 3,000 claims a month, adjusters quote repair numbers the company cannot account for.
Add, delete, find, get, list, update, and invoke: the last one models operations that compute, transform, or generate (an AI inference, a price calculation), so the whole modern API surface fits the data model.
A connector operation here is one HTTP call to one endpoint. Anything a modern API expresses across several calls, or with a pagination convention of its own, becomes steps in your flow that you maintain and the platform meters per item. The reusable unit is declared data plus a bounded escape hatch. Behaviour beyond the OpenAPI 2.0 declaration goes into Microsoft's fixed set of policy templates or into one script: "Q: Is it possible to use multiple scripts per custom connector? A: No, only one script file per custom connector is supported", where "Your script must complete execution within 2 minutes, and the size of your script file can't exceed 1 MB", with a namespace allowlist and a narrowing surface ("Q: Can I create my own http client in script code? A: Currently yes, but we'll block this in the future"). The generic HTTP action is the usual fallback, and its documented losses are specific. Typed fields come from a pasted sample ("Select Use sample payload to generate schema"). Paging auto-follows two conventions, and "if the response specifies the next page with any other tag, you might have to add a loop to your workflow. Make this loop follow that tag and manually get each page until the tag is null", with "Retries and requests from pagination also count as action runs". The artifact itself has published ceilings: "Characters per expression | 8,192", "Actions per workflow | 500", "Allowed nesting depth for actions | 8". The escape hatch Microsoft names is a different product: Azure Logic Apps Standard documents "Inline JavaScript, C#, and PowerShell" and "Custom .NET code", and Build 2026 announced "Public Preview: Codeful Workflows with the Logic Apps Standard SDK ... create workflows directly in code using familiar .NET development patterns" (seen 2026-08-25). Moving there means Azure reserved capacity, "billed for reserved capacity and dedicated resources whether or not you use them", and it answers expressiveness by trading away the readable artifact your team was going to inherit.
Ask the AI to set the vendor's limit, or type it once yourself, and every account sharing that API queues against one 185-calls-per-10-seconds budget. Elsewhere, the meter is the connection, and each connector's ceiling is its author's
Open the scenarioA vendor's rate limit is the real constraint on a multi-location sync, and hitting it corrupts a run.
310 branches sync to one supplier API that allows 120 calls per 10 seconds. A rate-limit rejection killed the nightly refill batch partway through, and branch queues opened at 8am short of data.
Type a vendor's limit once and the platform enforces it across every automation and every account that touches that API, with queueing and backoff. One deployment runs 232 locations against a single 185-calls-per-10-seconds budget with the platform queueing and backing off rather than each flow deciding on its own.
Rate limiting here is a property of each connection, so a vendor's ceiling is held in as many places as you have customer connections, and the number in each place is whatever that connector's author wrote. Microsoft: "In addition to the limits the platform imposes, each connector service has its own limits ... When a flow runs into connector-level throttling limits, the service returns error code 429 (Too Many Requests) with error text like Rate limit is exceeded. Try again in 27 seconds." (understand-limits, seen 2026-08-25). The HubSpot CRM V2 (Independent Publisher) (Preview) connector, Premium class in Power Automate, publishes "API calls per connection | 100 | 60 seconds". For a connector you build yourself, the two published figures disagree by table: Power Automate's limits page says "500 requests per minute per connection", while the custom connector FAQ's own Power Automate and Power Apps table says "10000 requests for each connection created by the connector" (the FAQ's own "500 requests for each connection created by the connector" row sits in its Azure Logic Apps table, so the disagreement is with Power Automate's own limits page). Changing either is a conversation rather than a setting: "We handle throttling limit adjustments on a case-by-case basis. Connect with your Microsoft contact with justification if you'd like your connector's limits adjusted." Concede the declarative layer, which is real: a connector definition can carry a Microsoft-supplied policy template, and "policies are used to enforce throttling limits on API calls" (policy-templates, page dated 11/14/2023). On the flow side the throttle is per trigger and one way: "Turning on Concurrency Control can't be undone without deleting and re-adding the trigger." For a fleet of customer accounts, that means the ceiling you are protecting is enforced at the connection and the trigger, and it is re-set wherever a new one is created.
Integrations your team hand-built years ago become AI-editable without a rewrite. Elsewhere, reachable where the flow is modern and inside a solution
Open the scenarioYears of existing integrations would otherwise be stranded outside the AI's reach.
214 integrations built by hand over eleven years, and the two people who built them are one retirement and one resignation from being gone. Modernizing cannot pause a single member-facing flow.
Integrations built by people over a decade convert into the same structured form the AI operates, so the AI can maintain the estate you already own. Nothing is stranded, and nothing loses its visual form in the process.
Whether your existing library is reachable by their AI depends on how each flow was built and where it lives. Concede the strong half plainly: Microsoft's official FlowAgent MCP server (MIT, 55 tools, v3.0.4 as of 2026-08-25) edits a live flow element by element, applying "targeted ('surgical') edits to an existing flow's definition without resending the whole thing, ideal for changing one action, parameter, or expression on a large flow", addressed by a slash-delimited path such as actions/Send_Email/inputs/parameters/subject. The in-product Copilot publishes an exclusion list, and it reads like an inventory of older work: "You can't edit flows in the cloud flows designer with the Copilot experience if your flow has any of the following flows capabilities: A non-Open API flow (older connection format). ... A flow with a comment. ... A flow contains a Power Apps V1 trigger. ... A solution flow using connections instead of connection reference isn't supported." (faq-copilot-cloud-flows, last updated 02/20/2026, seen 2026-08-25). A comment left on a flow is enough to put it outside that experience. The programmatic route carries its own boundary: "This article covers the management of flows included on the Solutions tab in Power Automate. Currently, managing flows under My Flows aren't supported with code." Years of work built outside a Dataverse solution sits outside the API surface the agent uses. In Copilot Studio the handoff runs the other way as well: "Once you open the agent flow in the designer, the Copilot chat panel can no longer make changes to the agent flow."
Time-to-new-connector is measured in working sessions, not sprints, and every connector you add, however obscure the API, joins the same inspectable library instead of adding one more codebase to the pile someone must maintain.
Approvals, child flows and waits of days inside a run are shipped Microsoft primitives and we concede them outright. What is bounded is the shape of the logic: 'Allowed nesting depth for actions | 8', fifty parallel iterations in a loop, a 30-day run ceiling, and custom code budgeted at one 2-minute, 1 MB script per connector, with anything larger meaning Logic Apps Standard on Azure billing.
Field-to-field mapping is the demo. The business is nested rules, parallel work, digests, approvals, waits, and the awkward requirement that makes your operation yours. The question for any platform: does that logic fit inside the model, where it stays visible and testable, or does it spill into code and patterns your team hand-builds?
214 stores get overnight prices in minutes, and the 6am report fires once. Elsewhere, fifty iterations in a loop, a one-way concurrency switch, and no documented cross-run latch; on that basis the finish line is manual
Open the scenarioProcessing two hundred locations in series took hours. In parallel, nothing knew when all of them had finished.
Launch N child runs in parallel, and the platform itself knows when the last one completes, so the "everything is done, now reconcile" step is a primitive, not a science project.
A 214-location convenience chain pushes overnight price updates. Every store must be updated in parallel (serially it takes past opening), and when the last store finishes, one reconciliation report must go to the merchandising director, listing any store that failed. The hard part was never the fan-out. It is knowing, reliably, that all 214 are done.
Prices land in minutes, the report is on the director's desk at 6am, and nobody wrote coordination logic.
Inside one run the join is documented and real: "In parallel execution, flows run two or more steps simultaneously. The workflow continues only after all parallel steps are complete." The width is where the published numbers bite. "Apply to each concurrency | 1 is the default limit. You can change the default to a value between 1 and 50 inclusively", and trigger concurrency runs "1 to 100 when Concurrency Control is turned on (defaults to 25)" (limits-and-config, seen 2026-08-25). Turning it on is a one-way door: "Turning on Concurrency Control can't be undone without deleting and re-adding the trigger."
Azure Logic Apps answers the width question rather than removing it, at the price of changing products: "Concurrent iterations | Concurrency off: 20 ... Max: 50" on Consumption, with trigger concurrency defaulting to 100 in Standard. Standard is an Azure resource on a Workflow Service Plan, "billed for reserved capacity and dedicated resources whether or not you use them", so reaching those numbers means moving the integration onto a different product with Azure billing and Azure operations.
Microsoft Power Automate does not document a latch across separately triggered runs, the thing that tells you the hundred runs launched for a hundred locations have all finished. We searched limits-and-config, implement-parallel-execution, create-child-flows and the Logic Apps limits page including its batch section, which covers inbound message grouping rather than run completion. On that basis, knowing when the set is done is manual work rather than a platform behaviour.
Contact changes flow both ways on day one, without the overnight loop that rewrites one record 4,000 times. Elsewhere, not documented; on that basis the loop guard is written per flow, per direction
Open the scenarioTwo systems updating each other trigger each other, forever.
Arrowe Physio, 22 clinics. Patient contact details must stay identical in the practice-management system and the marketing CRM, editable from either side. The failure mode is famous: the CRM update fires a webhook, the integration writes to practice management, which fires its webhook, which writes to the CRM, which fires again. By morning one patient record has been "updated" four thousand times and both APIs have rate-limited the clinic.
The sync runs both directions on day one, and "infinite loop" is not in the runbook.
Concede the guard that exists, because on Microsoft's own stack it is good. The Dataverse trigger scopes on columns: "Use the Select columns box to define the specific columns of the row that should cause the flow to run when included in the request", with a filter expression so that "The flow runs only when the expression evaluates to true after the change is saved in Dataverse." Their warning on the same page is the shape of the problem in miniature: "Don't include columns that always exist on update, like the primary key of the entity. This can cause all updates to trigger the flow."
Microsoft Power Automate does not document this. We searched the Dataverse create, update and delete trigger page, limits-and-config, the coding-guidelines pages on error handling and trigger optimisation, and triggers-introduction. On that basis it is manual work rather than a platform behaviour.
For a sync you ship to customers between two systems that are both theirs and neither of them Dataverse, the echo suppression is trigger conditions and last-modified-by filters written into each flow, per direction and per system, and re-derived whenever a customer's field set or update pattern differs from the one it was built against.
Your grandfathered-plan exceptions stay readable in the flow, so whoever inherits them can audit them without an engineer. Elsewhere, eight levels deep, then the rule moves to another flow
Open the scenarioReal business rules are nested, and field-mapping tools cannot express them.
The rule behind 46 municipal waste contracts is nested four deep and lives in a spreadsheet the billing manager maintains by hand. Get one wrong and that city reopens twelve months of invoices.
"For each location, for each membership type, if the plan is grandfathered and the balance is positive..." expresses directly in the flow, and stays visible there.
Concede the model: conditions, switches, scopes, apply-to-each and do-until are built-in actions in a declarative JSON definition, and a non-developer can read one. The published ceiling is where per-customer rules land. "Allowed nesting depth for actions | 8 | Add child flows if you need more than eight levels of nesting." (limits-and-config, last updated 07/17/2026, seen 2026-08-25). Two more shape limits sit on the same table: "Actions per workflow | 500", carrying Microsoft's own note that "Flows with a large number of actions might encounter performance issues while you edit them, even if they have fewer than 500", and "Switch scope cases limit | 25". The editing cost rises with the size of the thing being edited, in their words, below the documented ceiling. The documented remedy for depth moves the rules out of the flow you were reading. Past eight levels the branch becomes a child flow, and "You need a solution with two flows." The nested rule a customer asked for then lives in two artifacts, and anyone tracing the logic later opens both.
One fix instead of nine, with nothing left behind in a forgotten copy to drift out of step. Elsewhere, fifteen days for a certified connector fix, whatever its size
Open the scenarioThe same twelve-step sequence appeared in nine automations and had to be fixed nine times.
A twelve-step onboarding sequence sits inside nine automations. The April rule change meant the identical edit nine times, and copy seven had drifted: a welder paid at the wrong rate for five weeks.
Extract the sequence once, call it from all nine. Fix it once, all nine inherit it, and the subroutine tests in isolation.
Reuse inside one tenant is documented and works: "Use child flows to easily manage flows and avoid flows with hundreds of steps. This approach is especially beneficial if you want to reuse tasks in multiple places in a cloud flow, or even across multiple flows", with the requirement stated on the same page, "You need a solution with two flows." The cost appears when the shared piece is a connector rather than a flow. For a certified connector, "Deployment takes 15 days, no matter the size or complexity of your connector, whether it's new or an update." (certification-updates, seen 2026-08-26). The same page lists sixteen edit types, OperationDeleted, OutputFieldTypeChanged and InputFieldDeleted among them, that "may break existing flows", and the recommended mitigation is operational versioning: add a new version of the operation and leave the old one standing. Flows on the old operation keep calling it until a person edits each of them. Microsoft Power Automate does not document a maker-facing or agent-facing query that lists which parent flows call a given child flow. We searched create-child-flows, flow-groups, the Power Platform inventory page and FlowAgent's 55-tool list, whose reach is connector and operation level. On that basis, finding the callers before changing a shared piece is manual work rather than a platform behaviour.
Customers get one 5pm summary instead of 400 pings, and nothing is lost when two runs land at once. Elsewhere, not documented; on that basis the digest is a table you build, and its actions are metered
Open the scenarioCustomers wanted one daily digest, not four hundred notifications.
One Tuesday produced roughly 400 emails, and two of the largest accounts asked to be removed from notifications. The operations manager assembles the 5pm digest by hand, and she is away next week.
Four hundred events land all day; one clean summary goes out at 5pm. A dedicated primitive, safe under concurrency.
The platform digests its own failures, not your customer's events: "Weekly failure digest: A summary of all flow failures across your environments over the past week, sent regardless of the failure type." (understand-flow-failure-notifications, last updated 04/03/2026, seen 2026-08-25). That is operational mail to flow owners on a fixed weekly cadence, and it is a different thing from one daily summary of four hundred business events sent to a customer. Microsoft Power Automate does not document a reusable collector that accumulates items across runs and drains on a schedule. We searched limits-and-config, get-started-approvals, the flows designer documentation listing and the coding-guidelines pages. On that basis it is manual work rather than a platform behaviour. The route their documentation describes is a scheduled flow reading a Dataverse table you design, populate and maintain. That hand-built table is also counted. Microsoft's limits guidance states: "Each action generates one request. If the action is in an 'apply to each' loop, it generates as many requests as there are items for the loop to process." (guidance/coding-guidelines/understand-limits, https://learn.microsoft.com/en-us/power-automate/guidance/coding-guidelines/understand-limits, seen 2026-08-25, re-verified verbatim 2026-08-26.) A four-hundred-item digest is four hundred counted actions on the way out, plus the writes that put the items there, against a request allowance measured per user and per flow.
A customer's 300-row mapping sheet becomes the configuration directly, with unresolved rows flagged, instead of a week of error-prone typing. Elsewhere, not documented; on that basis spreadsheet to mappings stays hand entry
Open the scenarioA customer's mapping requirements arrived as a 300-row spreadsheet, and hand-entering it was a week of error-prone work.
The field map arrived as a 300-row spreadsheet, and hand-keying it eats most of week one of four. Every keying slip surfaces later as a subscriber billed twice, and renewal season opens 1 October.
The 300-row file becomes the mapping, directly. The AI reads it, applies it, and flags the rows that do not resolve.
Microsoft Power Automate does not document this. We searched create-cloud-flow-using-copilot, faq-copilot-cloud-flows, the flows designer documentation listing, FlowAgent's build-flow and create-flow skills with its definition-reference and connection-patterns references, and Copilot Studio's flow-nl page. On that basis it is manual work rather than a platform behaviour. The near miss is worth naming so nobody thinks it was missed: Excel and other file connectors read a spreadsheet at run time, inside a flow that has already been built. That is data passing through a mapping, not a specification becoming one. What their AI does read at build time is connector metadata, and it reads it strictly: "ALWAYS call get_operation_details before building any connector action. Never guess parameter names, enum values, or action types." (FlowAgent build-flow skill, seen 2026-08-25). The grounding is the connector, so a customer's 300-row mapping sheet becomes designer entry, one row at a time.
Turnover stops costing you the same debugging twice: a quirk solved once stays solved after its author leaves. Elsewhere, the curated memory is Microsoft's, about Microsoft
Open the scenarioThe same API quirk was rediscovered every time, by whoever drew the short straw.
The engineer who holds the loan-status lookup table in his head has given notice. 11 live integrations rest on knowledge that was never written down, and his replacement starts in three weeks.
Mappings, transforms, gotchas, and templates are saved and searchable. The AI checks the library before building, so the Mindbody pagination quirk gets solved once, ever.
Concede that a curated memory ships, because it does and it is well built. FlowAgent's repository carries reference files its own AGENTS.md tells the agent to read before acting: "The references/*.md files are curated, plugin-specific docs covering: Flow definition rules ... Connection reference patterns ... Error-to-fix mapping (the exact API errors FlowAgent users hit) ... Always check references/*.md first, they contain hard-won knowledge that Learn docs don't cover or bury across many articles." (seen 2026-08-25). The bundled Microsoft Learn MCP server gives the same agent documentation search on top of it. That memory is Microsoft's, about Power Automate, shipped and updated with the plugin. Microsoft Power Automate does not document a customer-writable store of patterns or vendor-API quirks that the AI consults on later jobs. We searched the FlowAgent skills and references, the Copilot overview and cloud-flow FAQ pages, and the Dataverse MCP tool list. On that basis it is manual work rather than a platform behaviour. For a team shipping integrations to its own customers, the knowledge that decays is the per-vendor kind: which field a given CRM actually populates, which endpoint reports pagination inconsistently, which tenant needs the retry. On this surface that accumulates in engineers' heads or in a wiki their agent does not read.
A genuinely odd requirement ships without waiting on a vendor release, and everything around it stays readable. Elsewhere, custom code is a 2 minute, 1 MB script behind a premium gate
Open the scenarioOccasionally a requirement is genuinely outside any data model, and waiting for a platform release is not an answer.
A 1987 mainframe demands a check digit no mapping tool expresses. The systems analyst has a 30 September council deadline and a $140,000 quote for middleware to cover that one field.
When you truly need arbitrary logic, a script slots in as one node of the structured document. Code is an optional leaf inside a data document, never the foundation. Everything around that leaf stays visible, testable, and machine-editable.
When a requirement falls outside what the connector model can express, the code you are allowed to write on a cloud flow lives inside a custom connector, and it arrives boxed. Microsoft's write-code page: "Your script must complete execution within 2 minutes, and the size of your script file can't exceed 1 MB." "The class name must be Script and it must implement ScriptBase." "Not all C# namespaces are supported. Currently, you can use functions from the following namespaces only." (custom-connectors/write-code, seen 2026-08-25). One script per connector, and the same page excludes the on-premises data gateway and bounds its SendAsync call to public endpoints. The licence then follows the code into every flow that touches it: "You must have a premium or trial license to run any flow that uses a custom connector" (limits-and-config, last updated 07/17/2026, seen 2026-08-25). For a SaaS company shipping the integration to its own customers, that gate lands on each customer's users rather than on your build. The unbounded version is a different product. Azure Logic Apps Standard lists "Inline JavaScript, C#, and PowerShell", "Custom .NET code" and "Call Azure Functions"; the Automation SKU adds "Full code-first development"; Build 2026 announced "Public Preview: Codeful Workflows with the Logic Apps Standard SDK ... create workflows directly in code using familiar .NET development patterns". Taking that hatch means moving your customers' integrations onto Azure resources with Azure billing, a separate designer and separate ALM. It is a migration, not a setting.
Logic complexity does not convert into code ownership. The awkward rules that make your business yours stay inside a model that your people can read, your tests can cover, and your AI can safely change.
Forcing any branch with static results, replaying real trigger data inside the run window, and testing a child flow on its own are all documented, so the mechanics of testing are parity. The reach is what differs: replay is per run, self-invoked and 30 days deep ('Run retention in storage | 30 days'), the impact query stops at your own tenant now that ISV Studio was 'removed on May 31, 2024', and the agent's guard is a per-call prompt, not a read-only production posture.
"It worked when I tried it" tests one path out of eleven. The other ten are where customers live. This act is the answer to the third standing test: when the AI, or a person, gets something wrong, what in the architecture catches it before production data does?
The AI tests every branch before it ships. Not the branches somebody thought to write payloads for. Every branch.
Ship a one-line fix across 300 accounts knowing exactly which customers it touches. Elsewhere, the impact query stops at your tenant boundary
Open the scenarioA one-line connector fix silently changed behaviour for three hundred accounts.
Beacon, a B2B SaaS vendor with 300 customer accounts live. A date-format bug is found in a shared connector operation. The fix is one line. The question that separates a routine Tuesday from an incident: which automations call this operation, on which customers' accounts, and which of them are relying on the buggy behaviour without knowing it?
The one-line fix ships with a printed list of everyone it touches, so the dependents are known before the edit rather than after it.
Inside your own tenant this question has a good answer, and it should be conceded before the boundary is named. Power Platform inventory documents "Map connector usage (preview): Find which apps, flows, and agents use a given connector or operation. Use this information to scope DLP, audit Premium connector adoption, and plan ahead of deprecations, security issues, or licensing changes", with "Fast updates: Created, updated, or deleted resources appear within 15 minutes" (power-platform-inventory, last updated 08/06/2026, seen 2026-08-25). Pipelines add a check on the receiving side: "Solution deployments are prevalidated against the target environment to prevent mistakes and improve success rates."
The boundary is where a SaaS company's customers actually sit. The pipelines FAQ answers "Can pipelines deploy to a different tenant?" with "No. We recommend using Azure DevOps or GitHub for this scenario", so three hundred customers are three hundred tenants and the inventory covers yours. We searched the inventory page, the pipelines documentation, the solution ALM concepts, the embedding guide, the licensing FAQ and the 2022 ISV pay-as-you-go blog for a cross-tenant view of who runs a given connector or flow; the per-customer inventory Microsoft did publish for ISVs, ISV Studio, was retired on 31 May 2024.
So when a vendor deprecation notice arrives, the in-tenant query answers for your own environments in minutes, and the same question about customer tenants is reassembled from whatever your install-time scripts happened to record.
You know a change is fully tested because the platform counts untested paths, not because someone felt confident. Elsewhere, not documented; on that basis coverage is what your team remembers to try
Open the scenario"It worked when I tried it" tested one path out of eleven.
The claim-intake automation has eleven branches. The claims supervisor signed off on a mapping change because the hail path ran clean in test. Harvest starts in five weeks and ten were never walked.
The platform knows every branch an automation has and tracks which ones testing has actually exercised. Coverage is measured, not assumed. A change ships when the walk is complete.
Microsoft Power Automate does not document a coverage report for a cloud flow. We searched the Test your cloud flows page, the cloud flow designer and error-checker documentation, the 2026 wave 1 and 2025 wave 2 release plans, and the test-suite command in Microsoft's own FlowAgent MCP server, which runs a configured set of flows and publishes no coverage output. The nearest release-plan item, "Test subflows with test suite" (GA 13 May 2026), sits under desktop flows rather than cloud flows. On that basis, knowing which of the eleven branches a test run left untouched is manual work rather than a platform behaviour, and it stays a matter of what your team remembers to try as the team changes. The loop this sits inside is documented, and it compounds the gap: "Can drafts be tested? Not at this time. Currently, flow changes need to be published and runnable to be tested" (drafts-versioning, last updated 03/20/2026, seen 2026-08-25). The run that would have exercised the rare branch happens on a flow that is already published.
Answer a month-old complaint by re-firing the exact message that failed. Elsewhere, replay is per run, self-invoked, and 30 days deep
Open the scenarioTesting a webhook-triggered flow meant asking a customer to go and click something in their system.
An undocumented rate-confirmation payload began dropping accessorial charges worth 18,000 euros a week. The fix is written. Validating it means asking a shipper to re-tender loads they already moved.
Every webhook ever received is a test case. Re-fire last month's payload against the fixed automation and watch it process, without asking a customer to reproduce anything.
Replaying last month's production traffic is bounded by how long that traffic still exists, and by who caused it. "Run retention in storage | 30 days ... Run retention is calculated using a run's start time" (limits-and-config, last updated 07/17/2026, seen 2026-08-25). The Dataverse copy of run history whose retention can be extended holds summary metadata, not per-action inputs and outputs, so a month back is the outer edge of what replays with its payloads intact. Resubmit itself is real and agent-callable, and that is worth conceding plainly: FlowAgent's resubmit_run "Resubmit a past run using its original trigger inputs (the trigger is auto-detected from the run)", and the Management connector ships "Resubmit Flow | Resubmit the given flow run in an environment." The bounds sit on the same pages: "You can resubmit or cancel up to 20 flow runs at a time", a count the page says is further bounded by the connectors' API call limits, and "Users can always resubmit their own flow runs initiated by instant triggers. To allow users to also resubmit flow runs initiated by other users, enable the Power Automate flow run resubmission setting in the Power Platform admin center." Deeper history and finer replay are the Azure Logic Apps answer: 90-day default run retention, raisable to 365 days in Standard, plus rerun from a chosen action, which carries its own limitations, "The workflow must have 40 or fewer actions for you to rerun from a specific action", "These capabilities currently are unavailable with Visual Studio Code or Azure CLI", and "The resubmitted run executes the same workflow version as the original run, even if you updated the workflow definition" (view-workflow-status-run-history, last updated 03/02/2026, seen 2026-08-25). That is your customers' integrations rehoused on a different product with Azure billing and its own ALM.
An agent works production with full read, and the actions that reach a fleet return a plan a human approves. Elsewhere, the guard is per call, not a production posture
Open the scenarioThe fastest way to an outage is a confident agent with production credentials.
An AI agent is to work directly on production integrations posting 2,600 ACH transactions a night. One mis-sequenced deploy at 11pm is a reportable incident by the time branches open.
The AI inspects production freely and changes nothing without an explicit, human-confirmed deploy step. Autonomy without the blast radius.
The safety on Microsoft's agent surface is per call and opt-in, decided by whoever is at the keyboard, rather than a posture the production environment holds on its own. The per-call guards are genuine and worth having. FlowAgent's preview_update is described in the shipped server as "Read-only: compute a diff between the live flow and the proposed update body, and return a short-lived single-use token. Use the token with update_flow to apply the change only if the proposal still matches what you reviewed. No mutation is performed by this tool." Backups are automatic, "List pre-mutation backup snapshots captured for a flow. Newest first. Last 10 retained per flow", the build skill creates flows in a Stopped state, and pipelines offer "Secure production environments with approval based delegated deployments" (FlowAgent mcp.mjs and skills, seen 2026-08-25; pipelines, last updated 01/12/2026). What is not documented is a production tool set that cannot write. We searched FlowAgent's README, AGENTS.md, CLAUDE.md, its ten skill files and every tool description in the shipped server: "Read-only" appears on two tools, diagnose_run and preview_update, and not as a mode. All 55 tools are granted to every skill, with delete_flow and publish_flow present in the diagnosis skill, and Microsoft's own README states "Auto-approval options give the agent the same access you have on your machine. Only use these in trusted or sandboxed environments." The tenant-level control that does exist, data loss prevention, classifies connectors rather than callers, blocking a connector for makers and agents alike, and Microsoft puts its worst-case propagation at "the latency for full enforcement is 24 hours" (wp-data-loss-prevention, last updated 04/08/2026, seen 2026-08-25).
Test coverage is a property of the platform, not of your team's imagination for payloads. Across months of daily production builds on APIANT, no hallucinated mapping, structure, or logic has been observed reaching production. That is what the compiler and the branch walk are for.
Mapping which flows use a connector inside one tenant is documented, and that row goes. Shipping to a fleet is where the model stops: 'Can pipelines deploy to a different tenant? No', each customer is a separate tenant whose capacity 'can't be pooled', one connection is shared among a flow's users while every new environment asks again, and versions carry no side-by-side diff, expire at six and twelve months, and redeploying an older one is 'an irreversible operation'.
Building the integration once is the demo. Running it for three hundred customers, each configured differently, each on their own credentials, all needing the same fix on the same day, is the business. This act is where per-customer platforms and per-fleet platforms part ways.
Ask the AI to ship the fix and it deploys to 232 linked accounts on your confirmation of the plan it returns. Elsewhere, each customer is a separate tenant, and capacity meters per licence, not per platform
Open the scenarioEvery customer wants the same integration configured differently, and cloning it per customer creates hundreds of divergent copies.
One codebase carries the logic. Settings (which fields sync, which features are on, time zones, branding) vary per customer. The same automation serves a single-location studio and a 232-location franchise.
A fitness franchise with 232 locations runs a booking-system-to-CRM integration at every site. Each location has its own booking credentials and its own quirks (time zones, membership names, feature toggles), but the logic is identical everywhere. Today, a fix needs to reach all 232 before the evening class rush. This is a real deployment shape running on APIANT now.
Fix at 2pm, fleet-wide by 2:15, evening classes uneventful.
Configuring one build differently per customer is well designed here, and the unit it configures is an environment inside your own tenant. Credit the mechanism plainly: "Environment variables are parameters that can store configuration settings like URLs, API keys, and connection strings ... which is helpful when you move your flows between environments that require different configurations", pipelines "deploy solutions as well as configuration for the target environment such as connections, connection references, and environment variables", and a value your customer set survives your next release: "When the application publisher publishes updates to the application, the value set by the customer isn't overwritten." (learn.microsoft.com, seen 2026-08-25.)
For a SaaS company shipping integrations to its own customers, the boundary matters more than the mechanism. A customer is a separate Microsoft Entra tenant, deployment is one environment at a time, and the pipelines FAQ answers "Can pipelines deploy to a different tenant?" with "No. We recommend using Azure DevOps or GitHub for this scenario." One build for hundreds of customers becomes hundreds of installs, each holding its own copy of the solution. (pipelines, seen 2026-08-25.)
Capacity is metered on the same shape. Licensed request capacity runs per user, 40,000 requests per 24 hours on Premium, or per Process licence, 250,000 per day, assignable to one flow or shared by a flow group of up to 25 solution-aware flows since July 2026, and Microsoft states this capacity "can't be pooled at any other level like environment or tenant levels." The tenant-pooled allowance that does exist covers non-licensed identities such as service principals, at 25,000 base requests per 24 hours for Power Automate. (api-request-limits-allocations, seen 2026-08-25.)
One incoming request lands in the right location's account, on that location's own credentials, with hundreds of accounts behind the curtain. Elsewhere, not documented; on that basis locations get wired by hand
Open the scenarioThree hundred locations cannot each hold their own credentials and configuration.
Kestrel Pharmacy Group's 178 branches share one refill endpoint, with the store code buried in the payload. The first batch lands at 6:40am, and every message has to reach the branch that can fill it.
A parent account governs hundreds of children. A webhook hits the master, which routes by location to the right child, which processes with its own credentials. The caller never knows there are 232 accounts behind the curtain.
Three hundred locations have to sit somewhere in the model, and the documented hierarchy runs tenant, environment, solution, flow. The nearest grouping construct, environment groups, carries governance rules and settings across many environments; no page describes it routing work, credentials or configuration from a parent account down to child locations, and it carries no deployment verb of its own. (environment-groups, seen 2026-08-26.) Microsoft Power Automate does not document this. We searched the environments admin overview, environment-architecture, create-team-flows, connect-to-other-environments, flow-groups, solution-concepts-alm and environment-groups. On that basis routing work from a parent account to child locations is manual work rather than a platform behaviour.
One CRM login covers every location while each site keeps its own booking login. Elsewhere, one connection is shared among a flow's users; each new environment asks again
Open the scenarioRe-authenticating per location does not scale past about twenty.
Southern Reef Dental's 96 practices each hold their own practice-management login, but the one group CRM token expires every 90 days. Re-authorising clinic by clinic has cost three weekends.
One CRM credential, flagged shared, serves all 232 locations, while each location keeps its own booking-system credential. Sharing is a toggle on the hierarchy, alongside shared settings and shared automations.
Credential sharing is documented at the flow, and it stops at the flow's edge. What exists is real and worth stating: "As an owner, you can specify whether run-only users need to provide their own connections or you can use a connection already defined in the flow" (create-team-flows, seen 2026-08-25), connection references let solution-aware flows bind to a connection rather than embed one, and pipelines support service principal connections "for connectors that support service principal authentication, including custom connectors." At the location boundary the question gets asked again. Every solution import into a new environment is where connections are chosen: "If your solution contains connection references, you're prompted to select the connections you want. If a connection doesn't already exist, create a new one" (import-update-export-solutions, seen 2026-08-25), and OAuth connections require the connection owner's browser consent in a Microsoft surface. The documentation therefore describes sharing among the users of a flow inside one tenant. It describes no inheritance in which one credential is set once at a parent and hundreds of child locations run on it while keeping the rest of their credentials separate.
A week of hand-updating becomes one confirmed action, staged if you prefer, with every prior version kept for a redeploy. Elsewhere, cross-tenant is answered with no; the fleet route is AppSource opt-in or scripts you own
Open the scenarioShipping a fix to two hundred customers by hand takes a week and misses some.
A payment provider renamed a field overnight and refunds have been failing since 05:00. The head of support has the fix in hand and 186 venue environments to get it into before Friday's 10am on-sale.
Deploy or upgrade a codebase group across the fleet in one action, atomically, with staged rollouts when you want caution and instant rollback when you need it.
Shipping one fix to two hundred customers is one solution import per customer tenant, repeated, and each repeat is yours to drive. Inside your own tenant the ALM story deserves credit: pipelines "Deploy a solution with a single command", prevalidate the target, gate production behind approvals, and retain every deployed artifact in the pipelines host. The edges sit on the same pages: each stage targets a single environment, "The same solution artifact must pass through pipeline stages in sequential order", the FAQ adds "Can I deploy multiple solutions at once? Not currently", "When a solution is being imported, the flows in that solution are turned off and turned on again", and "All other environments used in pipelines must be enabled as managed environments" holding premium-use licences, which Microsoft began enabling automatically for pipeline targets in February 2026. (pipelines; import-flow-solution; seen 2026-08-25, re-checked 2026-08-26.) Across tenants the FAQ is one word: "Can pipelines deploy to a different tenant? No. We recommend using Azure DevOps or GitHub for this scenario", which means a script you write and own, on Azure DevOps, GitHub, or Microsoft's Terraform provider, whose solution resource targets one environment per instance and whose maintainers say it "is not intended to replace ALM processes". The other documented route is AppSource, where each customer tenant's admin installs and updates the package; concede the automatic path, because it exists: a 2022 public-preview announcement states "As an ISV, you do not require additional action to enable automatic updates for your apps. Only tenant admin users are required to act by opting-in to this feature for select publishers from the Power Platform Admin Center.", applied during dark hours, and its linked documentation pages now redirect to a removal notice. Since "ISV Studio was deprecated on April 1, 2024 and removed on May 31, 2024", no per-customer outcome inventory for a rollout is documented. If you build the integrations as Azure Logic Apps instead, Azure Lighthouse is a documented cross-tenant control plane, "use Azure Lighthouse to manage your customers' Azure resources from within your own Microsoft Entra tenant", though deployments still run one delegated subscription at a time with no documented fleet transaction or per-customer rollout report, and cloud flows shipped as Dataverse solutions are outside its reach. That escape hatch is a different product with Azure billing and its own operational model.
Ask the AI what changed and it diffs the bad version against the last good one; the reversal is a redeploy of that kept version to the fleet. Elsewhere, no side-by-side diff, versions expire at six and twelve months, redeploy is labelled irreversible
Open the scenarioA change made things worse, and there was no way back.
The night before enrolment week, the integrations lead changed how guardian contacts are matched. Registrars in six districts are seeing siblings collapsed into one record, and offices open at 07:30.
Every committed version is kept, any two versions diff against each other, and rollback restores a known-good state fleet-wide in one action.
When a change makes things worse, the route back is narrower than the route forward. What exists: solution-aware cloud flows build a version history in Dataverse with restore as a new draft, pipelines automatically export and store every deployed solution in the host, and Microsoft's FlowAgent MCP server restores pre-mutation backups, "Last 10 retained per flow". (drafts-versioning; pipelines; FlowAgent mcp.mjs; seen 2026-08-25.) Comparison and retention are where the documentation sets the limits: "A side-by-side comparison of versions isn't available at this time", notes and titles "can't be added to the version at this time", "Timestamps are used to differentiate between versions", and "Draft records expire after six (6) months, and published records expire after 12 months." The feature set covers solution-aware cloud flows. The "Compare flow versions" item that reached GA in May 2026 is a desktop flows feature, not cloud flows. (drafts-versioning, last updated 03/20/2026, seen 2026-08-25.) Reversing a deployed solution is per environment, behind the "Allow redeployments of older versions" pipeline setting and a minimum pipelines package version, and Microsoft's own page states the cost of the reversal: "Redeploying overwrites the most recent version and any data within that version. This is an irreversible operation, and the data lost is unrecoverable. Updates, including new tables, will also be removed." (redeploy-past-solution-versions, seen 2026-08-25.)
A new account is created, linked, and inheriting shared logins, settings and automations in one operation, with no onboarding checklist to work through. Elsewhere, the 2022 embed promise has no one-operation path in the current documentation
Open the scenarioOnboarding a customer was a manual checklist.
Twelve newly acquired hotels each need their management system talking to the group's revenue and CRM stack before the 1 October rebrand. The onboarding checklist runs 31 steps per property.
A new customer account is created, linked into the hierarchy, and inherits shared connections, settings, and automations immediately. Provisioning is an operation, not a project, and the AI can run it.
Onboarding customer N plus one is where the marketing and the documentation part company. Microsoft's 2022 ISV pay-as-you-go blog promises "You simply embed the capabilities you want to extend to your customer and sell and deploy it as a unified offer." The 2026 documentation around the same scenario reads differently: setup widgets are iframes into make.powerautomate.com requiring a Microsoft identity, the licensing FAQ says a guest user "must have a Power Automate license assigned", and the current pay-as-you-go overview, last updated 09/18/2025, contains no occurrence of "ISV" or "embed". Quote both and date both. (2022 blog; licensing FAQ, last updated 08/14/2026; pay-as-you-go-overview; seen 2026-08-25.) Microsoft Power Automate does not document this. We searched the licensing FAQ, the licensing types page, embed-flow-dev, pipelines, power-platform-inventory and the pay-as-you-go overview, plus a docs-map search for the ISV embed program that returned the 2022 blog and a community thread. On that basis provisioning a new customer, meaning the environment, the solution and the connections together, is manual work rather than a platform behaviour, assembled per customer from separate admin steps.
A regional manager sees their 30 locations, support can look without touching, the master admin sees the whole franchise. Elsewhere, the support role sees no action-level detail; the documented workaround grants edit rights
Open the scenarioSupport needed to see a customer's runs without being able to change them.
Rent posting has failed at one of 340 buildings. The support desk has to inspect the run without changing owner data, and one owner's contract forbids staff on another portfolio from viewing a record.
Administrators, builders, viewers, scoped by account: the regional manager sees their 30 locations, the master admin sees all 232, support sees without touching.
Support that can look without touching is exactly what the operator role was built for, and its own page marks where the looking stops. Concede the design: "Operators aren't makers, they can't create or edit flows, but they have extended visibility and control over operational aspects." (operator-role, last updated 07/27/2026, seen 2026-08-25.) The same page lists what the role cannot reach on a customer problem. Operators cannot "View per-action inputs and outputs within a flow run", cannot "See expression evaluation results or retry details", cannot "Access the full trigger payload", and cannot "Resubmit or cancel a cloud flow run". Coverage also depends on how the flow was built: "The FlowRun table is populated only for cloud flows that are part of a Dataverse solution ... Operators have no visibility into executions of non-solution cloud flows through this role." Microsoft's own workaround table names the trade: sharing the flow as co-owner "Grants edit permissions, which reduces separation of duties." Diagnosing a customer issue at action level therefore means giving support edit rights, or routing the question back through the flow's owner.
Customer three hundred costs what customer three cost. Growth in breadth, more customers, more locations, does not multiply your operational surface, and does not show up as a per-deployment line item on the platform bill.
Cancelling a run, querying your own run data and auditing who changed what are documented and agent-reachable, and those rows go. The residue is day two at scale: full run detail lasts 30 days and 365 days means moving to Logic Apps Standard on Azure billing, a flow whose trigger or actions fail continuously is turned off after 14 days, resubmit moves twenty runs at a time, a bulk cancel "can take up to 24 hours", and the support role that avoids edit rights cannot see action inputs or outputs.
Nobody buys an integration platform for month one. The purchase is really years two through five: the customer reports, the API drift, the 2am incidents, the person who left. Every platform demos the build. This act is about everything after the demo, which is where the money is, and where architectures stop being interchangeable.
Answer a three-week-old customer complaint before standup: find the run, fix it, prove it, ship to all 90 sites. Elsewhere, full run detail lasts 30 days; 365 days means moving to Logic Apps Standard on Azure billing
Open the scenario"It did not work for this one customer last Tuesday" was a multi-day archaeology project, and often unanswerable.
6:51am, a support inbox. One location of a 90-site franchise writes: "A member signed up on June 30 and she never showed up in our CRM. She's furious. What happened?" It is July 21. Three weeks ago. The platform has run hundreds of thousands of executions since. Somewhere in there is one run that did something wrong to one record, and a customer is waiting to find out whether you are the kind of vendor who can answer.
All of it directed conversationally, by one person, before the 9:30 standup. The reply to the location: what happened, why, fixed, and here are the other three members we caught and restored.
A support question about one customer's failure three weeks ago runs into a 30-day wall, with summaries after it. "Run retention in storage | 30 days | Run retention is calculated using a run's start time." The Dataverse FlowRun copy whose retention is configurable holds summary metadata, run status, start and end time, duration and a summary-level error, not per-action inputs and outputs. Telemetry export to Application Insights is "turned on and supported for managed environments only" and is, in Microsoft's words, "not 100% lossless." (limits-and-config, last updated 07/17/2026; cloud-flow-run-metadata; app-insights-cloud-flow; seen 2026-08-25. Note that the bulk-resubmit page still describes a "28-day run history list", so two Microsoft pages disagree by two days.)
The documented way to hold history longer is a different product. Azure Logic Apps documents 90-day run retention by default, raisable through Logic Apps Standard's Workflows.RuntimeConfiguration.RetentionInDays setting to a maximum of 365 days. Taking that route means rebuilding the flows as Logic Apps workflows on an Azure resource Microsoft describes as "billed for reserved capacity and dedicated resources whether or not you use them", with Azure billing and a second operational surface alongside your Power Automate licensing.
"It didn't work for one customer last Tuesday" stops being a week of archaeology. It becomes a conversation.
A real deployment went from 140 alerts a day to 3. Elsewhere, its own alerting is a per-flow on or off switch, with a 28-day cooldown and owner-only delivery; threshold rules and routing live in Azure Monitor
Open the scenarioAlerting was either silent or so noisy that everyone stopped reading it, which is the same thing.
A platform team's alert channel gets 140 integration alerts a day. A hundred and thirty-eight are a flaky sandbox and a vendor's nightly maintenance window. Two are real. The humans did the rational thing months ago: they muted the channel. Last Thursday, one of the two real ones sat unread for nine hours while a customer's orders silently queued.
Three alerts a day, each one real, each one read. The channel gets unmuted.
Power Automate documents one control over the alerting it sends, and it is a per-flow switch: "Per-run failure alerts aren't enabled for all flows by default. If you aren't receiving any failure alert emails for your flows, verify that failure alerts are turned on in the flow settings." What that email does once it is on, the same page sets out plainly. It fires only "when the system identifies a known, fixable issue", and "If the system can't identify a specific fix for the failure, no per-run alert email is sent." Then: "After a per-run alert email is sent for a flow, there's a 28-day cooldown period before another per-run alert can be sent for the same flow. No other alerts are sent for that flow until the cooldown expires", and "Failure alert emails are never sent to environment admins or tenant admins. Only users who own or co-own the flow receive per-run alerts." A weekly digest covers all failures regardless of type, and the admin center's Monitor experience "shows every failed run with no exclusions". (understand-flow-failure-notifications, last updated 04/03/2026, re-scraped 2026-08-26.)
On the agent surface that switch has no counterpart we could find. Across all 98 platform-operation tool entries, FlowAgent's 55 tools, both management connectors, pac, the Dataverse Web API and the ARM REST API, no verb turns per-run failure alerts on or off, sets a threshold, routes a destination, defines a suppression window or maps an error message on a Power Automate cloud flow; the Management connector's Update Flow schema carries no notification field (re-verified 2026-08-26). Concede what does exist, because it is real and scriptable: configurable alerting on cloud flow failures runs outside Power Automate, where a managed environment exports run telemetry to Azure Application Insights and alert rules, destination routing and suppression windows are set through Azure Monitor's documented CLI and REST surfaces on an Azure subscription with Azure billing, and Logic Apps runs are alertable the same way. The admin center's Monitor area adds threshold alerts on 24-hour aggregate metrics, also for managed environments.
So the tuning Power Automate itself documents is the switch and the ownership list: per-run alerts on or off per flow, delivered to whoever owns or co-owns it. For thresholds, suppression windows with an audit of what is suppressed, retryable-error lists and per-step alert mapping inside Power Automate, we found no published statement; we searched understand-flow-failure-notifications, fix-flow-failures, automation-center-overview and the coding-guidelines pages on monitoring and alerting and on error handling. The documented route to anything narrower is building your own notification actions inside each flow, which Microsoft's own guidance warns "can result in excessive custom logging and an increased number of actions".
Ask once and 180 automations across a parent and 60 children are snapshotted and disabled, then restored exactly as they were. Elsewhere, cancel names one flow, and the page says it can take up to 24 hours.
Open the scenarioWhen an upstream vendor breaks, the choice was between flooding a broken API and losing track of what to turn back on.
Tuesday, 11:40am: a CRM platform your customers depend on goes down hard. Across one parent account and its 60 child accounts, 180 automations are hammering a dead API, burning retries, and generating an alert storm. Every minute they keep running makes the eventual recovery messier. But some of those automations were off already, on purpose, and when the vendor recovers you must restore exactly the previous state, not "turn everything on" and reawaken the three that were disabled for good reasons.
Total human attention: minutes at the start, minutes at the end. No flood, no amnesia.
Concede the mechanism plainly: an incident-response bulk cancel exists, and an agent can call it. "Bulk cancel lets you cancel all flow runs in the Running or Waiting state at once, without selecting them individually. This is useful during incidents with many erroneous flow runs", with the shutdown offered on the same action, "Optionally, select the checkbox to turn off your flow so you can address the underlying issues that trigger faulty runs" (how-tos-bulk-resubmit, seen 2026-08-25). FlowAgent wraps it: cancel_all_runs will "Bulk-cancel every in-progress run of a flow, for incident response when many erroneous runs are queued ... Optionally turns the flow off afterwards (turnOff)" (repo at v3.0.4, seen 2026-08-25).
Two published facts set what that costs during a real outage. Scope: each of those actions names one flow. Clock: "This process can take up to 24 hours", and "If a flow is turned off, pending canceled flows remain Waiting, and the queue doesn't clear until the flow is turned back on." Turning a flow off does not stop what is already moving: "When you turn off a cloud flow, no new runs start. All in-progress and pending runs continue until they finish" (limits-and-config, last updated 07/17/2026).
At fleet scale that shape is a loop, and Microsoft's own agent skill writes it out: "Batch disable: Call disable_flow per flow ... Report per-item success/failure" (manage-flows skill, seen 2026-08-25). Coming back up is the same per-flow call in the other direction, "Enable Flow as Admin" in place of "Disable Flow as Admin".
Transient blips retry themselves while broken credentials stop instead of hammering a customer's API, set once for the whole tenant. Elsewhere, the retried set, 408, 429 and 5xx, is printed on their Logic Apps page, and no page documents a customer-defined list
Open the scenarioTransient failures were treated as fatal, and genuine auth failures were retried forever.
At 03:10 transient 502s marked 340 overnight freight tenders fatal, while an expired token retried until that carrier's account locked. Trucks unassigned past 07:00 come off the contract rate.
Retryable error classes are tunable tenant-wide, auth failures on named domains get carve-outs, and automatic shutoff behaviour is a policy you set, not a surprise you discover.
Which failures get another attempt is decided by the platform, not by your team. Say plainly where the statement lives: the retry policy that Power Automate's limits page configures per action is described on Microsoft's Azure Logic Apps exception-handling page, which states "If the trigger or action's original request times out or fails, resulting in a 408, 429, or 5xx response, the retry policy specifies that the trigger or action resend the request per policy settings" (logic-apps-exception-handling, seen 2026-08-25). We found no Power Automate page that prints the status-code set, and we looked in the limits-and-config retry section and the error-handling guidance for one. What you configure per action is the shape of the retry, not what sets it off: "Retry attempts | 90", "Retry minimum delay | Five (5) seconds", "Retry maximum delay | One (1) day" (limits-and-config, last updated 07/17/2026). An expired OAuth token returning 401, a 409 conflict, a vendor's 422 on one malformed record: those sit outside that response set, and the retry documentation describes no customer-defined list of retryable errors or messages, and no per-domain exception. We searched the limits-and-config retry section, that Logic Apps exception-handling page, the error-handling guidance and the 55 tool names shipped in Microsoft's FlowAgent MCP server. The platform then acts on continuing failures for you: "Flows with errors | 14 days | A cloud flow that has a trigger or actions that fail continuously is turned off" (limits-and-config, seen 2026-08-25). For a company whose customers' credentials expire on their own schedule, a customer's integration going dark is a platform rule rather than a policy your team wrote.
After an outage, hundreds of failed records get reprocessed from one screen instead of by hand. Elsewhere, twenty runs per resubmit, and the connectors' API call limits bound the count further.
Open the scenarioAfter an upstream outage, hundreds of records needed reprocessing, and there was no safe way to do it in bulk.
A Saturday outage left 2,600 prescription-refill requests failed on the way to the dispensing system. The operations manager has Sunday and two staff before patients walk in Monday.
See every failed run, inspect what each was carrying, and retry them in bulk once the cause is fixed, from the same surface, at any scale.
After an upstream outage, putting the failed records back through is a paged, hand-selected job. Microsoft's bulk resubmit page: "You can resubmit or cancel up to 20 flow runs at a time", and on the same page, "The number of flow runs that you can resubmit is limited by the maximum number of API calls for the connectors in the flow" (seen 2026-08-25). Who may press it is gated too: "Users can always resubmit their own flow runs initiated by instant triggers. To allow users to also resubmit flow runs initiated by other users, enable the Power Automate flow run resubmission setting in the Power Platform admin center." Concede the agent surface, because it is real. FlowAgent's resubmit_run will "Resubmit a past run using its original trigger inputs (the trigger is auto-detected from the run)", and Microsoft's own manage-flows skill carries the caveat in the same breath: "only self-invoked runs are resubmittable per PA policy" (repo at v3.0.4, seen 2026-08-25). It is one run per call, and the Power Automate Management connector it works through is published at "API calls per connection | 5 | 60 seconds". Restarting from the step that failed, rather than from the top, is documented on Azure Logic Apps with its own limitations quoted there: "You can rerun only actions from sequential workflows", "The workflow must have 40 or fewer actions for you to rerun from a specific action", "These capabilities currently are unavailable with Visual Studio Code or Azure CLI", and "The resubmitted run executes the same workflow version as the original run, even if you updated the workflow definition" (last updated 03/02/2026). Reaching that means running the integration on a different product, as an Azure resource with Azure billing, rather than changing a setting where it lives now.
Catch a silent backlog before the customer calls: work that arrived but never ran has its own screen. Elsewhere, the queue ceiling is published; a view of what never became a run is not.
Open the scenarioSilent backlogs: everything looks healthy, and nothing is moving.
At 08:10 the dispatcher finds 430 missed-pickup webhooks arrived overnight and never moved past the door. Every status board was green, and the trucks left the yard without the reroutes.
The queue of arrived-but-unprocessed events is a first-class view. "Received but stuck" is visible before a customer notices the gap.
A backlog here is silent by construction: the dashboard looks healthy because the runs that would have shown the problem were never created. Microsoft documents the condition that produces it. "Waiting runs | Not applicable when Concurrency Control is off; 10 plus the degree of parallelism (1-100) when Concurrency Control is on", and in the same note, "Additional triggers that arrive while the waiting runs limit is met might be re-tried by the connector. However, the retry attempts might not succeed if the maximum waiting limit continues to be met for an extended period of time. To ensure all triggers result in flow runs, leave the Concurrency Control setting off in the flow's trigger" (limits-and-config, last updated 07/17/2026). The remedy is a design decision taken before the incident, and the setting is one-way: "Turning on Concurrency Control can't be undone without deleting and re-adding the trigger." What is missing is the view. Microsoft Power Automate does not document this. We searched limits-and-config, see-a-flow-run, the automation center overview, the Dataverse cloud flow run metadata page and the bulk resubmit page. On that basis it is manual work rather than a platform behaviour: reconciling the source system's records against run history by hand. Azure Logic Apps does publish such a view, and it is worth naming: "For a stateful workflow, you can review the trigger history for each run, including the trigger status along with inputs and outputs, separately from the workflow's run history" (view-workflow-status-run-history, last updated 03/02/2026). It sits on the other product, so reaching it means building the integration on Azure Logic Apps, with its own Azure resource and bill, rather than turning something on where the flow already runs.
Type a customer's email or order number and land on the runs that touched it across every account. An hour of log reading becomes a minute. Elsewhere, filters read run metadata; the payload is fetched run by run, against a read meter.
Open the scenarioCorrelating a failure across accounts meant reading logs by hand.
Claim AV-2291884 was acknowledged to the policyholder but never reached the loss adjuster, and the regulator's clock runs out Monday. Nobody knows which of 74 broker accounts it passed through.
Search every account at once for a value, a client ID, an email, an order number, and land on the runs that touched it. Correlation is a query, not a shift.
To find one customer's record across a fleet you search what the platform recorded about the run, not what was inside it. The documented search surface is Azure Application Insights: "Select Add filter and select ResourceId to select triggers and actions for specific flows" and "Select Add filter and select Operation Name ... These filters are the same as the display names of triggers and actions" (app-insights-cloud-flow, last updated 09/18/2025, seen 2026-08-25). Two gates sit on the same page: "This feature is turned on and supported for managed environments only", and "The logs powering the Power Automate telemetry in Application Insights aren't transactional data and hence are not 100% lossless." Searching by the data itself, a customer identifier sitting inside an action's output, is a different question. Microsoft Power Automate does not document this. We searched see-a-flow-run, the automation center overview, the Dataverse cloud flow run metadata page, app-insights-cloud-flow, and FlowAgent's tool list, where get_run_history filters on run metadata. On that basis it is manual work rather than a platform behaviour. That manual route is itself metered and time-boxed: "Read calls per 5 minutes | 6,000 for Low; 60,000 for all others | This limit applies to calls that get the raw inputs and outputs from a cloud flow's run history", inside the window the same page sets at "Run retention in storage | 30 days" (limits-and-config, last updated 07/17/2026).
Know which customers are heavy, erroring, or growing before renewal talks and capacity planning, per account, on demand. Elsewhere, counted per licensed user and per flow; the solution flows you ship sit outside the analytics reports.
Open the scenarioCapacity and billing questions had no ground truth.
The controller is closing the quarter with two customers disputing invoices and one that grew fourfold on its entry plan. The numbers came from three hand-built exports; sign-off is Thursday.
Which customers are heavy, which are erroring, which are growing: per-account ground truth, queryable by your team and your AI, exportable to your monitoring stack.
The numbers exist. What costs you is the unit they are counted in: a licensed user or a flow, never a customer. "To prevent a usage-heavy flow or user from impacting other users, the system tracks this capacity based on consumption at an individual user or flow level and it can't be pooled at any other level like environment or tenant levels" (api-request-limits-allocations, seen 2026-08-25). The report reads accordingly, with fields "Caller ID | The unique identifier of the flow", "Entitled Quantity" and "Consumed Quantity | Usage of Power Platform requests". The sharper line is an exclusion: "Solution-aware flows (flows created as part of a solution) are currently not included in analytics reports" (analytics-flow, seen 2026-08-25). Solutions are what the rest of the documentation requires of a flow you ship. Child flows need one ("You need a solution with two flows"), "The drafts and versioning feature set is available only for solution-aware cloud flows", pipelines deploy solutions, and "Flows must be in a solution for a Process license to be assigned." The flows in the fleet are therefore the flows outside the analytics report. Concede the health surface, which is genuine: the automation center publishes "Flow runs error rate" and "Top flow runs", with "Recommendations ... requires a Managed Environment", and licensing capacity reporting reached the admin center in March 2026, "giving admins a single place to see which users are over capacity and which flows are driving that usage".
Support sees what the customer sees and fixes it there, without ever asking for a password. Elsewhere, the support role that avoids edit rights cannot see action inputs, outputs or retry detail.
Open the scenarioSupport asking customers for passwords is both a security problem and a delay.
Recall reminders stopped Friday and a practice manager has 90 patients unconfirmed for this week's chairs. The playbook is her login, which your security policy forbids, or two days for an engineer.
Support switches into the customer's account context with its own audited access, sees what the customer sees, and never asks for a password.
The role Microsoft built for exactly this cannot see enough to diagnose a failure, and the documented workaround is edit rights on a customer's live flow. The operator role page (last updated 07/27/2026) opens well: "Operators aren't makers, they can't create or edit flows, but they have extended visibility and control over operational aspects." It then lists what an operator cannot do: "View per-action inputs and outputs within a flow run", "See expression evaluation results or retry details", "Access the full trigger payload (inputs and outputs)", "Resubmit or cancel a cloud flow run." Microsoft's own workaround table names the trade: "Share specific flows as co-owner with the operator | Grants edit permissions, which reduces separation of duties." A second cut sits on the same page: "The FlowRun table is populated only for cloud flows that are part of a Dataverse solution. Non-solution cloud flows don't write run metadata to Dataverse. Operators have no visibility into executions of non-solution cloud flows through this role." The admin route is genuine and should be conceded: "Get Flow as Admin", "List Flows as Admin (V2)", "Disable Flow as Admin", "Enable Flow as Admin", "Modify Flow Owners as Admin" and "Restore Deleted Flow as Admin" are documented connector actions, callable without anyone handing over a password (flowmanagement and microsoftflowforadmins pages, seen 2026-08-25). They are held by an identity inside the tenant that owns the flows, and the licensing FAQ is explicit that bringing in someone from outside it is not free: a guest user "must have a Power Automate license assigned" (last updated 08/14/2026).
Support stops being the silent tax on your margin. The question every vendor dreads, "what happened for this one customer three weeks ago," has a fixed cost of minutes, answered by one person, with the evidence still there.
Agents calling flows as tools is documented, including for people outside your tenant, and that row goes. The surface your customer actually touches is still Microsoft's: setup is 'an iframe' onto 'a page in the Power Automate designer' where 'There's no way to hide the Power Automate branding', the end user signs in with a Microsoft identity and 'must have a Power Automate license assigned', and exposing your integrations as MCP tools means Logic Apps Standard hosting or Copilot Studio credits.
Your customer never sees the engine. They see a setup screen, a connect button, a status page, and increasingly, a tool their own AI can call. Whether those surfaces feel like your product or like someone else's is a brand decision you are making when you pick the platform.
Customers set up the integration inside your product, on your domain, with no second settings screen to build. Elsewhere, setup is an iframe into Microsoft's designer, behind a Microsoft sign-in
Open the scenarioCustomers were being sent to a third-party integration UI that broke the product experience and advertised the vendor's supplier.
The settings that drive the integration are the interface the customer configures it with. No translation layer, no second UI to build and keep in sync. Your customers never see the platform. They think it is you.
Lumen, a veterinary-practice SaaS, is shipping a bookkeeping integration inside their product. The bar: a practice manager clicks "Connect accounting" in Lumen's settings, authorizes, maps two fields, done, without ever leaving Lumen, seeing another company's name, or touching a URL that is not lumen-branded. Because the practice manager is not buying an integration platform. She is trusting Lumen.
The customer's takeaway: "Lumen's integrations are great." Which is the entire point.
The setup screen your customer opens is Microsoft's, drawn inside a frame you do not control, and they have to be a Microsoft user to get past it. For a SaaS company putting integration setup inside its own product, that is the whole question, and Microsoft's embedding page answers it plainly.
"Flow widgets are iframes located in a host document. This document points to a page in the Power Automate designer." The unauthenticated widget is a template list at make.powerautomate.com; anything beyond it takes an identity: "You need to sign the user in with their Microsoft Account or Microsoft Entra to use the authenticated SDK", the host "needs to get a Power Automate access token for the user (Microsoft Entra ID JWT token with audience https://service.flow.microsoft.com) before it initializes the widget", and "Users need to enable third party cookies in their browser in order for the widget to load correctly" (embed-flow-dev, last updated 03/20/2026, re-verified 2026-08-26).
Microsoft documents a second route, writing your own screens against the Dataverse Web API, and states its bound: "This article covers the management of flows included on the Solutions tab in Power Automate. Currently, managing flows under My Flows aren't supported with code" (manage-flows-with-code). Worth holding the marketing next to the docs, as a prospect will: the 2022 ISV post says "You simply embed the capabilities you want to extend to your customer and sell and deploy it as a unified offer" (July 19, 2022), while the 2026 embedding page describes an iframe, a Microsoft sign-in and third-party cookies. Inside your own tenant, where the person on the other side is your employee, none of this is friction. It becomes friction the moment that person is your customer.
Your customers' AI assistants can drive multi-system work through your product, with an approval gate before anything destructive and a record afterwards. Your domain, every tier. Elsewhere, agent-callable means Logic Apps Standard on Azure, or Copilot Studio credits
Open the scenarioCustomers now want their own AI agents to reach these systems, and hand-building an interface per client does not scale.
An operations director at one of your customers types into her AI assistant: "Move every Thursday booking at the Riverside location to Friday and notify the affected members." For that sentence to become action, her AI needs a tool: a governed, authenticated, rate-limited operation that does the multi-system work and reports back. Your customers will judge your product on whether their AI can drive it.
The Thursday bookings move, the members get notified, and the audit trail shows exactly what her agent did.
Making your integrations callable by your customer's agent is real here, and it happens on a different product than the one you built the flows in. The cost is the migration and the shape each tool is allowed to take.
Concede the strong part in Microsoft's words: "The Azure Logic Apps MCP Server is now generally available and enables developers to expose existing Logic Apps workflows as MCP-compatible tools that agents can discover and invoke directly" (Build 2026 blog, seen 2026-08-25). The documentation page still carries preview terms as of 02/25/2026, so both statements are worth reading together. Its requirements are printed: hosting is "Workflow Service Plan or App Service Environment v3 only", and "By default, MCP endpoints use OAuth 2.0 ... you must set up Easy Auth". The quicker API Center route is tighter still: "You can select only one connector for your MCP server", "Built-in service provider-based connectors and custom connectors aren't supported", "Each tool can have only one action".
On Power Automate itself the documented route runs through Copilot Studio: "Agent flows that have the When an agent calls the flow trigger can be added as tools in agents" (flows-overview, last updated 08/03/2026), metered on Copilot Credits, with "new agent flow runs are blocked" once an environment's prepaid capacity is consumed. We found no published statement for exposing a Power Automate cloud flow directly as an MCP server; we searched copilot-overview, limits-and-config, embed-flow-dev, the FlowAgent README, and the 2026 wave 1 release plan, where the MCP server item sits under Process Mining. So a SaaS company whose customers want agent-callable integrations is choosing between rebuilding on Logic Apps Standard, a separate Azure product on its own plan and billing, and keeping the tools inside Copilot Studio's agent surface in its own tenant.
The AI assembles the setup screen, so there is no front-end project: validated input, live choices from the customer's systems, embed code returned. Elsewhere, the customer-facing form is a second product, licensed per user
Open the scenarioConfiguration UIs were bespoke front-end projects, every time.
Palletworks promised its three largest brokers a screen that pulls their live carrier list and validates SCAC codes before anything saves. Its two front-end engineers are nine weeks into a backlog.
Customer-facing forms assemble from a catalog of elements and saved patterns, validate input, refresh their choices from the customer's live data, and drop into any page with an embed code.
The configuration screen your customer fills in is not something Power Automate hands you. Building it is a project in an adjacent product, with its own licence and its own domain rules. What is documented is aimed inward: manual trigger inputs and Adaptive Cards collect values from people already inside the tenant, and the 2026 release wave 1 item "Build better forms with integrated Power Apps" sits in the desktop flows section of the planned-features table, not under cloud flows. Past that, the documented paths to a customer-facing form are Power Apps, licensed per user on Microsoft identity, or Power Pages, a separate website product where a custom domain requires that "the website is in production state" and an uploaded SSL certificate (add-custom-domain, seen 2026-08-25). For form building blocks with validation and live-data choices served to your end customer inside your product, Microsoft Power Automate does not document this. We searched embed-flow-dev, the 2026 wave 1 planned-features table, the Power Pages custom-domain page, and the Power Automate docs map for forms. On that basis it is manual work rather than a platform behaviour.
A new customer connects, maps and goes live without anyone from your team on the call. Elsewhere, self-serve stops at the Microsoft identity and licence your customer has to hold
Open the scenarioEvery new customer connection required a human on both sides.
310 schools want the gradebook-to-parent-messaging connection live in three weeks. Each takes a 40-minute screenshare with a Coursefold engineer: 206 hours of calls, four people in implementation.
The customer clicks connect, authorizes, maps what needs mapping, and is running, inside your product, with nobody from your team on the call.
Self-serve connection works when your customer already is a licensed Microsoft user. When they are not, the click becomes a procurement conversation in their company before a record moves. The widget can provision a flow from a template and trigger it, but the authenticated SDK requires that you "sign the user in with their Microsoft Account or Microsoft Entra". If that person is outside your tenant, the licensing FAQ is explicit: "Do guest users (not from your tenant) need a license to use Power Automate? Yes. The guest user must have a Power Automate license assigned through one of the following tenants: ... The home tenant of the guest user" (last updated 08/14/2026). And any integration reaching an API Microsoft does not already ship carries its own gate: "You must have a premium or trial license to run any flow that uses a custom connector" (limits-and-config, last updated 07/17/2026). The credential step itself is a browser consent performed by a maker, and connections "represent a saved credential and are stored within the environment that hosts the app or flow" (wp-data-loss-prevention). Sharing is documented and genuinely useful inside a company: "As an owner, you can specify whether run-only users need to provide their own connections or you can use a connection already defined in the flow" (create-team-flows). All of it presumes the connector is a member of a tenant you administer, which your customer is not.
Every surface a customer's IT team inspects, screens, addresses, callbacks, carries your name on every plan. Elsewhere, you can size the frame and reword five of its strings; the Power Automate branding inside it is documented as unhideable
Open the scenarioAn integration layer that shows a supplier's name tells your customer who really built it.
Fenmark is 48 hours from signing a carrier worth 1.4 million a year. Question 41 asks for every hostname claim data touches, and its webhook receiver answers on a domain carrying someone else's name.
Every surface a customer or their IT team can inspect, the UI, the webhook URLs, the authorization callbacks, carries your name, at every tier.
The setup screens your customer opens are framed from make.powerautomate.com, the token your host mints carries audience https://service.flow.microsoft.com, the sign-in is a Microsoft one, and the documentation says the branding does not come off. "There's no way to hide the Power Automate branding when you use widgets" (embed-flow-dev, last updated 03/20/2026, re-scraped 2026-08-26), on a surface the same page describes as an iframe pointing "to a page in the Power Automate designer". That page does document styling and component parameters around the frame, and they are worth naming exactly, because they mark where the customisation stops. You size the frame with your own CSS: "Here's a sample style for the container that you can modify to match with the host application's dimensions", over a sample that sets width, height and border on the container's iframe. You can reword its labels: the GET_STRINGS event "lets you customize text for some of the UI elements shown in the widget", and the page lists five string keys, the create button, the flow name, two headers and the run button. The approval widget takes component switches, hideLink, which "hides the received and the sent approval links", plus showSimpleEmptyPage and hideInfoPaneCloseButton, and the renderWidget sample passes a widgetStyleSettings object that the page's own parameter table does not list. We found no colour or font parameter in its widget settings, widget events or widget actions sections. So the frame is yours to size and its labels are yours to word, and the Power Automate branding inside it is documented as staying. When something breaks, the message goes to your maker and not to your customer: "Failure alert emails are never sent to environment admins or tenant admins. Only users who own or co-own the flow receive per-run alerts" (understand-flow-failure-notifications, last updated 04/03/2026). We found no published statement for a custom domain on the Power Automate maker portal, the widget iframe, or the OAuth callback; we searched embed-flow-dev, limits-and-config, and the Power Automate docs map for "custom domain", which returned desktop-flow custom forms and customer-managed keys. There is an escape hatch worth naming, and it is on the other product: Logic Apps Standard runs on App Service, where Microsoft documents adding a custom domain ("Add custom domain as the following configuration. You can choose to use the app service managed certificate or add the certificate later"), and API Management can front a workflow endpoint on your hostname. That gives a machine-to-machine URL your name, at the cost of rebuilding on a separate Azure product with its own billing, and it leaves the embedded screens, the sign-in and the emails exactly where they were.
The integration experience compounds into your brand instead of your supplier's. Every setup flow, every status page, every AI tool call is a moment your product looks finished, in your customer's language, on your domain.
Their agent surface is real, MIT-licensed, same-day fresh, and it reads its own reference docs before acting, which is parity and deletes that row. Its boundary is scope rather than quality: the runbooks end at one flow inside your own tenant, solutions and pipelines sit outside the MCP as CLI shell commands, every job loads all 55 tools with delete and publish included on 'the same access you have on your machine', and bug filing waits for you to ask.
Everything on this page is exposed to AI, but "AI-powered" is the emptiest phrase in the category. The question with teeth: which phases of the integration lifecycle does the AI have real tooling for? Building is one phase. There are seven more.
One person and the AI cover an integration's whole life, launch through incidents. Elsewhere the AI diagnoses, then a developer does the fixing. Elsewhere, real runbooks, and they end at one flow in your own tenant
Open the scenarioAn AI with raw API access improvises. An AI with encoded procedures repeats what works.
Day two. The integration is built and live; both platforms' AI tooling got you here, and both did it well. Now the real career of an integration begins: a customer reports a discrepancy, an API starts rate-limiting, an alert needs tuning, a fix needs to reach the fleet. The question for the AI is no longer "can you build it." It is "how much of what happens next can you handle?"
One person and the AI cover the lifecycle. Day two looks like day one.
For a company shipping integrations to its own customers, the encoded procedures cover one flow inside your own tenant, and the steps that follow a working fix, tuning what it alerts on and getting it to the customers running it, sit outside them.
Concede the build plainly, because it ships in a public MIT repo anyone can check in minutes: "Build, edit, run, and debug Power Automate cloud flows from Claude Code or GitHub Copilot CLI, powered by the FlowAgent MCP server" (v3.0.4, repo pushed 2026-08-25). The ten skills are genuine runbooks rather than a tool dump. The build skill orders "ALWAYS call get_operation_details before building any connector action. Never guess parameter names, enum values, or action types", and per flow the surface reaches build, test, debug of a failed run, resubmit, bulk cancel with turn-off, surgical edit, and restore from automatic pre-mutation backups ("Last 10 retained per flow"). Logic Apps Automation adds its own drafting assistant in public preview, on a different product with Azure billing.
Past that flow the runbooks thin out. FlowAgent's own AGENTS.md reserves sharing and solutions and admin operations, which is where deployment lives, for CLI-only commands the MCP does not wrap. Across all 98 platform-operation tool entries (FlowAgent's 55 tools, the management and admin connector actions, pac) no verb sets, routes, suppresses or maps an alert on a Power Automate cloud flow; the built-in failure emails are published with "a 28-day cooldown period", reach the flow's owners and co-owners, and carry no documented setting that changes either destination or cooldown. The alert rules Microsoft documents as agent-scriptable, Azure Monitor rules over exported run telemetry and on Logic Apps runs, sit on Azure resources with Azure billing (re-verified 2026-08-26). Shipping to your customers is not a procedure the agent repeats either: the pipelines FAQ answers "Can pipelines deploy to a different tenant?" with "No. We recommend using Azure DevOps or GitHub for this scenario." Moving to Logic Apps Standard answers some of this and costs a different product on Azure billing, and it does not hand an agent the step a fix runbook wants most, since rerunning from the action that failed is portal work: "These capabilities currently are unavailable with Visual Studio Code or Azure CLI", for sequential workflows of "40 or fewer actions".
Give an AI forty similar-looking tools and it picks the wrong one. Here it sees only the handful this job needs. Elsewhere, every skill gets all 55 tools, delete and publish included
Open the scenarioDepth and focus are in tension: an AI drowning in tool definitions gets worse, not better.
Friday, 16:40. The integration lead has the AI retune a load-tender mapping inside 61 automations, a change 40 dispatchers need Monday. Every irrelevant tool is another way to reach the wrong one.
The full tool surface stays available, but only the set the current procedure needs is loaded. The AI stays sharp on a platform wide enough to get lost in.
Nothing narrows the grant to the job at hand: the agent sent to diagnose a failed production run holds the same delete and publish verbs as the agent scaffolding a new flow in dev. This is inspection of the shipped manifests rather than inference. Every one of FlowAgent's ten skills carries the same allowed-tools line granting all 55 mcp__flowagent__ tools, so diagnose-flow, described as "Deep autonomous diagnosis of a failed flow run", is handed create_flow, delete_flow, delete_connection and publish_flow alongside its read tools, and the server itself ships as "a single self-contained ESM bundle (stdio transport, all 50+ tools, deps inlined)" (repo at v3.0.4, seen 2026-08-25). Per-tool guard rails do exist and deserve credit: preview_update is marked "Read-only", returns "a short-lived single-use token" and applies a change "only if the proposal still matches what you reviewed", get_flow_context is to be called before mutating, and the build skill creates a flow "in Stopped state". What is not documented is a scoped or read-only tool set for production work; "Read-only" appears on two individual tools, not as a mode (searched the README, AGENTS.md, CLAUDE.md, all ten SKILL.md files and the tool descriptions in server/mcp.mjs). Microsoft's own README states the consequence: "Auto-approval options give the agent the same access you have on your machine. Only use these in trusted or sandboxed environments." Narrowing the blast radius falls to whoever approves each call.
The AI files the platform defect it hits, so it gets fixed instead of papered over by an undocumented workaround. Elsewhere, filing waits for your request and lands on the plugin repo
Open the scenarioAgents silently working around platform bugs means the bugs never get fixed.
The platform layer behaves differently than documented, the AI routes around it, and that detour is permanent, undocumented, and a 2am problem next hail season. The supervisor has inherited three.
When the AI hits a platform-layer defect, it files a structured report to engineering, autonomously, instead of quietly routing around it. The tools get better because the agent using them is also their reviewer.
Filing waits for a person to ask, and it lands on the plugin's repository, so a platform quirk the agent routed around stays routed around unless someone decides to write it up. Credit what ships: FlowAgent includes a report-issue skill in an actively maintained MIT repo (last push 2026-08-25), and the skill's own trigger text draws both boundaries in one sentence: "Use this skill when the user wants to \"report a bug\", \"file an issue\", \"report an issue\", \"submit a bug report\", or report any problem with the power-automate plugin to the GitHub repository." The actor is the user wanting to report, and the destination is the plugin's GitHub repository. Read across the rest of the surface, none of the ten skills and none of the 55 tool descriptions describes the agent raising a report on its own initiative when it observes the platform behaving contrary to its documentation, and none names a Power Automate triage queue as the destination (skills and server/mcp.mjs, seen 2026-08-25; the report-issue description re-verified verbatim against the repo 2026-08-26). For a team running integrations for customers, that means the quirks your agent hits during a support week accumulate in your own notes rather than in the vendor's queue.
The AI is not a build accelerator bolted to the front of the lifecycle. It is a colleague with a runbook for all of it, which is why one person can run what used to take a team.
Every row on this page reduced to the same fork. On APIANT, the job was a walkthrough: find it, see it, change one node, prove it, ship it everywhere. On Microsoft Power Automate, the same outcome was reachable, usually, and it was a project: a code artifact to edit, a pattern to hand-build, a script to write against their API, a window that had already closed. Not because their team built a careless product. They built a serious one. But their platform is made of code at the layer that matters, and their AI's output is code, so every question on this page eventually hit the same wall: the thing that runs your business is an artifact only developers can safely touch, and the AI that builds it cannot fully operate it afterwards. On APIANT the integration is a structured document at every layer, which is why the AI can build it, a compiler can refuse the invalid version of it, a test can force every branch of it, a person can read it, and one command can ship it to a fleet. That is not forty-four features. It is one architecture, showing up forty-four ways.
Then you write code, in the one place code belongs: a scripting escape hatch that slots in as a single node of the structured document. Code is an optional leaf inside a data document, never the foundation. The loop, the branches, the mappings, the tests around that leaf all remain visible, machine-editable, and compiler-checked; the custom logic is contained to the one spot that genuinely needed it.
Compare the shape of the same answer elsewhere: when the model runs out, the escape hatch is more code on a foundation that is already code. The exception and the rule are indistinguishable. Here, the exception stays the exception, and a decade of production has kept it rare.
Own the outcome, and be precise about what owning the artifact costs. A code integration is cheap on day one and priced like a liability thereafter: it is reviewed by whoever has time, it carries a dependency tree that ages, every API drift re-opens it, and its real documentation is the memory of whoever wrote it. Multiply by every integration you will ever ship, then by the years you will run them, then subtract the engineers who will have moved on. That is the asset you would own.
What you own on APIANT is the thing you actually wanted: integrations that run, on your domain, inspectable by your team, provable before they ship, and operable by AI for as long as you run them. The buildings your company works in are owned this way too: you own the use of something built and maintained by people whose whole business is that it never falls down.
The API with no catalog entry, the forty custom fields, the sync that loops, the customer report from three weeks ago. One working session, on your systems, and you watch it built, tested on every branch, and running. Judge the architecture with your own scenario, which is what this page has been asking you to do all along.
Book a working session See the AI operate the platformScenario companies on this page are composite illustrations drawn from real deployment shapes. Company names are fictional and are not customer references. Where a figure comes from a live APIANT deployment it is identified as such and the customer is not named. Every statement about Microsoft Power Automate on this page derives from Microsoft Power Automate's public documentation, public repositories, blog, and pricing page as reviewed in August 2026. Direct quotes are reproduced verbatim for comparison purposes. Microsoft Power Automate is a trademark of Microsoft Power Automate; all product names belong to their owners. Platform capabilities evolve; verify anything decision-critical against the current versions of the linked pages.
