Search for “Power Platform developer” on Adzuna, Jooble or Arbeitnow and you’ll see the same few job titles repeated: Power Platform Developer, Dynamics 365 / Power Platform Developer, and most often Lead Power Platform Developer. Many organisations are hiring for this role. Many of them are also writing a job description before they’ve worked out what they need.
We build and support Dynamics 365, Business Central and Power Platform solutions. We often get pulled into projects after a hire didn’t work out, or after a well-meaning citizen developer built something the business now depends on. This article covers what the role involves, what “Lead” should mean, and how to judge whether you need a permanent hire, a contractor or a partner.
What “Power Platform developer” covers
The title covers a wide range of skills. At one end is someone who builds canvas apps and Power Automate flows against SharePoint lists. At the other is someone who writes C# plug-ins, builds PCF controls, designs Dataverse data models and runs deployments through pipelines. Both people are “Power Platform developers,” and they are not interchangeable.
A realistic breakdown of the skill areas:
- Low-code build: canvas and model-driven Power Apps, Power Automate cloud flows, Power Pages, Copilot Studio agents.
- Data: Dataverse table design, relationships, security roles, business units, column-level security. This is where most long-term problems start if it’s done badly.
- Pro-code extension: C# plug-ins, custom workflow activities, PCF components, custom connectors, Azure Functions, and JavaScript on model-driven forms.
- Integration: connectors to Dynamics 365, Business Central, SQL, line-of-business APIs, plus an understanding of throttling, API limits and error handling.
- ALM and governance: solutions (managed vs. unmanaged), environment strategy, Power Platform Pipelines or Azure DevOps/GitHub, environment variables, connection references, DLP policies.
- Reporting: Power BI, often expected even when it isn’t in the title.
Few people are strong in all of these. A useful job description says which ones matter most for your work.
What “Lead” should mean
So many listings ask for a Lead Power Platform developer because organisations usually discover the need for one after the fact. Someone builds a few apps. Those apps become critical. Then nobody can say which environment holds the real version, who owns the connections, or why a flow failed at 2 a.m.
A lead developer is mostly there to stop that from happening again. In practice, the role should include:
- Setting the environment and ALM strategy: dev/test/prod, how solutions move between them, and who can deploy.
- Owning the data model, so new apps don’t each create their own “Customer” table.
- Reviewing other people’s work, including citizen developers. The point is to stop fragile patterns before they reach production, not to slow people down.
- Making build-vs-buy-vs-extend calls: when to use out-of-the-box Dynamics 365 functionality, when to build, and when to say “this shouldn’t be on the Power Platform at all.”
- Working with IT and security on DLP policies, licensing and tenant settings.
If the job you’re hiring for is “build apps faster,” you probably don’t need a lead. If it’s “make sure the twenty apps we already have don’t fall over,” you do.
Last year a 150-person professional services firm called us in after their expense approvals had stopped for three days. A finance analyst had built the flows in the default environment, using connections under her own account. When she left and IT disabled the account, every flow failed and nobody else had edit rights. We moved the flows into a solution and set up separate dev, test and production environments. We switched to connection references owned by a service account and added a simple Power Platform Pipelines deployment. That took about four weeks. The flows have since got through two more staff changes without anyone noticing.
The Dynamics 365 overlap
The Dynamics 365 / Power Platform Developer title exists because the Dynamics 365 customer engagement apps (Sales, Customer Service, Field Service and so on) are built on Dataverse. Someone extending Dynamics 365 Sales is working on the same platform as someone building a model-driven Power App. Plug-ins, security roles, solution layering and form scripting all carry over.
Business Central is different. It doesn’t run on Dataverse. Extending Business Central means AL development in VS Code. Connecting it to the Power Platform goes through the Business Central connector, APIs, or Dataverse virtual tables and synchronisation. A strong Dataverse developer is not automatically a Business Central developer, and the reverse is also true. If your business runs Business Central and you want Power Apps or Power Automate around it, make sure your candidate has done that specific integration. Understanding how the two models fit together matters more than knowing either one alone.
For a 60-person Irish building supplies wholesaler on Business Central online, we built a canvas app that lets yard staff record goods received against purchase orders on a tablet. We used the Business Central connector against the standard API pages. We also wrote one custom API page in AL to expose a bin code field the standard APIs didn’t include. We looked at Dataverse virtual tables, but the client had no other use for Dataverse, so it would have added cost without much benefit. The build took about five weeks. Most of that went on testing permissions and partial receipts.
Hire, contract, or partner
There’s no universally right answer, but the trade-offs are fairly predictable.
A permanent hire makes sense when you have a steady stream of work for years, not months, and you want the knowledge to stay in-house. The risk is hiring one person and expecting them to cover architecture, pro-code, low-code, Power BI and governance alone. If that person leaves, so does most of what you know about your own systems.
A contractor works well for a defined piece of work with a clear end, or to add capacity alongside an existing team. The risk is that solutions get built to the contractor’s habits, documentation is thin, and the handover is a single meeting.
A partner is useful when you need several skills for a period of time, such as a lead-level reviewer, a pro-code developer for a plug-in and someone who knows Business Central integration. It also helps when you want a second opinion before committing to a design. The risk is dependency. A good partner should be working to make you less dependent on them over time, not more.
Many organisations end up with a mix. They hire one or two internal developers, and a partner sets up the foundations (environments, ALM, data model, governance) and stays available for the harder pieces.
A practical checklist before you hire (or engage anyone)
Use this before you write the job ad, and again when you interview.
Before writing the role
– [ ] List the apps, flows and reports you already have, who built them, and which environment they live in.
– [ ] Decide whether you need mainly low-code build, pro-code extension, governance/ALM, or a mix, and rank them.
– [ ] Note which Dynamics 365 apps or Business Central you run, and what needs to integrate with what.
– [ ] Check your licensing position (per-app, per-user, premium connectors, Dataverse capacity). Developers make design choices that affect licence costs.
– [ ] Decide who the developer reports to and who signs off production deployments.
When assessing candidates or partners
– [ ] Ask them to describe their environment strategy and how a change gets from dev to production. Vague answers are a warning sign.
– [ ] Ask when they’d use a plug-in instead of a Power Automate flow, and why.
– [ ] Ask how they handle connection references and environment variables across environments.
– [ ] Ask about a time they told a stakeholder something shouldn’t be built on the Power Platform.
– [ ] If Business Central is involved, ask specifically how they’ve connected it to Dataverse or Power Apps, and what went wrong.
– [ ] For lead roles, ask how they’d bring existing citizen-developer apps under control without stopping people from building.
– [ ] Ask what documentation they leave behind, and ask to see an example if possible.
After they start
– [ ] Agree on an environment and ALM setup in the first few weeks, before new builds begin.
– [ ] Put DLP policies in place, or review the ones you have.
– [ ] Set up a simple register of apps, flows, owners and business criticality.
Where we fit
We work with organisations at both ends of this. Some have a developer in place and want a lead-level review of their environments and ALM. Others want us to set up the foundations so their first hire walks into something sensible. Some just need a pro-code piece, such as a plug-in, PCF control or Business Central integration, built properly and handed over with documentation.
We usually start with a short review of two to three weeks covering environments, solutions, connections and DLP policies, and we write up what we would change in order of priority. From there, some clients have us set up the foundations over a few weeks, and others keep us on a small monthly support arrangement for the harder pieces.
If you’re writing a job description for a Power Platform developer, or you’ve already hired one and aren’t sure the setup is right, we’re happy to talk it through. There’s no obligation and no pitch deck. Get in touch at vizorsol.com.