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.

Business Process Automation (BPA) with the Power Platform

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 vs. Zapier, Make, n8n for 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.

Managed Services & Flow Takeover

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 quotes in the USD 40 to 70 per hour band for a Microsoft certified senior engineer in Yerevan, on a B2B contract, invoiced in EUR, USD, or GBP. Fixed price work is quoted from that band once the scope is written down.

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.