Power Automate & RPA Consulting

What types of Power Automate flows does Solzet build?

We build three categories of Power Automate flows. Cloud flows: event-driven or scheduled automations that run in the Microsoft cloud. Common examples include lead qualification workflows (new lead in D365 → enrich data via API → assign to sales rep → send Teams notification), document approval chains (SharePoint upload → manager approval → signature → archive), and data synchronization between systems (ERP to CRM nightly sync, form submissions to Dataverse). Desktop flows: UI-based RPA scripts that automate interactions with legacy Windows applications - clicking buttons, filling forms, extracting screen data, and passing it to cloud flows. We use Power Automate Desktop's recorder plus manual scripting for resilience. AI Builder flows: intelligent automations that use pre-built or custom AI models - invoice processing, receipt scanning, sentiment analysis of customer emails, and document classification.

What does business process automation (BPA) on the Power Platform involve?

Business process automation is a larger job than automating a task, which is why it gets its own section on a page otherwise about flows. A task automation moves one thing from A to B: a form submission becomes a Dataverse row, an email attachment lands in SharePoint. A business process runs for days or weeks, crosses several systems and several departments, has human decision points, exceptions, escalations and reassignments, and has to be reportable afterwards because sooner or later somebody asks who approved what and when. Microsoft Power Platform is a BPA suite rather than a workflow tool because it provides a separate component for each of the three things an end to end process needs: somewhere to keep the state of the process, an engine to move it along, and screens for the people who have to act inside it. Dataverse, Power Automate and Power Apps map onto those three jobs. The most common reason a BPA programme on this platform disappoints is that somebody tried to do all three with flows alone.

Dataverse is where the process lives, not just where the data lands. The design decision that separates a durable BPA build from a fragile one is giving the process its own table instead of scattering its state across variables inside a running flow. A credit review, an onboarding case, a change request or a supplier claim becomes a row with its own columns: current stage, owner, due date, requested amount, the decision and the reason for it. That single move buys most of what enterprise BPA is supposed to have. Row level and column level security decide who can see the request and who can see the commercial terms on it. Business rules and a C# plugin registered on the Dataverse event pipeline enforce the rules that must hold no matter how the row arrives, including through an integration or a bulk import. Auditing records every column change with a user and a timestamp, which is the audit trail rather than a reconstruction of one. Alternate keys give you idempotency, so a retried integration updates the existing request instead of creating a second one. Change tracking gives every other component an event to react to. And because the state is a row rather than a run, a process can sit paused for three weeks waiting on a supplier without a flow timing out, and it can be reported on while it is still in flight.

Power Automate is the orchestration layer, and in a real BPA build it is usually several small flows rather than one large one. Cloud flows trigger on the Dataverse change tracking pipeline within seconds of a row changing, so the process advances on an event rather than on a poll. Child flows keep each stage independently testable and rerunnable, which matters the first time you have to restart a long process from the middle. Approvals actions push a decision into Teams or Outlook with the request attached and write the outcome back to the process row, and a scheduled flow chases anyone sitting on one past its service level. Scopes with try, catch and finally wrap every external call so a failure lands in a monitored path instead of stopping quietly. Where a step needs more than low code can express, a Dataverse custom API turns a piece of C# into a named operation that flows, apps and integrations all call the same way, which is how the same rule avoids being reimplemented three times in three places. Desktop flows cover the system that has no API at all. The approval mechanics specifically, meaning authority matrices, escalation and the audit trail finance teams are asked for, are worked through in how Power Automate approval flows save mid-market finance teams time.

Power Apps is the layer most BPA projects underbuild. Almost every enterprise process has a human in it who needs more than an approve or reject button, and giving that person the right screen is what decides whether the process is adopted or routed around. A model-driven app over the process tables gives a reviewer a queue, a filtered view of what is waiting on them, the full record with its history, and business process flows that stage gate the work so a request cannot reach approval before the checks behind it are complete. A canvas app gives the person doing the physical step, on a site or in a warehouse, a phone screen with three fields on it rather than a CRM form. Power Pages puts the external participant, meaning the supplier, the applicant or the customer, directly into the process on the same Dataverse rows, with table permissions deciding what they can see, instead of your team retyping their email into the system on their behalf. Those three surfaces, plus a report over the same tables, are the difference between a process that is automated and a process that is merely triggered.

How this connects Dynamics 365 Customer Engagement to everything else is the part that is hard to reproduce outside the Microsoft ecosystem. The starting point is that D365 Sales, Customer Service and Field Service are themselves Dataverse applications, so a process built on Dataverse is not integrating with your CRM, it is running inside the same database, under the same security model, in the same solution, with the same audit. There is no sync job, no shared key to maintain and no window during which two copies of the customer disagree. From that centre the platform reaches outward through several mechanisms rather than one. Over a thousand first party and certified connectors cover the mainstream SaaS systems. Custom connectors wrap any REST API from its OpenAPI definition, so a maker can call your own services without writing integration code. The on-premises data gateway reaches SQL Server, file shares and line of business systems behind your firewall. Virtual tables surface data owned by another system as Dataverse rows, so a flow or an app can read it without copying it and without a reconciliation job. Azure Functions, Service Bus and Event Grid take the heavy transformation and the durable, ordered messaging when volume matters more than convenience. Desktop flows drive the applications that expose nothing at all. Underneath all of it sits one Entra ID for identity, one set of data loss prevention policies, and managed solutions with connection references and environment variables, so the tables, flows, apps and plugins move from development to test to production as a single unit instead of being rebuilt by hand in each environment.

Why this is a different category from automation inside a SaaS suite. HubSpot workflows, Salesforce Flow and the trigger builders inside service desk products are good tools, and they share one design assumption: the process lives inside the vendor object model and stays there. A HubSpot workflow can update a deal, enrol a contact in a sequence, send an email and set a property, and if your process is marketing and sales activity inside HubSpot then that is the right tool and we will say so. It stops being the right tool at four specific boundaries. Schema: a process that needs its own record, with its own columns, stages and retention rules, is not a deal or a contact, and bending a CRM object model to hold it is how an organization ends up with fourteen custom properties nobody can explain. Enforcement: a SaaS workflow runs after the fact on the vendor side, so it can react to a bad record but it cannot refuse to create one, while a plugin on the Dataverse event pipeline runs inside the transaction and can. Human interface: you get the vendor screens, so the reviewer works in a CRM built for salespeople rather than an app built for the review. Reach: the moment the process needs the database behind the firewall, the desktop application with no API, or an approval that has to happen in Teams, you are bolting a separate integration tool onto the side of the suite anyway. Then add the licensing shape, where letting an occasional participant complete one step means buying them a seat in a CRM they otherwise never open, against a Power Apps or Power Pages licence sized for exactly that. The fair summary is that SaaS suite automation is excellent at automating inside its own product and structurally weak at automating across a business, and BPA is the second thing.

When to use the Power Platform, and when to use something else. This page already compares Power Automate with the dedicated RPA platforms above and with the consumption priced tools below, so this framework sits a layer above both: it decides whether the work belongs on a BPA suite at all. Six questions settle it in practice, and it is the count of yes answers that matters rather than any single one. Where does the authoritative record of the process belong? If the answer is Dataverse or a Dynamics 365 Customer Engagement app, build the process where that record already is. How long does the process live? Minutes means almost any tool will do; days or weeks with escalation, reassignment and partial completion needs durable state and therefore a real data layer. Does a human have to work inside it, and do they need a screen rather than a button? Must any rule be enforced rather than merely executed, meaning it has to hold when a record arrives from an import or a second integration? Does the data cross a compliance boundary that makes a third party processor a problem? Is there a system in the chain with no usable API? Four or more yes answers and the Power Platform is the cheaper option across the life of the process, even where it is slower in week one. One or two, and a lighter tool will get you there faster, which is a recommendation we make regularly and the comparison section below sets out the categories for. The reason this is often cheaper than mid-market teams assume, because a large part of the entitlement is already sitting inside the Microsoft 365 licences being paid for every month, is argued in Power Platform: the most underused tool in mid-market companies. Where you need the platform layer of this work rather than the flow layer, meaning the apps, the Dataverse model and the governance around them, that is our Power Platform developers service.

• Process state, in Dataverse. One table per process carrying stage, owner, due date, amount and decision, with auditing, alternate keys for idempotency, and row and column level security, so the process outlives the run that started it and can be reported on mid flight.
• Orchestration, in Power Automate. Cloud flows on Dataverse change tracking triggers, child flows per stage for restartability, approvals routed into Teams and Outlook, scheduled escalation for anything past its service level, and scopes with try, catch and finally around every external call.
• Enforcement, in Dataverse. Business rules for the simple cases and C# plugins or a custom API for the rules that must hold regardless of whether the record arrives from a form, a flow, an integration or a bulk import. This is the piece no tool outside the platform boundary can provide.
• Human interface, in Power Apps. Model-driven apps and business process flows for reviewers and caseworkers, canvas apps for the mobile or site based step, and Power Pages for suppliers, applicants and customers who must act inside the process without holding a CRM licence.
• Reach beyond Microsoft. Certified connectors for mainstream SaaS, custom connectors generated from an OpenAPI definition, the on-premises data gateway for systems behind the firewall, virtual tables to read external data without copying it, Azure Functions and Service Bus for heavy or order sensitive work, and desktop flows for applications with no API.
• Measurement. Because the process record is a row rather than a flow variable, cycle time, queue depth, rework rate and approval turnaround are reportable while the process is still running, instead of being reconstructed from run history after somebody complains.
• Lifecycle. Managed solutions with connection references and environment variables move tables, flows, apps and plugins between environments as one unit, with regression testing against the two Microsoft release waves a year before they land rather than after.

How does Power Automate compare to UiPath or other RPA tools?

Power Automate's key advantage is native integration with the Microsoft ecosystem - Dynamics 365, SharePoint, Teams, Outlook, Dataverse, and Azure services all have first-party connectors that require zero custom integration work. For organizations already invested in Microsoft 365 and Power Platform, this reduces total cost of ownership significantly. UiPath, Automation Anywhere, and Blue Prism offer more advanced enterprise RPA capabilities - attended/unattended bot orchestration, computer vision-based automation, and cross-platform desktop automation. Solzet recommends Power Automate when your automation landscape is primarily Microsoft-centric and your RPA needs are moderate. For heavy RPA scenarios (hundreds of bots, non-Windows systems, mainframe automation), we can advise on the right tool even if it is not Power Automate.

Power Automate or Zapier, Make and n8n: which fits enterprise automation?

Zapier, Make, and n8n are good at what they were built for: wiring together SaaS applications that already expose clean REST APIs, quickly, without involving IT. If the job is to push a form submission into a Slack channel and append a row to a spreadsheet, any of them will beat Power Automate on time to first working automation, and we will say so. The comparison changes shape the moment an automation touches Dataverse, customer records inside Dynamics 365, or anything an auditor will later ask a question about. At that point you are no longer choosing a connector library. You are choosing where your customer data sits while it is in flight, whose identity the automation runs under, and what happens to the invoice when volume grows. Those three questions decide this comparison for Microsoft centric organizations far more often than the visual builder does.

Native Dataverse and Dynamics 365 integration. Power Automate reaches Dataverse as a first party service inside your own tenant. A cloud flow triggers on the Dataverse change tracking pipeline rather than on a poll, so it fires within seconds of a row being created, updated, or deleted, and it can run in the security context of the user who caused the change, which means row level and column level security still governs what the automation is allowed to read. It can call a custom API written in C#, hand work to a plugin running inside the platform transaction, and move from development to test to production inside a managed solution with connection references instead of being rebuilt by hand in each environment. Zapier, Make, and n8n reach the same data from outside the tenant through the Dataverse Web API. That means an Entra ID app registration with an application user, a client secret somebody has to rotate, a polling trigger on the vendor's schedule rather than an event, typically every 1 to 15 minutes depending on plan, and deduplication keys you write yourself because a poll that overlaps will process the same row twice. In our experience a non trivial Dynamics 365 integration built that way costs roughly 20 to 60 engineer hours more than the equivalent first party flow before it is production ready, and the gap reopens every time the automation is promoted to another environment or a secret expires. Across a dozen integrations that is a large part of an engineer's year spent rebuilding what the native connector already does.

Governance and security inside Microsoft 365. This is usually where a security review settles the question rather than a feature grid. Power Automate runs inside your Microsoft 365 tenant, under Entra ID, and inherits controls you have already bought and already audited: conditional access and multifactor authentication on the accounts that own connections, data loss prevention policies that stop a maker joining a business connector to a personal one, separate environments so production is not where people experiment, managed environment controls for sharing limits and maker onboarding, audit records in Microsoft Purview, and data residency in the geography your tenant already sits in. Zapier and Make are separate processors. Your customer records leave the tenant, sit in their infrastructure for the duration of every run, and are covered by their data processing agreement and their subprocessor list rather than yours. For a company that answered these questions once for Microsoft 365, adding a consumption tool means a fresh vendor assessment, a second DPA, another place to revoke access when somebody leaves, and another line to defend in a customer security questionnaire. n8n is the honest exception here: self hosting keeps the data inside your own infrastructure, which removes the processor problem and replaces it with an operations problem, because the container, the upgrades, the secrets, the backups, and the on call rota become yours.

Cost at scale. The pricing models are different shapes, which is why the comparison looks flattering to the consumption tools at small volume and decisive against them at large volume. Zapier and Make meter consumption: you pay per task or per operation, every step of every run adds to the bill, and a busy month costs more than a quiet one. Power Automate meters entitlement: you license the user or the process, and the ceiling is a daily Power Platform request allocation rather than a number on an invoice. The crossover arrives earlier than most teams expect. One flow with 20 steps running 1,000 times a day is 600,000 metered operations a month, which sits well past the standard published tiers of the consumption tools and into their higher or custom priced ones. The same work on a Power Automate Premium seat is about 20,000 requests a day, comfortably inside the 40,000 request daily allocation that licence carries, pooled across the tenant, so the cost tracks headcount instead of volume. And for a Microsoft centric company the starting line is not zero either: the seeded Power Apps and Power Automate rights bundled with most Microsoft 365 plans mean part of the capability is already being paid for every month, the argument we set out in full in Power Platform: the most underused tool in mid-market companies.

Complex and data sensitive logic. Consumption tools are strongest when the logic is linear. Power Automate holds up better when it is not: child flows so a long process stays testable in pieces, scopes with try, catch, and finally around every external call, concurrency and pagination controls for batch work, and the option to leave low code entirely when a rule belongs in code. That last point is the one that matters for data sensitive work. Pricing, discount, approval, and validation rules that must hold no matter how a record arrives belong in a C# plugin registered on the Dataverse event pipeline, not in an external automation that a bulk import, a second integration, or a user editing the row directly will simply walk past. A tool outside the platform boundary cannot enforce a rule at that boundary. If part of your logic has to be enforced rather than merely executed, that is a constraint rather than a preference, and it takes the consumption tools off the shortlist for that piece of work regardless of what they cost.

What we actually recommend. If your systems are SaaS applications with clean APIs, the data is not regulated, the volume is modest, and the people building the automations are not engineers, Zapier or Make is a reasonable answer. If you need self hosting and have a team comfortable running it, n8n is credible. If your customer data lives in Dataverse or Dynamics 365, your identity and compliance story is already built on Microsoft 365, or your automation volume is heading past a few hundred thousand steps a month, Power Automate is cheaper to run, faster to integrate, and easier to defend to an auditor, and that gap widens rather than closes as the estate matures. Mixed estates are common and often fine; the automations worth moving are the ones touching customer data or growing in volume. Our Power Platform developers can review what you already run and tell you which of those two categories each automation falls into.

• Trigger latency. A Dataverse cloud flow fires on the platform change tracking pipeline within seconds. Zapier, Make, and n8n poll the Dataverse Web API, typically every 1 to 15 minutes depending on plan and configuration, so event driven processes become batch ones.
• Security context. Power Automate can run in the calling user's context, so Dataverse row level and column level security still applies to what the automation reads. An external tool authenticates as one application user and sees everything that user can see.
• Data residency. First party flows keep customer records inside your Microsoft 365 tenant and its geography. A consumption tool copies them into a third party processor for the duration of every run, which is a new entry on your data map.
• Governance. Data loss prevention policies, environment separation, managed environment controls, Entra ID conditional access, and Purview audit records apply to Power Automate automatically, because it is part of the tenant you already govern.
• Cost shape. Consumption tools bill per task or operation, so cost tracks volume. Power Automate bills per user or per process against a daily request allocation, so cost tracks headcount and stays flat while volume grows.
• Enforcement. Rules that must hold regardless of how a record arrives belong in a C# plugin inside Dataverse. No external automation tool can substitute for that, because it sits outside the boundary the rule has to be enforced at.
• Build cost. Budget roughly 20 to 60 additional engineer hours per non trivial Dynamics 365 integration built outside the tenant, plus the recurring cost of secret rotation, per environment rebuilds, and deduplication logic somebody has to own.

What industries benefit most from Power Automate workflows?

Power Automate delivers measurable ROI across every industry we serve. Financial services firms automate loan approval pipelines, KYC document collection, and compliance notification chains - reducing processing time from days to hours. Manufacturing companies use Power Automate for quality alert escalation, equipment maintenance scheduling, and production shift handoff workflows. Professional services firms automate proposal generation, time entry reminders, engagement onboarding sequences, and invoice creation from approved timesheets. B2B technology companies build automated customer onboarding sequences, renewal reminders, churn risk alerts, and partner deal registration approval flows. The common thread is eliminating manual, repetitive tasks that consume senior staff time. Solzet designs automations that connect Dynamics 365, SharePoint, Teams, Outlook, and third-party systems into seamless end-to-end processes - each with built-in error handling, retry logic, and monitoring so your operations team knows exactly when something needs attention.

How does Solzet design resilient Power Automate solutions?

Many Power Automate implementations fail not because the happy path is wrong, but because error handling is absent. Solzet builds every automation with production-grade resilience. This includes try-catch scopes around every external API call with configurable retry policies, parallel branch execution with timeout controls, dead-letter queues for failed records that need manual review, structured logging to a central Dataverse table or Azure Application Insights for monitoring, and alerting flows that notify administrators via Teams or email when a critical automation fails. We also implement circuit-breaker patterns for high-volume integrations - if an external system becomes unresponsive, the flow pauses and retries on a schedule instead of flooding the target with failed requests. For RPA desktop flows specifically, we add screenshot capture on failure, session recovery logic, and machine health checks before execution starts. Every automation ships with a runbook documenting the flow logic, failure modes, and remediation steps.

How should service accounts and connection references be set up for reliable flow deployment?

The single most common way a working Power Automate estate stops working is not a bug in a flow. It is an identity event somewhere else in the company. Someone in finance resets their password on a Tuesday morning, and by Tuesday afternoon the nightly SQL Server sync, the invoice approval chain and the two flows that write back to Dataverse have all stopped, with the run history showing an authentication failure on the first action that touches a connection. Nobody edited a flow, which is why nobody can find the change that explains it. What changed is that a Power Automate connection does not store a password. It stores a refresh token that Entra ID issued to whoever clicked Sign in when the connection was first authorized, and Entra ID revokes refresh tokens on a password reset, on multifactor re-registration, when an administrator revokes that person's sessions, and when a conditional access policy change makes the existing token non compliant. If the connection was authorized by a human, the automation is running on that human's password policy: a 90 day expiry, a security incident that triggers a tenant wide revocation, a laptop refresh that forces MFA enrolment again. The tell is that every flow that person ever authorized fails within the same few minutes, across unrelated processes, which is how you separate this from a genuine flow fault in the first five minutes rather than the third hour.\n\nDiagnosing that class of failure symptom by symptom, with the specific status codes and what each one actually means, is the job of our Power Automate and Power Platform support guide. This section is the other half: how to build the estate so the password change is a non event. Two components do the work, and they only work together. A dedicated Entra ID service account, or better a service principal, so the credential belongs to the company rather than to a person. And solution aware connection references, so that credential can be repointed in one place instead of being reselected inside every flow that used it. A service account without connection references still forces a per flow edit every time the identity changes. Connection references pointed at a named employee still die when that employee does.\n\nWhat a connection reference actually is, because the name undersells it. It is a solution component that sits between the flow and the connection: the flow points at the reference, the reference points at a connection, and the connection holds the credential. That indirection is what turns three separate problems into one setting. Promotion between environments stops being a manual reselection of connections inside every flow, because the same solution imports into development, test and production and a deployment settings file tells each import which connection to bind. Identity changes stop being a rebuild, because repointing a reference at a new connection is a solution edit of a few minutes with no flow content touched. And the environment boundary becomes real, because the production flow can no longer be accidentally holding a development connection to a development database, which is the quiet failure mode that hurts most: it does not error, it just writes the wrong data to the wrong place until somebody notices.\n\nChoosing the identity is the decision that determines how much of this you will be doing again next year. A service principal is the strongest answer wherever the connector accepts one, because it has no password at all, so the entire class of reset and MFA failures disappears and the only clock left is a secret or certificate expiry you set yourself. Dataverse, SQL Server, the Azure connectors, HTTP with Entra ID and any custom connector you build accept a service principal. The personal connectors do not: Outlook, OneDrive, SharePoint in a user context, Teams messages posted as a person and the Approvals actions all need a real account with a mailbox and a licence behind it. So a mature estate normally runs both, and the useful rule is one dedicated service account per environment tier for the connectors that insist on an account, a service principal for everything else, and never a named employee for anything in production. One warning on how the service account is secured, because it is the shortcut we most often have to undo: do not solve it by exempting the account from conditional access and multifactor authentication tenant wide. Scope a policy to that account instead, restrict it to the locations your automation runs from, keep the credential in Azure Key Vault or the vault you already run, and put the rotation on a named person's calendar. An unmonitored, unrestricted, never rotating account with broad privileges is a worse problem than the outage it was created to prevent.\n\nAcross development, test and production the shape is the same in each environment and only the values differ. Each environment gets its own service account or its own application user, its own connections authorized as that identity, and its own row in a deployment settings file. The solution itself is identical in all three, which is the point: a connection reference carries no environment specific value inside the solution, so the same managed artifact promotes without modification, and anything else that differs, meaning the site address, the endpoint, the mailbox, the threshold, goes into an environment variable rather than into the flow. The command level mechanics of generating and passing that settings file, and of running the promotion as a pipeline rather than by hand, are covered in our Power Platform ALM guide to the Power Platform CLI, so the walkthrough below stays on the identity and connection side and does not repeat them. Two rules are worth stating plainly because breaking either one is what causes most first time deployment failures. Create the target connections as the target environment identity before you import, not after, because a connection reference with nothing to bind to resolves to whoever ran the import. And let the pipeline authenticate as a service principal, because a pipeline that imports as a person inherits that person's password policy in exactly the way this whole section is trying to avoid.\n\nDesktop flows follow the same discipline with one addition. They are solution aware, so they take connection references and environment variables like any cloud flow, but they also run on a machine group that signs in as an account of its own, and that account has the same rotation and least privilege questions attached to it. The credential handling, the machine group hygiene and the monitoring that goes with unattended RPA are set out in Power Automate Desktop production reliability rather than repeated here. What matters for deployment is that the sign in account for the machine group and the identity behind the cloud flow connection are two separate things, and both have to exist in the target environment before the solution arrives.

• Step 1, create the identity before the first flow, not after the first incident. One Entra ID account per environment tier, named for its job rather than for a person, for example svc-automation-dev, svc-automation-test, svc-automation-prod. Separate accounts per tier mean a development credential cannot reach production data, and a test failure cannot take production down with it. Where the connectors in scope accept a service principal, register an application instead and add it to the environment as an application user with its own security role.
• Step 2, license it for what it will actually do. A service account that owns premium flows needs a premium licence like any other owner, and a shared or scheduled automation with no human behind it usually belongs on a per flow licence rather than a seat. The licensing section above sets out that decision and the audit that tells you which flows fall where. Skipping this step is how an estate ends up correctly architected and non compliant at the same time.
• Step 3, secure it properly rather than exempting it. Credential in a vault, a conditional access policy scoped to the account rather than a blanket exclusion, a security role written for automation instead of System Administrator borrowed for convenience, and a rotation date owned by whoever owns identity. Record who can retrieve the credential and how, because a vault nobody can open during an incident is not a control.
• Step 4, build inside a solution in a development environment. Not in My flows, not in the default environment, and not directly in production. Anything built outside a solution has to be rebuilt to get into one later, and that rebuild is the tax most estates are still paying when we arrive.
• Step 5, create connection references explicitly, one per connector per purpose, with a naming convention you can read in a settings file six months later. Splitting by purpose rather than sharing one reference for everything is also a throughput decision, because Dataverse service protection limits are counted per identity and consolidating an entire estate onto one tidy connection concentrates the load instead of spreading it.
• Step 6, authorize the development connections signed in as the development service account, then verify who the reference is actually bound to rather than assuming. The identity a solution aware flow runs as is whoever authorized the connection, which after an import is frequently the person who ran the import rather than the person who built the flow.
• Step 7, put everything environment specific into environment variables. Site addresses, endpoints, mailboxes, thresholds, record identifiers. A literal value in a flow definition is a value that will point at development data from production, silently and without an error, until somebody notices the wrong records moving.
• Step 8, generate the deployment settings file from the solution and fill one copy per environment. Regenerate it every time a connection reference or environment variable is added, because the failure mode of a stale settings file is an import that succeeds with an unbound reference and a flow that will not start.
• Step 9, create the target connections in test as the test service account before importing anything, then import the managed solution with the test settings file, authenticating as a service principal rather than as a person. Run the flows and read the run history to confirm which identity they executed as.
• Step 10, promote to production the same way with the production settings file, and change nothing in production by hand afterwards. Editing a managed component directly in production creates an unmanaged layer that the next import will not overwrite, which is how an environment quietly stops matching its own source and starts behaving differently from test.
• Step 11, set ownership and notification routing while you are there. Add a security group or a Dataverse team as co-owner of everything that matters, and route Microsoft platform notices to a shared mailbox or Teams channel somebody reads, because the warnings that arrive before a flow is disabled go to the owner and an unread mailbox is the same as no warning.
• Step 12, make it survive contact with the calendar. Secret and certificate expiry dates on a shared calendar with a reminder ahead of them, failure alerting inside your own tenant, and a re-run of the ownership and connection inventory on a cadence. Without the last one the estate drifts back toward personal connections within two release waves, one convenient shortcut at a time.

# Create the automation identity once per environment tier. Flag names vary
# between CLI versions; confirm with pac help admin before putting this in a
# pipeline.

# --- Option A: service principal, preferred wherever the connector accepts one
# Registers an app and adds it to the environment as an application user.
pac admin create-service-principal --environment <environment-id> --role "System Customizer"

# Returns the tenant id, application id and client secret. Put the secret in a
# vault immediately and record its expiry date. This is the only clock left.
pac auth create --applicationId <app-id> --clientSecret <secret> --tenant <tenant-id>

# --- Option B: dedicated user account, for Outlook, Teams, Approvals, OneDrive
# Created in Entra ID, licensed, credential vaulted, one per environment tier:
#   svc-automation-dev@contoso.com
#   svc-automation-test@contoso.com
#   svc-automation-prod@contoso.com
#
# Then, in Dataverse, give it one security role written for automation rather
# than System Administrator borrowed for convenience, and add it to the team
# that owns the production flows.

# Verify what an environment is actually running as, before you trust it
pac admin list-app-users --environment <environment-id>
pac connection list --environment <environment-id>

# 1. Generate the settings template from the solution you are about to ship.
#    Re-run this every time a connection reference or environment variable is
#    added, or the import binds nothing and the flow will not start.
pac solution create-settings --solution-zip ./out/ContosoAutomation_managed.zip --settings-file ./config/deploy.template.json

# 2. Fill one copy per environment. Same solution, three settings files.
#    config/deploy.test.json:
{
  "EnvironmentVariables": [
    { "SchemaName": "contoso_ApiBaseUrl",   "Value": "https://api-test.contoso.com/v2" },
    { "SchemaName": "contoso_FinanceInbox", "Value": "ap-test@contoso.com" }
  ],
  "ConnectionReferences": [
    {
      "LogicalName":  "contoso_sql_finance",
      "ConnectionId": "<connection-id-from-the-test-environment>",
      "ConnectorId":  "/providers/Microsoft.PowerApps/apis/shared_sql"
    },
    {
      "LogicalName":  "contoso_dataverse_core",
      "ConnectionId": "<connection-id-from-the-test-environment>",
      "ConnectorId":  "/providers/Microsoft.PowerApps/apis/shared_commondataserviceforapps"
    }
  ]
}

# 3. IMPORTANT ORDER. Create those connections in the target environment first,
#    signed in as that environment service account. A reference with nothing to
#    bind to resolves to whoever ran the import, which is how a production flow
#    ends up running as a consultant who left in March.

# 4. Import as the pipeline service principal, never as a person.
pac auth create --applicationId <app-id> --clientSecret <secret> --tenant <tenant-id>
pac solution import --path ./out/ContosoAutomation_managed.zip --settings-file ./config/deploy.test.json --activate-plugins --publish-changes

# 5. Production is the same command with the production settings file. Nothing
#    in the solution changes between environments. Only the file does.

DEPLOYMENT TROUBLESHOOTING CHECKLIST
Work down it in order. The first four cover most first time failures.

1. IMPORT FAILS: connection reference has no connection / cannot be resolved
   Cause  The settings file predates the reference, or ConnectionId is empty,
          or the connection does not exist yet in the target environment.
   Fix    Create the connection in the target as that environment identity,
          re-run create-settings, refill, re-import. Do not create the
          connection by editing the flow in the target.

2. IMPORT SUCCEEDS BUT THE FLOW IS OFF AND WILL NOT TURN ON
   Cause  An unbound connection reference, or the importing identity has no
          privilege on one of the connectors, or a required environment
          variable has no current value in this environment.
   Fix    Check every reference and every variable for an empty current value
          before touching the flow itself. An empty variable builds a request
          against an empty segment and fails as though the endpoint were down.

3. THE FLOW RUNS AS THE WRONG PERSON
   Cause  The connection reference was authorized by whoever ran the import
          rather than by the environment service account.
   Fix    Sign in as the service account, create the connection, repoint the
          reference in the solution, publish. Repointing in production without
          also fixing the source solution means the next import undoes it.

4. AUTHENTICATION FAILURE ACROSS SEVERAL UNRELATED FLOWS AT ONCE
   Cause  Almost never a flow fault. A password reset, an MFA re-registration,
          a revoked session or a new conditional access policy killed the
          refresh token behind a connection a human authorized.
   Fix    Short term, re-authorize. Properly, move that connection onto the
          service account or a service principal so it cannot happen again.
          Status codes and how to read them: see the support guide linked above.

5. A CHANGE MADE IN PRODUCTION KEEPS COMING BACK
   Cause  Editing a managed component in production creates an unmanaged layer
          that the next import cannot overwrite.
   Fix    Remove the unmanaged layer, make the change in development, promote.

6. MISSING DEPENDENCY ON IMPORT
   Cause  The connection reference or environment variable lives in a different
          solution from the flow that uses it.
   Fix    Keep a flow and everything it binds to in the same solution, or make
          the dependency explicit and import the base solution first.

7. ONE FLOW THROTTLES AND TAKES THE OTHERS WITH IT
   Cause  Dataverse service protection limits are counted per identity, so
          every flow sharing one service connection shares one budget.
   Fix    Split connection references by workload. With references this is a
          solution change rather than a rebuild.

8. IT WORKED IN TEST AND WRITES TO THE WRONG SYSTEM IN PRODUCTION
   Cause  A literal value in the flow definition instead of an environment
          variable, so production holds a development endpoint.
   Fix    This one does not error. Diff the settings files against the flow
          definition and move every literal out before the next promotion.

How do you fix Power Automate flows that keep failing because they run on a departed employee's connections?

When payroll, compliance or finance flows break every few weeks because they still run on a leaver's personal connections, stabilise first and restructure second. Stabilise: have an admin regain access to every flow the person owned, add co-owners, export each flow definition as a backup, and re-point the connections to an active, dedicated service account. Then make it permanent: move production flows into solutions with connection references, run them under a licensed service account or, where the connector supports it, a service principal, and inventory every flow in the tenant that still depends on one person. The service account setup above covers the identity build in detail; this section is the worked recovery.

The emergency sequence, in order. Keep the leaver's account and licence alive and block sign in rather than deleting it, because connections belong to the identity that authorised them and disappear with it. If the account has already been deleted, check with your identity team whether it can still be restored from Microsoft Entra ID's deleted users before planning a rebuild. Next, a Power Platform or environment administrator finds every flow the person owned, including flows in My flows in the default environment that nobody else can see, through the Power Platform admin center or the admin PowerShell cmdlets. Add a co-owner to each: a security group, or the service account that will run it. Export a backup of every definition before changing anything, as a package from Power Automate or by adding the flow to a solution and exporting the solution, because a failed edit on an undocumented flow is otherwise unrecoverable.

Then swap the connections, signed in as the service account, because a maker can only select connections they own or that have been shared with them. In a solution with connection references this is a change to the reference, not to each flow. Outside a solution, each flow is opened and its connections reselected. Plan the timing: the change applies to runs that start afterwards, while runs already in flight, such as one waiting days for an approval, may still be tied to the old definition and connection and fail or need resubmitting. Behaviour here can change, so check the current Microsoft documentation and, for critical processes, swap between runs, pause the trigger or kill switch while you do it, and resubmit anything that failed. Test one full run, then reassign primary ownership to the service account or a team, route platform notifications to a shared mailbox, and only then reclaim the leaver's licence. The licensing section on this page has the same rescue as a numbered checklist with commands.

The permanent structure is solution aware flows, connection references in managed solutions promoted through test to production, and an identity that belongs to the company. A service principal removes password and MFA events entirely and is accepted by connectors such as Dataverse, and solution aware flows can be owned by an application user. Many everyday connectors, including Office 365 Outlook, SharePoint, Teams and Approvals, work through a user context and do not offer a service principal connection, so they need a dedicated licensed service account. Connector support changes, so check the authentication types listed on each connector's reference page before you design around it. Most estates end with both.

An undocumented estate needs an inventory before anyone can say what depends on whom. List every environment and every cloud and desktop flow with its owner, co-owners, state and last successful run; list every connection with the account that created it and its status; and join the two, so you get the flows per owner and the connections per owner for each person, starting with leavers and single owner flows. The Power Platform admin center gives the view per environment, the admin PowerShell module (for example Get-AdminFlow and Get-AdminPowerAppConnection, with parameters that vary by module version) gives the join in one pass, and the Center of Excellence Starter Kit keeps the inventory current once installed. The tenant sweep in the licensing section on this page is a starting script. While you work through the list, add a kill switch to each critical flow: a row in a configuration table read at the start of every run, so a flow can be paused without turning it off or losing its trigger. A configuration table suits this better than an environment variable, which a running flow may keep cached, as described in our point-to-point integration rationalisation guide.

Check data loss prevention before you swap. A new service account connection in an environment whose DLP policy groups that connector differently can leave the flow suspended, and a DLP change made during the tidy up can switch off flows that were working. Diagnosing those symptoms one by one is in our Power Automate and Power Platform support guide, and a tenant wide review of DLP policies, connector classification, ownership and key person risk is part of our Dynamics 365 health check and technical audit.

• Step 1, freeze: block sign in on the leaver, keep the account and licence, and note which processes have failed and since when.
• Step 2, regain access: a Power Platform or environment administrator lists every flow and connection the leaver owned in every environment.
• Step 3, co-own: add a security group or the service account as co-owner of each flow.
• Step 4, back up: export every flow definition before any change.
• Step 5, swap: as the service account, create the connections and re-point connection references or reselect connections, between runs or behind a paused kill switch, then test and resubmit failed runs.
• Step 6, transfer: make the service account or a team the owner, route platform notifications to a shared mailbox, then reclaim the licence.
• Step 7, restructure: move flows into solutions with connection references, use a service principal where the connector supports it and a licensed service account where it does not, and promote as managed solutions.
• Step 8, inventory and govern: flows and connections per owner across the tenant, kill switches on critical flows, DLP reviewed, and the inventory re-run on a schedule.

Can Solzet manage and take over a Power Automate estate somebody else built?

The most common reason we are called about a Power Automate estate somebody else built is that a person left. One employee, often not a developer, built the automation the business now runs on. The flows sit in a personal environment rather than in a solution, the connections were authenticated with that person's account, the run history is the only documentation that exists, and Microsoft platform notices go to a mailbox that was closed the week they resigned. Nothing breaks on the day they leave. It breaks four to eight weeks later, when a password expires or a licence is reclaimed, and by then nobody can say what the flow was supposed to do or who is waiting on its output. The specific failure modes behind that, meaning connection ownership, automatic flow suspension, DLP policy changes, and premium connector licensing, are catalogued symptom by symptom in our Power Automate and Power Platform support guide. This section is about the service, not the diagnosis.

A flow takeover starts with forensic documentation rather than with fixes. We inventory every environment, solution, cloud flow, desktop flow, and app; map who owns each one and which connections, gateways, and premium connectors it depends on; read the run history to establish what genuinely still runs and what has been failing quietly for months; and rank the estate by what it costs the business when it stops. The deliverable is a written estate report plus a short runbook for each process that matters: what it does, what it depends on, how it fails, and what to do about each failure. That document is what makes the automation transferable between engineers, and it is the reason the next resignation is an HR event rather than an outage. We quote this stage as a fixed price, because it is bounded work and you should be able to buy the diagnosis without committing to the repair.

Monitoring is what stops the estate drifting back to where it was. We move production flows into solutions with connection references, re point them at a dedicated service account instead of a named employee, put a second owner on everything that matters, and route Microsoft platform notifications to a shared mailbox or Teams channel somebody actually reads. On top of that we build failure alerting inside your own tenant and, for the processes where a successful run does not prove the work was done, reconciliation checks that compare the automation against reality. A named engineer then reviews the estate on a fixed cadence. We are deliberate about what that is not: it is not a manned twenty four hour operations centre, and we will not describe it as one. If your automation needs cover through the night, that is a scope and cost conversation rather than a checkbox.

The commercials are deliberately simple, and the two halves can be bought separately. The takeover itself is fixed price, quoted before we start, so an estate nobody understands does not become an open ended invoice. What follows is either a monthly allocation of hours or ad hoc hourly work, on a B2B contract with no recruitment fee, payroll, or notice period attached. Where the audit finds that the build itself cannot be salvaged, that is a rescue rather than a takeover, and our Dynamics 365 project rescue and takeover service covers the larger version of the same discipline: environment lockdown, forensic audit, then a fixed scope reset phase with dated milestones.

• Flow takeover audit, fixed price. Estate inventory, ownership and connection map, licence exposure, run history review, and runbooks for the processes that matter. An estate of up to roughly 30 cloud flows is normally 20 to 40 engineer hours, quoted as one price before we start. Larger estates and unattended desktop flow farms are scoped from the inventory rather than guessed at.
• Remediation, fixed price per work package. Moving flows into solutions, service accounts and connection references, second owners, error handling and retries, and the monitoring build. Priced package by package once the audit has said what the packages are, so you approve each one with the number in front of you.
• Managed support, monitoring only. We build the failure alerting and the health view inside your tenant, watch it, and tell your team what broke and why. Your people do the fixing. This suits an organization with an internal maker who can act but no way of knowing something failed until a user complains.
• Managed support, dedicated allocation. A named senior engineer with context on your environments, typically 20 to 40 hours a month, covering break fix, small enhancements as processes change, licensing reviews, and release wave checks before they land. This is the common shape for a mid-market company running real automation without a platform team.
• Ad hoc hourly. Billed against a purchase order with no monthly minimum, for estates that are small and stable. It is the most expensive way to buy the same hours and the right answer when the volume does not justify an allocation.
• The rate. Solzet offers competitive rates for Microsoft certified senior engineers in Yerevan, on a B2B contract, invoiced in EUR, USD, or GBP. We do not publish a rate card: fixed price work is quoted once the scope is written down.

How do you rescue Power Automate premium connector licensing and compliance?

Premium connector licensing is the most common way a Power Automate estate becomes non compliant without anybody deciding to be. The Power Automate use rights seeded into Microsoft 365 cover standard connectors only, and the platform will happily let a maker build, save, and run a flow on a premium connector while holding nothing more than a trial. Nothing blocks it on the day it is built. The bill, or the enforcement notice, arrives at renewal or true-up, months later, usually attached to flows the finance team has never heard of. Our Power Automate and Power Platform support guide catalogues the symptoms this produces one by one; this section is the fix: how the two licence models differ, how to audit a tenant yourself, and the exact order to rescue a flow whose owner has left.

First, what actually counts as premium, because the boundary is wider than most makers think. SQL Server, Salesforce, SAP, Azure services, and every third party business system connector are premium. Dataverse is premium whenever it is used outside the context of a Dynamics 365 application the user is already licensed for. Every custom connector is premium by definition, whatever it wraps. The HTTP and HTTP with Azure AD actions are premium. The on premises data gateway is premium. Desktop flows are licensed separately again, with attended and unattended modes carrying different requirements, and AI Builder runs on its own credit pool. The practical consequence is that the cheap looking flow that reads one table over an HTTP call is a premium flow, and it is exactly the kind nobody remembers building.

Per user or per flow: the two models and how to choose. Power Automate Premium is licensed to a named person and covers every premium flow that person owns, plus attended desktop flows on their own machine. Power Automate Process is licensed to a single flow, covers unlimited users triggering that flow, and comes with a much larger daily request allocation, which is what makes it the right shape for a shared or unattended automation with no natural human owner. The arithmetic is simple once it is written down. A per user seat multiplies by headcount and is indifferent to how many flows that person builds. A per process licence multiplies by the number of automations and is indifferent to how many people use them. So the question is never which is cheaper in the abstract, it is which axis your estate grows along: makers, or shared processes. The trap we see most often is a company buying per user seats for automations that have no user, meaning scheduled integrations and unattended RPA, which then get parked on a leaver's account because somebody had to own them.

Auditing your own tenant is a bounded, repeatable job, and you should do it before Microsoft does it for you. The goal is four lists rather than one report: flows using premium connectors whose owner is not licensed for them, premium seats assigned to people who own no premium flow, flows whose owner has left or been disabled, and connections authenticated with an account that no longer exists. The Power Platform admin center will give you environments, capacity, and licence consumption, and the Center of Excellence Starter Kit will maintain the inventory on a schedule once it is installed, but for a one off audit the admin PowerShell modules get you the join you actually need faster, because the thing you are looking for is the intersection of flow, connector, owner, and licence, and no single screen shows all four. The step order below matters: build the inventory before you touch a single account, because the evidence disappears the moment a licence is reclaimed.

The rescue procedure for a flow whose owner has left is a sequence, not a set of options, and doing it out of order is what turns a twenty minute fix into a rebuild. The reason is that connections belong to the identity that authenticated them and cannot be handed to somebody else. Delete the leaver's account, or strip their licence, and the connection is gone with it; the flow does not just stop, it loses the credential that told it what it was allowed to do. So the first move is always to freeze, not to tidy. Block sign in if you must, keep the account and its licence alive, and only reclaim it once the last connection has been rebuilt under an identity that will still exist next year. Where the flow lives in a solution with connection references, that rebuild is a repointing exercise and takes minutes per flow. Where it does not, each flow has to be opened and its connections reselected by the new owner, which is the real argument for getting production flows into solutions before you need to.

There is one design decision worth making during the rescue rather than after it: what the new owner should be. A named colleague is the fastest answer and reproduces the same problem with a different name on it. A dedicated service account is the usual right answer, licensed properly, with its credentials in a vault, excluded from nothing it should not be excluded from, and owned by a team rather than a person. Better still, where the connector supports it, use a service principal, which is what Dataverse connection references accept and what removes the password rotation problem entirely. Whichever you pick, put a security group or a Dataverse team as co-owner so the flow survives the next departure, and route the platform notification emails somewhere a human reads, because the warnings Microsoft sends before it disables a flow go to the owner's mailbox and a leaver's mailbox is closed.

Solzet sells this as a fixed price licensing audit and rescue. The audit produces the four lists above with the evidence attached, a per flow recommendation of per user, per process, or retire, and a number for what the estate should cost once it is right, which in most tenants is lower than what is being paid now because the waste and the exposure sit on different flows. The rescue that follows is quoted package by package: solutions and connection references, service accounts and connection rebuilds, co-ownership and notification routing, then licence reclamation. For a tenant of up to roughly 50 flows the audit is normally 15 to 30 engineer hours, quoted as one fixed price before we start. Where the licensing problem turns out to be a symptom of a wider governance gap across apps, environments, capacity, and security roles, the tenant wide register is the governance module of our Dynamics 365 health check and technical audit rather than a bigger version of this. Where the automation is part of an implementation that has stalled altogether, the larger discipline of lockdown, forensic audit, and a fixed scope reset is our Dynamics 365 project rescue and takeover service. Send us the tenant and the symptom and we will tell you which of the three you are actually buying.

• Step 1, inventory before you touch anything. Enumerate every environment, every cloud and desktop flow, its state, its owner, and its connection references, and export it. Do this while the leaver still has a licence, because reclaiming it first destroys the record of what their connections were bound to.
• Step 2, classify the connectors. Join each flow to its connectors and mark the premium ones. Anything whose connector id does not sit in the Microsoft standard list is premium, and every custom connector is premium regardless of what it wraps.
• Step 3, catch what a connection audit misses. HTTP and HTTP with Azure AD actions are premium but appear in the flow definition rather than in the connection list, so a scan that only reads connections will pass a flow that is not compliant. Search the exported definitions for those action types as a separate pass.
• Step 4, join to licence assignment. Pull the licences held by each owner from the Microsoft 365 admin center or Microsoft Graph and match them against the flows they own. Two lists fall out of this at once: unlicensed premium usage, and premium seats held by people who own nothing premium.
• Step 5, flag the orphans. Owners who are disabled, deleted, or outside the company, connections in an error state, single owner flows with no co-owner, and flows whose last successful run is older than their schedule says it should be. These are the ones that break four to eight weeks after a departure rather than on the day.
• Step 6, decide per flow. Many makers each owning several premium flows points to per user seats. One shared or scheduled automation that many people trigger, or that no human triggers at all, points to a per process licence and a service account. Retire is a legitimate third answer and is usually the cheapest one for a fifth of any mature estate.
• Step 7, rescue in order. Freeze the leaver account, add a co-owner to every flow they own, create and license the service account, rebuild or repoint each connection under it, reassign ownership, route notifications to a shared mailbox, then reclaim the licence and watch one full business cycle before closing the ticket.
• Step 8, make it stick. Production flows in solutions with connection references, a service principal rather than a password where the connector supports it, a security group or Dataverse team as second owner, and the inventory re-run on a cadence. Without the last one the estate drifts back within two release waves.

QUESTION              POWER AUTOMATE PREMIUM      POWER AUTOMATE PROCESS
                      (per user)                  (per flow)
----------------------------------------------------------------------------
What is licensed      A named person, and every   One automation, and every
                      premium flow they own.      user who triggers it.

Cost grows with       Headcount. Each maker who   Automations. Each licensed
                      needs premium adds a seat.  flow adds a licence, no
                                                  matter how many people use
                                                  it.

Best fit              Several makers who each     A shared or scheduled
                      build and own several       process with many users or
                      premium flows for their     no human owner at all.
                      own work.

Who owns the flow     The licensed person. If     A service account or a
                      they leave, the flow        team. Survives a departure
                      leaves with them.           by design.

Desktop flows         Attended RPA on the         Unattended RPA, with the
                      user's own machine.         hosted or unattended
                                                  add-on on top.

Daily request         The smaller allocation,     The larger allocation,
allocation            pooled across the tenant.   sized for high volume
                                                  process automation.

Typical failure       Seats bought for            Licences bought per flow
                      automations that have no    where a handful of makers
                      user, then parked on        would each have been
                      somebody's account.         cheaper on a seat.
----------------------------------------------------------------------------
Rule of thumb: license the person when the estate grows by makers, license
the flow when it grows by shared processes. Anything running on a schedule
with no human behind it belongs on a process licence and a service account,
never on a named employee.

Plan names, inclusions, and request allocations are the published ones at the
time of writing and Microsoft revises them; we check the current licensing
guide before anything goes into a budget.

# Modules: Microsoft.PowerApps.Administration.PowerShell, Microsoft.Graph.Users
Add-PowerAppsAccount

$rows = foreach ($env in Get-AdminPowerAppEnvironment) {
  foreach ($flow in Get-AdminFlow -EnvironmentName $env.EnvironmentName) {

    $owner = Get-AdminFlowOwnerRole -EnvironmentName $env.EnvironmentName `
                                    -FlowName $flow.FlowName |
             Where-Object { $_.RoleType -eq 'Owner' }

    # Connector ids live on the flow definition, one per connection reference
    $connectors = $flow.Internal.properties.connectionReferences.PSObject.Properties |
                  ForEach-Object { $_.Value.api.name }

    [pscustomobject]@{
      Environment = $env.DisplayName
      Flow        = $flow.DisplayName
      Enabled     = $flow.Enabled
      OwnerId     = $owner.PrincipalObjectId
      Owner       = $owner.PrincipalDisplayName
      Connectors  = ($connectors | Sort-Object -Unique) -join ';'
      # Anything outside the standard set is premium, custom connectors included
      Premium     = [bool](($connectors | Where-Object { $_ -notin $standard }).Count)
    }
  }
}

# The join that matters: premium usage against what the owner is licensed for
$rows | Where-Object Premium | ForEach-Object {
  $skus = (Get-MgUserLicenseDetail -UserId $_.OwnerId).SkuPartNumber
  $_ | Add-Member NoteProperty Licences ($skus -join ';') -PassThru
} | Export-Csv .\premium-exposure.csv -NoTypeInformation

# Second pass: HTTP actions are premium but carry no connection reference,
# so a connection-only scan will pass a flow that is not compliant.
$rows | Where-Object { $_.Definition -match '"type":\s*"Http' }

# 0. FREEZE. Do not delete the account and do not reclaim the licence yet.
#    Connections belong to the identity that authenticated them and cannot be
#    transferred. Remove the identity and the credential goes with it.

$leaver  = (Get-MgUser -UserId 'former.employee@contoso.com').Id
$service = (Get-MgUser -UserId 'svc-automation@contoso.com').Id

# 1. Everything the leaver created, across every environment
$owned = foreach ($env in Get-AdminPowerAppEnvironment) {
  Get-AdminFlow -EnvironmentName $env.EnvironmentName -CreatedBy $leaver
}

# 2. Co-own first, so nothing is single-owner while the work is in progress
foreach ($f in $owned) {
  Set-AdminFlowOwnerRole -EnvironmentName $f.EnvironmentName `
                         -FlowName $f.FlowName `
                         -RoleName CanEdit `
                         -PrincipalType User `
                         -PrincipalObjectId $service
}

# 3. Rebuild the connections as the service account.
#    In a solution: edit the connection reference, pick the new connection,
#    publish. Minutes per flow, and no flow edit needed.
#    Outside a solution: open each flow signed in as the service account and
#    reselect every connection by hand. This is the argument for solutions.

# 4. Reassign ownership. Solution-aware flows are Dataverse workflow rows, so
#    ownership moves like any record and can go to a team rather than a person.

# 5. Route platform notices to a shared mailbox or Teams channel. Microsoft
#    warns the owner before it disables a flow, and a leaver's mailbox is shut.

# 6. Only now reclaim the licence, then watch one full business cycle,
#    including the month-end runs, before the ticket is closed.

How do you build an internal Power Platform app without buying premium licences for everyone who uses it?

Keep the licence cost proportionate to the premium work, not to the headcount. Put the premium work, meaning connectors to line-of-business systems, SQL, custom connectors and integrations, behind a small number of properly licensed flows, typically on a Process licence per flow, owned by a service identity rather than an employee. Keep the surface that hundreds of viewers and occasional users touch on standard connectors, so they do not each need a premium seat. Use Premium per user for the handful of people who build or work in premium data every day, and pay-as-you-go where usage is spiky or unknown. Then check the design against Microsoft's multiplexing rules, because several popular shortcuts look compliant and are not.

The licensing audit above answers what you are paying for today. This section answers the design question that comes before it on a new build: how to shape the app so the licence bill follows the premium work rather than the number of people who open it. The distinction that matters is between people who work in premium data and processes that do premium work. A buyer approving an invoice in Teams is not working in your ERP. The flow that posts the approved invoice into the ERP is doing premium work on the process's behalf, once per invoice, and that flow is what needs the licence. Get that distinction into the architecture before anyone builds screens, because retrofitting it means rebuilding the parts users see.

We do not quote prices, and Microsoft revises plan names, inclusions and use rights regularly, so every row below describes the shape of a licence rather than its cost. Confirm the specifics against the current Microsoft Power Platform licensing guide, or with your licensing partner, before a design goes into a budget. Where the honest answer is that no licence shape fits, because hundreds of occasional users genuinely need to read and write the same business records, a platform licensed per user may be the wrong platform, and a custom CRM or business application without Microsoft licensing is the alternative we build.

• Separate the two populations first. List who builds and works in premium data daily and who only submits, approves or views. The first list is usually short and gets the per user or app licences; the second stays on standard connectors.
• Give each piece of premium work its own flow with a clear job. One flow that posts approved invoices, one that syncs customer records, one that calls the credit check, each licensed, owned by a service identity and in a solution with connection references.
• Prefer a service principal as the flow identity where the connector supports it, and license the flow rather than the identity, since a service principal cannot hold a user seat.
• Keep the user surface honest. Standard connectors for capture, approval and notification, with results shown as status and outcome rather than a live window onto the premium system.
• Put pay-as-you-go on the environments where usage is genuinely unpredictable, and move to assigned licences once the numbers are known.
• Write the licensing rationale into the solution documentation per flow and per app, so the next audit reads a decision rather than reverse engineering one.

Which Power Platform licence-saving designs look compliant but are not?

Microsoft's multiplexing rules say that pooling access through an intermediary, whether a service account, a shared connection, a sync into another store or a custom front end, does not reduce the number of licences required. Users who reach premium data indirectly are generally treated as if they reached it directly. That is the line the architecture above has to stay on the right side of. A licensed flow that does a job for a process is legitimate design. A standard surface that exists to give unlicensed people a working window onto premium data is multiplexing with extra steps, and it tends to be discovered at renewal or true-up, not when it is built.

The designs below are the ones we are most often asked to approve, or find already in production. Each one saves licences on paper. Where a design sits close to the line, we set out the facts and the options and recommend confirming it with Microsoft or your licensing partner in writing, because we build Power Platform solutions and do not give contractual licensing rulings. The wider build, including environment strategy and the Power Apps side of the same decision, is part of our Power Platform consulting and development work.

• Copying premium data into a standard store so people can read it. A scheduled flow that mirrors SQL or Dataverse records into a SharePoint list or an Excel file every night so unlicensed users can work from the copy. The copy does not change who is accessing the data.
• One Premium seat on a shared service account. Dozens of premium flows owned by a single licensed account and run by a whole department through shared connections. A per user licence covers that user, not everyone using the account.
• A standard-connector app as a thin proxy. A canvas app on SharePoint where every screen is really a form over the premium system, with a flow writing each change straight through on behalf of the user. The more the flow behaves like the user working in the premium system, the less it looks like process automation.
• Calling it in context when it is not. A general integration placed in the same solution as a Power App and described as in the context of the app so the app licence appears to cover it.
• HTTP actions to avoid a premium connector. Calling the same API through an HTTP action to avoid a premium connector. The HTTP actions are premium themselves, as the audit steps above explain.
• Leaving it on a trial. Premium flows built on a trial or developer plan that quietly became production. The platform lets them run; the use rights do not follow.

Can Power Automate integrate with non-Microsoft systems?

Yes - and this is where Power Automate often delivers the most value. The platform ships with 1,000+ pre-built connectors covering major SaaS applications (Salesforce, SAP, ServiceNow, DocuSign, Slack, Jira, HubSpot, Stripe, Twilio, and hundreds more). For systems without a pre-built connector, Solzet builds custom connectors using the OpenAPI specification - wrapping any REST API as a reusable Power Automate action that your citizen developers can use without writing code. For legacy on-premises systems with no API at all, desktop flows bridge the gap through UI automation. Common cross-platform integrations we build include: Dynamics 365 to SAP for order and inventory sync, SharePoint to DocuSign for contract signature workflows, Dataverse to Stripe or Chargebee for subscription billing reconciliation, and Teams to Jira for development task creation from support tickets. Solzet architects these integrations with data mapping documentation, transformation logic, and idempotency patterns to prevent duplicate records.

How do you automate rekeying between systems when one of them has no API?

Pick the most durable route into each system, in this order, and only drop a rung when the one above genuinely does not exist. First, a real API: a certified connector, or a custom connector built from the vendor's API definition. Second, a database or file interface: reading views or writing to a staging table the application imports from, or a structured file dropped to an agreed folder or SFTP location. Third, a scheduled export and import with a reconciliation of what arrived against what was sent. Fourth, and only as a last resort, desktop automation that operates the screen, accepted with its fragility written down. Most teams rekeying between five systems find that only one or two genuinely need the bottom rung.

The order is about what breaks and who notices. An API has a contract the vendor maintains. A staging table or file format is a contract you agree with the system owner, which is why it needs one named person on each side. An export and import has latency and partial files built in, so it is only safe with counts and control totals compared on every run. A desktop flow has no contract at all: a screen change, a slow morning or a signed in session can stop it, and it can type the wrong value into the right field without raising an error. That does not make it wrong for a 2003 application with no other way in. It means the flow has to be engineered for production rather than recorded, as set out in Power Automate Desktop production reliability, and the business has to know which step depends on it.

Two rules hold on every rung. Never write directly into another application's transaction tables, because that can bypass its business logic and its vendor support terms; write to a staging table or import routine the system owner controls. And where an interface needs creating on the other system, such as an export, a staging table or an import job, we specify it and that system's owner or vendor builds it. Effort estimates and wave planning for each integration class are covered in our process automation portfolio roadmap.

How do you build an approval chain across disconnected systems that cannot lose or double-book a request?

Keep the state of each request in Dataverse, not in a flow run. A flow run that waits for an approval holds its progress in memory, and Microsoft documents a maximum run duration after which pending steps time out, so a request that sits in someone's inbox too long, or a flow that is turned off and on during a fix, can simply disappear. Give the process an approval request table instead, one row per request, with its status, current approver, due date, source record key, target system reference and posting status. Flows then become workers that move a row from one status to the next, and any of them can stop and restart without losing where the request had got to. Why the process needs its own row rather than only a flow is also answered in the FAQ on Dataverse for business process automation on this page.

Escalation should be a schedule, not a wait. A scheduled flow that queries rows past their due date and reassigns, reminds or escalates them keeps working even if the flow that sent the original approval failed, and the rule is visible as data rather than buried in a timeout setting. Record every decision as its own row: who approved, when, on which version of the amounts and lines, with the comment, from which channel. Restrict update and delete on those rows and enable Dataverse auditing on the table, so the approval history is evidence rather than a reconstruction from run history that ages out.

Posting into the target system must be idempotent, because every reliable integration retries and a retry must not book the same invoice or order twice. Generate an idempotency key when the request is approved, store it on the row, and send it with the posting: into an alternate key or external reference field where the target supports one, or checked by a lookup on that reference before creating. Set the posting status to Posting before the call and Posted with the target document number after it, so a restart can tell a request that was never sent from one that was sent but not confirmed. Then prove nothing was lost with a daily reconciliation that compares approved, posted and confirmed counts and totals across the systems, lists every difference as an exception row with an owner, and alerts when the check itself did not run. The broader build of Dataverse data models, model-driven apps for approvers and custom connectors sits in our Power Platform development service, and outbox and kill switch patterns for integrations that keep failing are in our point-to-point integration rationalisation guide.

• Step 1, map the chain: every system, every handoff, who rekeys what today, and which rung of the ladder each system can offer.
• Step 2, create the approval request table and the decision table in a solution, with statuses, due dates, idempotency key, target reference and posting status, and auditing enabled.
• Step 3, capture requests into a row first, from a form, a Power Apps screen, an inbound file or an export, before any approval is sent.
• Step 4, send approvals from the row through Teams or Outlook, and write each response back as a decision row with the approver, time and data version.
• Step 5, run escalation as a scheduled flow over overdue rows, with reassignment and delegation rules held as data.
• Step 6, post approved rows to each target system through the highest available rung, using the idempotency key and the Posting and Posted statuses.
• Step 7, add a kill switch row in a configuration table that every posting flow reads at the start, so posting can pause during an incident without losing approved work.
• Step 8, reconcile daily across all systems on counts and totals, raise exceptions with owners, and alert on silence as well as on failure.