MS Dynamics Guys home

Hire Power Platform experts

Hire Power Automate developers

In short

MS Dynamics Guys provides Power Automate developers who join your team and help keep your cloud flows working when people, accounts and processes change. They build, repair and maintain flows around Microsoft Dynamics 365, Dataverse and Microsoft 365. The work covers connectors, approvals, error handling, failure alerts and retries that do not create duplicate records. Your lead decides which flows come first and approves each release. Before a flow reaches production, we agree with you who owns it and which accounts its connections use.

Discuss automation capacityReview your flows as a project

When a Power Automate developer from MS Dynamics Guys fits

A Power Automate developer from MS Dynamics Guys fits teams whose important processes run on cloud flows, or soon will.

The role includes flow design as well as fixes. The developer proposes approval routes and error paths, then builds, tests and maintains the flows your lead prioritizes. Your process owner decides the approval rules.

A good fit when

  • Approval or update flows fail, stall or create duplicate records, and nobody on your team has time to find the cause.
  • The person who built your important flows has left or changed roles, and the flows still run under that person's account.
  • Automation requests around Microsoft Dynamics 365 or Microsoft 365 are queuing up. Your makers need someone to build the harder flows and review theirs.
  • Important flows sit outside solutions, so nobody can change their owner in place or switch their connections without editing each flow.
  • A process owner on your side can decide the approvers, the limits and what happens after a rejection.

Another role or service fits better when

  • Most of the work is app screens and forms, with a few flows behind them. A Power Apps developer fits better.
  • One release must change an app, its flows and its Dataverse tables at the same time. That combined work suits a Power Platform developer.
  • A rule must run inside the save, whatever app, flow or integration saves the record. A simple rule, such as setting a value or checking data, can be a Dataverse business rule with table scope, which needs no code. Other rules are plug-in work for a Dataverse developer.
  • The main need is a high-volume data sync between systems. That calls for an integration design with record ownership, sync timing and reconciliation.
  • You need a defined flow review or repair rather than a developer working through your backlog. A scoped Power Platform consulting project starts with the flows, deliverables and acceptance checks to agree.

What a Power Automate developer can own in your team

The developer takes flow work from your backlog. Each change arrives in your solutions, ready for your lead's review, with notes your team can maintain.

Typical tasks and deliverables:

  • Build automated, scheduled and manually triggered cloud flows, with trigger conditions so that each flow runs only when it should.
  • Build flows on Microsoft Dynamics 365 Sales or Customer Service records, which these apps keep in Dataverse tables. Each trigger watches only the rows and columns that matter, so routine edits do not start the flow.
  • Build flows for Microsoft Dynamics 365 Business Central on its connector. It is a premium connector with triggers for record changes and approval requests, and it allows 300 calls per connection every 60 seconds.
  • Design approvals: who approves, in which order, what happens after a rejection, and how reminders and escalation work.
  • Use standard and premium connectors first. Build a custom connector only when a system offers an application programming interface (API) but no connector.
  • Add error handling to each flow: scopes that catch failures, and Run after settings that decide which step runs when another step fails. Each failure gets a clear failed status and a message to a named person.
  • Design each write so that it can run twice safely. A retry or a resubmitted run then updates the record instead of creating a second one.
  • Package flows in solutions with connection references and environment variables. Deploy them to test and production as managed solutions.
  • Write test cases for each change, including failure and repeat-run cases, and run them in your test environment.
  • Set up failure alerts, keep the flow inventory current and write a short runbook for each important flow.
  • Diagnose failed runs from run history, fix the cause and resubmit the runs that should still complete.

What stays with your team. Some decisions and permissions belong to your people:

  • A process owner decides the rules, approvers and limits for each flow, and confirms the result in testing.
  • An administrator grants access, assigns licenses and plans data policy changes. Approvals are stored in Dataverse. In an environment other than the default one, the first approval flow must be run by a user with an administrator role.
  • Your team decides who owns each production flow and which accounts its connections use.
  • Your lead approves each release. The developer prepares it.

Flows can sit in solutions only in environments that have Dataverse. Without Dataverse, the developer can still build and fix flows, but they cannot move between environments as solutions or change owner in place.

Who maintains flows from MS Dynamics Guys developers when accounts, connections or processes change?

Your team maintains the flows, with help from the MS Dynamics Guys developer while the engagement runs. We plan for that from the first flow. Before a flow reaches production, your team names its owner, decides which accounts its connections use and chooses who receives failure alerts. Production flows are not left owned by the developer's own account.

When a person or an account changes

An automated or scheduled cloud flow runs under its owner's license. A manually triggered flow runs under the license of the person who runs it. Power Automate sends failure emails to the flow's owners. If the owner leaves your organization, the flow drops to a lower performance level and the remaining owners are notified. Unless someone acts, the flow is turned off after 14 days. Steps that use the departed person's connections might also fail.

Inside a solution, an owner, co-owner or administrator can assign a new owner in place. After the change, the previous owner stays on the flow as a co-owner. For automated and scheduled flows, the new owner's license can take up to seven days to apply, unless someone edits and saves the flow. Outside a solution, the owner cannot change in place, because the owner is part of the flow's identity.

The developer therefore builds production flows in solutions, where the environment has Dataverse. Each one is owned by an account or a service principal that your organization controls. A service principal is an identity in Microsoft Entra ID that stands for an application, not a person. If you release through pipelines in Power Platform, the identity that deploys a solution owns the flows in it. A standard deployment requested by the developer would make the developer the owner. Our page on Power Platform developers covers how to choose the deploying identity.

When a connection, a setting or a policy changes

Flows built in a solution use connection references instead of direct connections. A flow moved into a solution keeps its direct connections until the developer switches it. When the account behind a connection changes, your administrator updates the connection reference once, and the flows that use it follow. A flow can be turned on only by someone who owns its connections or can use them through sharing. Settings such as a site address sit in environment variables, so they also change in one place. Flows can take up to an hour to pick up a new value.

Data policies, the connector rules that your administrator sets, can change too. When a data policy changes, flows that break the new rules are suspended, usually within an hour. Before such a change, the developer compares it with the flow inventory and lists the flows it would stop.

When the business process changes

A new approval limit or an extra approver is a change to the flow. It follows the same path as any other change: development, test, your approval, then production. Two points need a decision before the release:

  • Approvals already waiting. A run can wait up to 30 days before its pending steps time out. Decide whether open requests finish under the old rules or restart under the new ones.
  • Events while a flow is off. Polling triggers check for new events at regular intervals. Webhook triggers are notified when an event happens. When a flow is turned off and on again, polling triggers process the events they missed, while webhook triggers skip them. The release plan says how missed or repeated records are handled.

When the engagement ends, the handover covers every flow the developer changed: its owner and co-owners, connection references, alerts, known limits and runbook. Your administrator then removes the developer's access. If the developer leaves the engagement early, the replacement terms agreed in writing apply. Before the last day, the developer hands over open work in writing. The aim is that your team can run and change the flows without the developer.

Skills we assess in a Power Automate developer

Every candidate gets the same practical task: a cloud flow that fails, with its run history. They find the cause and write a recovery plan. The table shows what we review and the evidence the review produces.

Power Automate developer skills, how MS Dynamics Guys reviews them and the evidence the review produces
SkillHow we review itEvidence the review produces
TriggersFrom run history, the candidate explains why a flow ran twice or did not run. They fix it with a trigger condition or a different trigger.The diagnosis, in the candidate's own words
Error handlingThey add scopes that catch failures, Run after settings and a clear failed status to a flow that fails without telling anyone.The corrected design and a list of changes
Retries and repeat runsThey explain the default retry policy, then redesign a write so that a retry or a resubmitted run cannot create a duplicate record.The redesigned step and its test cases
Connectors and limitsThey find which connector or platform limit a failed run hit and propose how the flow can stay under it.Notes in the recovery plan
Ownership and connectionsThey review a sample flow inventory and find flows that depend on one person's account. For each flow, they choose a fix: change the owner in place, add the flow to a solution first, or export and import it as a new flow. They also list the connections to replace.A flow-by-flow plan for owners and connections
ApprovalsThey design an approval with a reminder, an escalation path and a rule for requests that wait too long.A one-page approval design
Releasing the fixThey plan how the fix reaches production. The plan covers events missed while the flow was off, approvals already waiting and who approves the release.The release steps in the recovery plan
MonitoringThey propose failure alerts, a daily check that a named person can run, and Application Insights where the environment is a managed environment.The monitoring part of the plan

The recovery plan carries the most weight. It shows how the candidate reasons, sets priorities and writes for people who were not part of the diagnosis. You receive a short written summary of the result before your interview. How we assess specialists explains who reviews the work and what an assessment cannot show.

Example first work package: stabilize one approval flow

How you can engage Power Automate capacity

This page describes one developer who joins your team. The table lists how MS Dynamics Guys can add flow capacity and who directs the work.

Ways to add Power Automate capacity and who directs the work
OptionWho directs the workSuitsModel
One developer in your teamYour lead, through your backlog and release processA steady flow backlog and a lead who can review the workStaff augmentation

Allocation, overlap hours, minimum term, notice and replacement are agreed in writing for each engagement. Rates are quoted after the role is defined. In every model, an account or service principal that your organization controls owns each production flow. For a side-by-side view of responsibility and delivery risk, read staff augmentation versus project delivery.

How a Power Automate developer starts

  1. Role brief

    You describe the flows and connectors, what fails today, who owns the flows, the hours to cover and whether desktop flows are in scope.

  2. Fit review

    We read which flows and connectors your brief names. We also check whether your environments have Dataverse, because solutions need it. Then we confirm whether we can staff the role, including any desktop flows.

  3. Assessed candidates

    Each candidate completes the failing-flow task before you see a profile. The profile comes with a short written summary of the result.

  4. Your interview

    You interview each candidate and decide who joins. A real failed run from your environment, with sensitive data removed, makes a strong interview task.

  5. Written agreement

    Scope, allocation, overlap hours, ownership of the work and replacement terms are signed before the start. Your team also names who will own the production flows and who receives failure alerts.

  6. Access

    Your administrator creates a named account with maker access in a development environment. Production access follows only where the work needs it.

  7. First reviewed task

    One real flow problem from your backlog, fixed in development, reviewed by your lead and accepted before release.

What you can check before you rely on a developer

MS Dynamics Guys has no client case studies approved for publication yet, so this page shows no client names, results or reviews. We do not replace them with invented examples.

The steps above give you three checks on the person: the written assessment summary, your own interview and the first reviewed task. The outline below lets you check the method. It is an original demonstration written for this page, not taken from client work. It shows the parts we expect in a candidate's recovery plan.

Demonstration: outline of a recovery plan for a failing flow
Part of the planWhat it answers
ImpactWhich runs failed and since when, which records or approvals are affected, and who needs to know
CauseThe failing step, the error from run history and the evidence for the cause. Run history is kept for a limited time, so the plan copies what it needs.
Immediate fixThe smallest change that stops new failures, and how it is tested before release
Missed and repeated workWhich failed runs to resubmit, which records to correct by hand, and how to avoid processing a record twice
PreventionChanges to ownership, connection references, error handling, alerts or limits that stop the problem from returning
Sign-offWho approves the fix, who runs the recovery and who confirms that the data is correct

How we assess specialists describes the full assessment, who reviews it and its limits.

Questions about hiring Power Automate developers

Can the developer fix flows that still run under a former employee's account?

Usually, yes. Inside a solution, an owner, co-owner or administrator assigns a new owner in place. Outside a solution, a co-owner first adds the flow to a solution, or exports it and imports it as a new flow. If no owner remains, your administrator can add a co-owner in the Power Platform admin center. The developer then replaces the former employee's connections.

Whose account should own our production flows?

An account or identity that your organization controls, not the developer's own account. Microsoft recommends a service principal as the flow owner rather than a shared service account. Shared credentials are a security risk, and they make it hard to see who changed a flow. Your administrator sets up the service principal as an application user in the environment. The choice of owner affects licensing, so confirm it with your administrator.

Who handles failed runs outside the developer's working hours?

Your team does. Flows can run at any hour, but the developer works only the hours agreed in writing for each engagement. So each failure alert goes to a named person on your side as well as to the developer. The runbook tells that person which failed runs can wait, and how to turn off the flow or resubmit a run. The developer finds and fixes the cause during the agreed hours. Tell us your time zone and which flows are time-critical when you describe the role.

Do we keep the flows as files, and do the files carry our connections?

Yes, where your environments have Dataverse. The developer builds the flows inside your solutions. With each release, the developer adds the editable, unmanaged version of each solution to your source control repository. The files carry connection references, not the connections themselves. Each environment gets its own connections at import, from accounts your organization controls. Ownership of the work and its intellectual property is set in the written agreement before the start.

Do premium connectors or a service principal owner change what we pay?

They change your Microsoft license costs, not the developer's rate. You buy licenses through Microsoft's channels. Who needs a license depends on how a flow starts and who owns it:

  • If an automated or scheduled flow uses premium connectors, only its owner needs a license that includes them, such as Power Automate Premium.
  • If a manually triggered flow uses them, each person who runs it needs Power Automate Premium.
  • A Process license can cover one flow in a solution instead, or up to 25 such flows in a flow group.
  • A premium flow owned by a service principal needs a Process license, directly or through a flow group. A designated licensed user can cover it instead, and the flow then uses that person's license.
  • Qualifying Microsoft Dynamics 365 licenses include Power Automate rights only in the context of the licensed Microsoft Dynamics 365 app. A service principal flow used only in that context does not need a Process license.

The developer's rate is agreed in writing for each engagement and quoted after the role is defined. It depends on seniority, allocation, duration and the hours you need covered.

Describe the automation work you need covered

Tell us which flows and connectors are involved, what fails today, who owns the flows now and the hours you need covered. We confirm whether we can staff the role before any introduction.

Discuss automation capacityDiscuss a flow project instead

Product documentation referenced on this page