Halilcan Soran

Tag: Governance

  • How to Run a Power Platform Licensing Audit Before You Ship

    How to Run a Power Platform Licensing Audit Before You Ship

    Checklist and connector diagram representing a power platform licensing audit before solution rollout

    By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published August 3, 2026

    A working app in your dev environment tells you nothing about what it costs to run for 300 people. I have watched a solution sail through UAT and then stall at rollout because one flow used an HTTP action, which flipped the whole thing premium, and suddenly every user needed a license nobody had budgeted. A structured power platform licensing audit takes an afternoon and catches this before procurement finds out the hard way. By the end of this walkthrough you will have a one-page map of every connector, every flow context, and every license gap in your solution.

    Step 1: Inventory Every Connector in the Solution

    Open the solution in make.powerapps.com, then go through each app under Details and check the connections list. Premium connectors carry the diamond Premium tag. SharePoint, Outlook, and Teams are standard. SQL Server, Dataverse, HTTP, and every custom connector are premium. I wrote a full walkthrough on building custom connectors, and the licensing footnote there matters: they are always premium, even when they wrap a free public API.

    Do not stop at the app level. Open every flow in the solution and read the actions, because the HTTP action never appears in the app’s connection list. Search the flow definitions for shared_http if you want to be thorough. This is where most surprises hide.

    Step 2: Trace the Context of Every Flow

    Licensing for flows depends on how they run, not what they do. A flow with a Power Apps (V2) trigger, packaged in the same solution as the app that calls it, runs in the context of that app and is covered by the app user’s Power Apps license. A scheduled or automated flow that runs standalone is not covered by anything. It needs Power Automate Premium on the owner, or a Process license attached to the flow itself.

    While you are here, check who owns each standalone flow. A flow running on the personal license of someone who leaves the organisation gets suspended when that license is removed. Move business-critical standalone flows to a service account or a Process license now, not after the first silent outage. If your flows rely on desktop automation, the selector strategy you choose also affects maintenance overhead — Selectors vs Image Recognition for Power Automate Desktop Flows covers the tradeoffs in detail.

    Step 3: Map Real Users to Real Licenses

    Pull the actual license assignments from the Microsoft 365 admin center, or with Get-MgUserLicenseDetail in PowerShell. Do not assume everyone has the same SKU. Mixed tenants are the norm, and the F3 users in the warehouse do not have what the E5 users in finance have.

    Then do the arithmetic. Per-app runs 5 dollars per user per app per month, Power Apps Premium runs 20 per user per month. The break-even sits at four apps per user. If your solution is app number one for a group of frontline workers, per-app wins. If the same 50 people will end up using five internal apps within a year, per-user is cheaper and you should say so before someone locks in the wrong plan. The Microsoft licensing overview has the current SKU details.

    Step 4: Check API Request Limits and Dataverse Capacity

    Licenses carry daily Power Platform request entitlements, and they are not generous at the low end. A Power Apps Premium user gets 40,000 requests per 24 hours. A user running on a seeded Microsoft 365 license gets 6,000. A flow that loops over 2,000 SharePoint items with three actions per item burns 6,000 requests in one run. The request limits documentation lists the allocations per SKU. Check your heaviest flow against the lowest entitlement in your user base.

    Dataverse capacity is the other quiet cost. If your solution logs every run or every submission into a Dataverse table, estimate table growth per month against your tenant’s storage allocation. Capacity overages show up on someone else’s budget line, which means they show up as an angry email. If you are also planning to add AI features to those Dataverse tables, the new Prompt Columns in Dataverse column type adds storage considerations of its own that are worth factoring in early.

    Step 5: Test With a Standard-Licensed Account

    Your dev account masks everything. It almost certainly has per-user premium plus an E5, so every connector works and every flow runs. Create a test user with exactly the license mix your real end users have, share the app with it, and run every screen and every flow path. If there is a gap, this account hits the premium license prompt immediately, and you fix it before rollout instead of during it. In my experience, this single step catches more licensing problems than the previous four combined, because it tests the actual runtime entitlement chain instead of your reading of the documentation.

    The Final State

    You now have a connector inventory with premium flags, a flow list with run contexts and owners, a user-to-license map with the per-app versus per-user math done, and a request limit sanity check. That one page is the difference between a rollout and a procurement escalation.

    The pitfall to watch: child flows. A standard-looking parent flow that calls a child flow containing one HTTP action inherits the premium requirement, and nothing in the app’s connection list will tell you. Open every child flow. Read every action. It takes ten minutes and it is the ten minutes people skip.

    Frequently Asked Questions

    How do I run a Power Platform licensing audit before deploying a solution?

    Start by inventorying every connector in your solution and flagging anything premium, such as SQL Server, Dataverse, HTTP, or custom connectors. Then trace how each flow runs, since standalone flows need separate licensing while flows triggered by a Power Apps canvas app can be covered by the user’s Power Apps license. Finally, pull real license assignments from the Microsoft 365 admin center to confirm every user has the right SKU before rollout.

    What is the difference between a standard and a premium connector in Power Platform?

    Standard connectors like SharePoint, Outlook, and Teams are included with most Power Platform licenses at no extra cost. Premium connectors, which include SQL Server, Dataverse, HTTP, and all custom connectors, require users to hold a Power Apps or Power Automate Premium license to use them.

    Why does a single HTTP action in a flow affect licensing for all my users?

    The HTTP action is a premium connector, so any flow that includes it requires the users who interact with it to hold a premium license. Because this action does not show up in an app’s connection list, it is easy to miss during a review and can trigger unexpected licensing costs at the point of deployment.

    When should I check who owns standalone flows in my Power Automate solution?

    You should verify flow ownership before any production rollout, not after an incident occurs. If a standalone flow runs on a personal license and that person leaves the organisation, the flow will be suspended when their license is removed, causing silent failures in business processes.

    About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

  • Inside a Power Platform Center of Excellence: Why Most Setups Stall in Month Three

    Inside a Power Platform Center of Excellence: Why Most Setups Stall in Month Three

    Power Platform Center of Excellence setup architecture diagram

    By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published May 3, 2026

    Most people think a Power Platform Center of Excellence setup works like installing a product. You import the CoE Starter Kit solution, run the setup wizard, point it at your tenant, and the dashboards fill up. Job done.

    That is the surface behaviour. The actual mechanism underneath is a chain of dependencies, sync jobs, and admin connector calls that quietly degrade if any one link breaks. I keep seeing teams hit this on LinkedIn and in conversations with people at other organisations. The kit looks healthy for six weeks, then the inventory stops matching reality and nobody knows why.

    Let me walk through what is actually happening underneath.

    What you see on the surface

    You install the CoE Starter Kit, the wizard provisions a Dataverse environment, and a set of cloud flows starts populating tables like Environments, Apps, Flows, and Makers. The Power BI dashboard lights up. You see a maker count, an app count, an orphaned resource list.

    From the outside, it looks like the kit is scanning your tenant. It is not scanning anything in real time. Every number you see is the result of scheduled flows that ran sometime in the last 24 hours, hit admin connectors, paginated through results, and wrote rows into Dataverse. The dashboard is just a read on that table.

    This matters because the moment those flows stop succeeding, your dashboard stops being true. And it does not tell you it stopped being true.

    The underlying mechanism

    The CoE kit runs on a stack of sync flows. The most important ones are Admin Sync Template v3 (environments), Admin Sync Template v4 (apps and flows), and the maker activity flows. Each one authenticates as the service account you set up during install and calls the Power Platform for Admins, Power Apps for Admins, and Power Automate Management connectors.

    Three things have to be true for those flows to keep working. The service account needs an active Power Platform Administrator or Global Administrator role. The account needs a per-user Power Automate licence with the right premium entitlements, because the admin connectors are premium. And the account needs to not be hitting throttling limits while paginating through a tenant with thousands of resources.

    The CoE sync flows are exactly the kind of workload that hits both platform-level and connector-level throttling, because they loop through every environment and every app in the tenant in one run. Getting your Power Automate error handling patterns right matters here — transient throttling errors need to be caught and retried differently from terminal failures, or the sync silently drops data.

    Where it breaks

    The most common failure mode is not the install. It is month three.

    The service account password expires, or MFA gets enforced tenant-wide, or someone removes the admin role because of a security review. The flows start failing silently. Default retry logic masks it for a week or two. Then the runs hit timeout and stop entirely. The dashboard freezes on stale data, but the numbers still look plausible, so nobody notices.

    The second failure mode is scale. The kit was designed for small to medium tenants. If you have 40,000 apps and 80,000 flows across hundreds of environments, the sync flows do not finish inside the 30-day Dataverse retention window for run history. You lose visibility into your own automation.

    The third one is the licensing trap. Teams install the kit on a trial, then move to production without giving the service account a proper premium licence. The flows technically run, but premium connectors throw 403s on specific calls, and only some tables populate. Half the dashboard works. The other half lies.

    What this means for how you build it

    Treat the CoE as a product you operate, not a kit you install. That changes a few decisions.

    Use a dedicated service principal with certificate auth where the connectors support it, instead of a user account with a password. The service principal does not expire, does not get MFA, does not get caught in a leaver process. Where you must use a user account, document it, monitor it, and put the password rotation in a runbook owned by a real team.

    Build a health check flow that runs daily and alerts when the last successful sync timestamp on each core table is older than 48 hours. Do not trust the dashboard to tell you the dashboard is broken.

    For larger tenants, split the sync flows by environment group instead of running them tenant-wide. The kit supports filtering, and partial visibility refreshed daily beats full visibility refreshed never.

    Decide what governance question the CoE is actually answering for you before you build dashboards on top of it. Inventory is not governance. A list of 12,000 apps with no owner attached is just a longer problem. The broader challenge of Power Platform governance that does not kill adoption is worth thinking through before you design your DLP and ownership policies around what the CoE surfaces, because the data is only useful if makers trust the system enough to stay inside it.

    The CoE Starter Kit is genuinely good engineering. It just is not magic. If you are starting to build out more automation on top of your tenant inventory, the question of why Power Automate is still worth learning in 2026 is a good framing for where to focus the team’s time once the CoE is stable. If you want to compare notes on how other teams are running theirs, I am always up for that conversation.

    Frequently Asked Questions

    Why does my Power Platform center of excellence setup stop working after a few weeks?

    The CoE Starter Kit relies on scheduled sync flows that call admin connectors on a recurring basis. If the service account loses its licence, hits throttling limits, or has a permission issue, those flows fail silently and your dashboards show stale data without any obvious warning.

    What licences and permissions does the CoE Starter Kit service account need?

    The service account requires either a Power Platform Administrator or Global Administrator role, plus a per-user Power Automate licence that covers premium connectors. Without the premium entitlement, the admin connector calls used by the sync flows will not run.

    How do I know if my CoE sync flows have stopped running correctly?

    The dashboards will not alert you automatically when sync flows fail, so you need to monitor flow run history directly. Comparing your app and environment counts against known tenant activity over time is a practical way to spot when the inventory has drifted from reality.

    Why does the CoE Starter Kit struggle with throttling on large tenants?

    The sync flows paginate through every environment and every app in a single run, which generates a high volume of connector calls in a short period. This makes them prone to both platform-level and connector-level throttling, so transient errors need to be handled with retries rather than treated as permanent failures.

    About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

  • Power Platform Governance That Does Not Kill Adoption

    Power Platform Governance That Does Not Kill Adoption

    Power Platform governance that does not kill adoption in an enterprise environment

    By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published April 24, 2026

    I keep seeing the same pattern on LinkedIn and in conversations with people at other organisations. Power Platform governance gets handed to a security team, they lock everything down, and six months later nobody is building anything. Then someone writes a post about low adoption and blames the makers. It is not the makers. It is the governance design.

    Good Power Platform governance is not about stopping people. It is about making the safe path the easy path. If your governance model forces a citizen dev to file three tickets and wait two weeks to use a SharePoint connector, you do not have governance. You have a queue.

    The two failure modes of Power Platform governance

    Every governance setup I have seen fails in one of two ways.

    The first is the lockdown. Default environment is disabled for everyone. Every connector is in the Blocked DLP group unless explicitly approved. New environments require a business case signed by three people. Makers give up and go back to Excel macros. Shadow IT grows in Teams and OneDrive where nobody is watching.

    The second is the free-for-all. Everyone builds in the default environment. No DLP. No naming conventions. Flows owned by people who left two years ago still run in production because nobody knows what they do or who to ask. The CoE Kit is installed but nobody looks at the dashboards.

    Both end in the same place. Leadership decides Power Platform does not work for the enterprise. The real problem was never the platform.

    What actually works

    The teams I talk to who have this working treat governance as a product with makers as the users. That framing changes everything.

    They have a managed maker environment that anyone in the org can request access to in under an hour. Standard connectors are in the Business group. Premium and risky connectors need justification but the path is documented. People know where to go.

    They have a promotion path from maker environment to a shared Dev, then UAT, then Prod. Each environment has different DLP settings and the differences are written down. This is the part most teams miss. I wrote about this before in the context of Power Platform agents and GitHub integration, where a connector sitting in Business in Dev and Blocked in Prod silently kills an agent at go-live. Same pattern applies to any flow or app that crosses environments.

    They have an ownership policy that actually runs. When someone leaves, their flows and apps get reassigned within a defined window, not forgotten. The Power Platform PowerShell modules handle most of this if you script it. The CoE Kit is fine for inventory but I have stopped relying on it as the source of truth for ownership because the lag is too long.

    DLP policies that do not punish makers

    Most DLP policies I see are written by someone who has never built a flow. They block the HTTP connector by default and then wonder why nobody integrates with anything. Or they put SharePoint and Outlook in different data groups and break every approval flow in the tenant.

    The approach that works is starting from what makers actually need and working backwards. Look at what the top 50 flows in your tenant use. Build your Business data group around that. Put the genuinely risky stuff like custom connectors to unknown endpoints in Blocked. Review quarterly, not yearly.

    And write the policy down in plain language somewhere makers can find it. Not a SharePoint page buried in the IT site. Pin it in the Teams channel where makers ask questions.

    The CoE Kit is not a governance strategy

    I see this a lot. A team installs the CoE Kit, enables a few flows, and calls it done. The CoE Kit is a starting point. It is inventory and some reporting. It is not a governance strategy on its own.

    The manual updates every few months genuinely do break things. The premium license requirement for some of the governance features is a real cost. The handoff complexity when the person who installed it leaves is a known problem. None of this is a secret.

    What I have seen work is using the CoE Kit for what it is good at, which is discovery, and building lightweight custom tooling for the parts that matter to your org. Inactivity policies. Ownership reassignment on leaver events. Environment request intake. None of this needs to be fancy. A few flows and a SharePoint list go a long way, which ties back to a point I have made before about SharePoint being the right backend for most Power Platform needs.

    Governance is a product

    The shift that changed how I think about this is treating governance as a product with makers as the customer. If makers avoid your governance model, it is broken. If they route around it, it is broken. If they ask for exceptions constantly, it is broken.

    The safe path has to be the easy path. Otherwise adoption dies and you spend the next year explaining to leadership why the platform did not deliver. If you are still building out the foundation, understanding why Power Automate is still worth learning in 2026 is a good place to start before layering governance on top of a platform your team is not yet fluent in.

    Frequently Asked Questions

    What is Power Platform governance and why does it matter?

    Power Platform governance is the set of policies, environments, and controls that shape how people build and share apps, flows, and agents in your organisation. When designed well, it protects the business without slowing down the people trying to do useful work. When designed poorly, it either locks everything down or lets chaos grow unchecked.

    How do I set up Power Platform governance without killing adoption?

    Treat governance as a product where makers are the users, not a security checklist applied on top of them. Give people a managed environment they can access quickly, document the DLP policies clearly, and make the approved path easier than any workaround. If the process to get started takes weeks, people will find another way.

    Why does my Power Platform app break when it moves from Dev to Production?

    This usually happens because DLP connector policies differ between environments and those differences are not documented anywhere. A connector allowed in your Dev environment may be blocked in Production, which silently breaks apps or flows at go-live. Writing down the DLP differences for each environment and testing against them before promotion prevents this.

    When should I reassign Power Platform flows and apps after someone leaves the organisation?

    Reassignment should happen within a defined window as soon as someone leaves, not reactively when something breaks. Flows and apps owned by former employees can keep running in production for years with no clear owner, which creates a serious operational and security risk. Power Platform PowerShell modules can automate much of this process.

    About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

  • Low-Code Roundups Answer a Question Enterprises Never Ask

    Low-Code Roundups Answer a Question Enterprises Never Ask

    By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published April 14, 2026

    Updated August 2026 added the agent governance angle, updated the DLP and Managed Environments context, and sharpened the stakeholder response section now that AI agent roundups have joined the pile.

    I came across another Zapier Blog roundup ranking the best low-code automation platforms, and it reminded me of a conversation I keep having internally. Someone reads a list, sends it over, and asks why we are not using one of the other tools. The question sounds reasonable. The comparison is not. For teams doing enterprise automation on Power Platform, these lists are built around the wrong frame entirely.

    Comparison Lists Are Built for Buyers Who Do Not Exist in Enterprise

    Roundups are useful for one type of reader: someone at a small company, starting from scratch, no existing infrastructure, who needs to pick a tool this week. That reader exists. Most people building automation inside a large organisation are not that reader.

    Enterprise teams are not choosing platforms in a vacuum. They operate inside a tenant. There is an existing Microsoft 365 agreement. There is an IT security function that has already decided what can touch production data. There is a DLP policy, or there is about to be one. The question is never which platform wins a feature comparison. The question is what is already inside the perimeter and how far it can go.

    When the starting point is an E3 or E5 agreement, Power Platform is not an option on a menu. It is already there. The real conversation is how deeply to use it, not whether to adopt it.

    What Roundups Get Wrong About Power Platform at Scale

    These lists treat features as equivalent when they are not. Power Automate supports HTTP calls, so does Zapier, check. Both have triggers and conditional logic, check and check.

    What they do not cover is governance when you have hundreds of flows built by dozens of makers across multiple environments. Power Platform has environment-level DLP policies that control which connectors can touch which data. You can block a connector tenant-wide from the admin centre. Managed Environments let you enforce solution-aware deployments, sharing limits, and maker onboarding rules before anything goes near production. None of that shows up in a feature checklist. It is architecture you depend on when something breaks at 2am and you need to know exactly what touched what.

    Connector governance also ties directly into Entra ID. Service principal authentication, conditional access, managed identities for flows calling Azure resources. These are not nice-to-haves. They are what your security team asks about before any automation touches HR or finance data. A comparison that skips this is not comparing the thing an enterprise is actually buying.

    The Agent Layer Made This Worse, Not Better

    This is the part I added in 2026, because the roundup problem has spread. The lists now rank agent builders too. Copilot Studio versus a dozen standalone agent platforms, scored on how fast you can ship a chatbot.

    Same mistake, higher stakes. An agent is an automation with judgement. The governance question is not whether it can call a tool, it is whether you can see every action it took, restrict which knowledge sources it reads, and audit what it told whom. Copilot Studio inherits the tenant’s DLP, audit log, and Entra identity model. Agents built there show up in the same admin centre as everything else. A standalone agent platform gives you a shinier canvas and a second, separate governance problem.

    If a flow leaking data was bad, an agent leaking data is worse, because the agent decides on its own what to fetch. The lists ranking these tools almost never mention it.

    The Tenant Boundary Argument Nobody in These Lists Makes

    Everything inside your Microsoft tenant shares an identity layer, a licensing model, an audit log, and a set of compliance controls. Power Platform lives inside that boundary by design. When a flow calls Dataverse, or a Copilot Studio agent hands off to an agent flow, or a Power App writes back to SharePoint, nothing crosses a boundary. It is all one governance envelope.

    Bring in a third-party automation tool and you introduce a boundary crossing immediately. Data leaves the tenant. Authentication is managed separately. Your audit trail splits. Your DLP logic does not follow. That is not an argument against ever using other tools. It is the argument comparison lists never make, because they are not written for people carrying compliance obligations across a 10,000-person organisation.

    I have written before about how throttling in Power Automate has two distinct layers, platform-level and connector-level, and how knowing which one you are hitting matters. The same principle applies here. Platform selection has two layers: what the tool can do, and what the tool is allowed to do inside your perimeter. Roundups only ever address the first.

    How to Respond When Someone Senior Sends You One of These Articles

    This still happens, and more often now that agent roundups exist. Someone reads a list, sees another tool scored well on ease of use or pricing, and asks a fair question. Here is how I handle it, and it is roughly what I tell people I talk to at other orgs when they run into the same thing.

    Do not get defensive about Power Platform. That reads as tribal and closes the conversation. Reframe instead. The roundup answers “which tool is easiest to try”. The enterprise question is “which tool can we govern, audit, and scale without adding a new identity boundary”. Say it in one sentence and most stakeholders get it immediately.

    Then offer the honest caveat. There are cases where a third-party tool genuinely fits, usually at the edges, integrating with systems Microsoft connectors do not cover well. Name that possibility yourself. It shows you evaluated the option instead of dismissing it, and it makes the boundary argument land harder for everything that stays inside.

    The comparison lists will keep coming. The frame is the thing worth defending, not the logo.

    About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn