Power Platform Consulting and Development Services

What does a Power Platform developer do?

A Power Platform developer designs, builds, and maintains business applications on Microsoft Power Platform. The job has four parts in practice. Power Apps: canvas apps for task focused and mobile scenarios, model-driven apps for data heavy processes on Dataverse, and the forms, views, business process flows, and Power Fx logic inside them. Power Automate: cloud flows for approvals, notifications, scheduled jobs, and data synchronization between systems, plus desktop flows that drive applications with no API. Dataverse: the data model everything else stands on, meaning tables and relationships, business rules, security roles and column level security, server side logic in C# plugins and custom API, and an environment strategy across development, test, and production. Pro code extension: PCF controls in TypeScript and React when the standard controls cannot express the interface users need, custom connectors, and integration through the Dataverse Web API.

The value the role delivers is straightforward to state. Work that used to move by email and spreadsheet gets a system that records it, routes it, and reports on it. Processes that used to depend on somebody remembering to act get a flow with retries, error handling, and an owner who is told when it fails. Dynamics 365 gets extended to fit how your business actually sells and serves, instead of your business bending to fit the product. And the people who do the work get an app built for their job rather than a screen inherited from someone else.

What you buy from an experienced developer is mostly the decisions, not the clicks. Anyone can add a table and drop controls onto a screen. The difference shows six months later: whether the data model still holds when a second department joins, whether flows fail loudly into a monitored error path or quietly at three in the morning, whether solutions move between environments through managed pipelines or by hand, and whether the licence design still fits the user count you now have. Solzet staffs projects with senior developers who have made those calls before. Engaging us is the practical equivalent of hiring an experienced Power Platform developer into your own team, without the recruitment, the payroll, or the wait, and without the risk of a junior learning the platform on your project.

What is the difference between a Power Apps developer and a Power Platform developer?

The two titles often describe the same person, and on a small team they usually do. The distinction worth making is scope. A Power Apps developer is hired for the application layer: canvas and model-driven apps, screens, forms, views, Power Fx logic, connectors to SharePoint, SQL, or an API, and the experience of the tool people open every morning. A Power Platform developer covers that plus everything around it: the Dataverse data model and security model, Power Automate cloud flows and desktop RPA, Power Pages portals for external users, Copilot Studio agents, application lifecycle management with solutions and pipelines, and pro code extension through C# plugins and TypeScript PCF controls.

Which one you need follows from the work. A single departmental app over SharePoint data is a Power Apps developer job and should be priced like one. An app that shares a data model with Dynamics 365 Customer Engagement, enforces record level security, integrates with an ERP, and has to survive two Microsoft release waves a year needs the wider skill set. Solzet developers work across both, so the scope can move without changing the person doing the work. If what you actually need is custom UI inside Dynamics 365 rather than a new app, our PCF controls development service is the narrower form of the same team.

How do you hire a Power Platform developer from Solzet?

Three shapes cover most requests. A dedicated developer: one of our people works with your team for an agreed number of days per month, joins your standups, and works inside your Azure DevOps, GitHub, or Jira rather than asking you to adopt ours. A fixed scope project: we specify, build, test, and hand over a defined app, flow set, or portal against dated milestones. Managed support: a monthly allocation for change requests, release wave updates, and fixes on an environment that already exists, including environments originally built by another partner.

Starting is deliberately light. Send us the problem rather than a specification, if a specification is the thing you do not have yet. We reply within one business day, run a short scoping call, and come back with a proposal within five business days naming the scope, the engagement model, and the people who would do the work. We contract B2B, sign NDAs and GDPR compliant data processing agreements, and define IP ownership in the statement of work, so the solutions and the source belong to you. We do not publish a day rate, because the honest number depends on scope and duration, but Armenian rates sit below Western European consultancy rates for the same certified senior people, and there is no recruitment fee, payroll, or notice period attached to the arrangement. Yerevan is GMT+4, which leaves 4 to 6 hours of daily overlap with Western European hours and 6 to 8 with the UK, so a dedicated developer shares your working day instead of handing work over overnight. For Microsoft partners we also work white label, under your brand and your email, as part of your delivery team.

What Power Platform services does Solzet offer?

Our Power Platform practice covers five core areas. Power Apps: we build both canvas apps (pixel-perfect UI for mobile and tablet scenarios) and model-driven apps (data-rich applications on Dataverse for complex business logic). Power Automate: we design cloud flows for process automation (approvals, notifications, data synchronization between systems) and desktop flows for RPA scenarios where legacy applications lack APIs. Power Pages: we build external-facing portals for customer self-service, partner collaboration, and public data access - connected to Dataverse and secured with Azure AD B2C or local authentication. Copilot Studio: we design and deploy conversational AI bots integrated with your D365 data and business processes. Dataverse: we architect data models, configure security roles, build business rules, and manage environment governance across dev/test/production.

Model-driven apps or canvas apps: which should you build?

Both are Power Apps, both are built in the same maker portal, and the comparison is normally presented as a feature list. In delivery the choice is settled by one question: is this an application about records that several roles work across for years, or a tool for one task done by one role in one place? A model-driven app generates its interface from the Dataverse data model, so you configure tables, forms, views, dashboards and business process flows and the platform renders and secures them. A canvas app gives you an empty screen and Power Fx, so you place every control yourself and connect to whichever data source you like. Everything else below follows from that one difference.

Our default, and it is a default rather than a rule: if the data belongs in Dataverse and more than one role touches the same record, build model-driven and treat a canvas app as the exception you have to justify. The reason is commercial rather than aesthetic. Every form, view, chart and search box the platform generates is one you never build, never test and never repair after a release wave, and the security model is enforced by the platform instead of being reimplemented in formulas. A canvas app earns its place when the screen itself is the value: a phone or tablet held by somebody standing up, offline capture, a camera, a barcode scanner, or a guided task for people who will never open a CRM.

The two expensive mistakes are mirror images of each other. The first is a canvas app over Dataverse that slowly turns into a CRM: several hundred controls, record level visibility hand rolled in Power Fx, a gallery that quietly stops returning the right rows once the table passes the delegation limit, and a rebuild quoted eighteen months later. The second is a dense model-driven form pushed onto a shop floor tablet, where somebody wearing gloves is asked to work a record page designed for a desk and a mouse. Both are avoidable at design time and both are expensive once users have already stopped trusting the app. If you are living with the first one now, fixing a slow canvas app gallery over Dataverse covers the performance half of that story.

• A structured CRM extension is model-driven, every time. Sales and service teams working shared accounts, cases and opportunities, with role based visibility, an approval path and reporting over the same tables. This is the bulk of our Dynamics 365 development work, and it is exactly the case where a canvas app means rebuilding by hand what Dataverse already enforces for free.
• A shop floor inspection or downtime app is canvas, every time. A tablet at the machine, validation at the point of entry, barcode scanning, photo capture and offline sync into Dataverse, designed for the operator rather than for the person who will read the report. The full pattern, including why offline decides whether the pilot survives, is in how Power Apps replaces paper forms on the shop floor.
• A first app for a mid-market team replacing a shared spreadsheet is canvas over SharePoint, and deliberately small. It runs on licensing the tenant almost certainly already holds and it produces a visible win in weeks, which is how a platform gets adopted rather than merely approved. That starting strategy is set out in Power Platform: the most underused tool in mid-market companies.
• Field work with a back office behind it is both. Dispatchers, planners and managers work the model-driven app; engineers work a canvas app on a phone against the same Dataverse tables. One data model, two interfaces, nothing to integrate, and the licensing sized once for both populations instead of twice.

START: where does the data live, or where should it live?
  |
  |-- Not Dataverse, and it should not be: a SharePoint list,
  |   Excel, or a SQL database or API you do not own.
  |        -> CANVAS APP. A model-driven app cannot run on it.
  |
  '-- Dataverse, or it belongs in Dataverse.
           |
           v
     Do several roles work the same records over time, with
     different visibility, a process to follow and reporting?
           |
           |-- YES -> MODEL-DRIVEN APP.
           |            |
           |            v
           |     Is one step of that process phone shaped,
           |     offline, or camera and scanner driven?
           |            |
           |            |-- NO  -> Model-driven app, done.
           |            |
           |            '-- YES -> MODEL-DRIVEN APP plus a custom
           |                       page, or an embedded canvas
           |                       app, for that one step only.
           |
           '-- NO, it is one task for one role.
                        |
                        v
                 Is the screen itself the value: a phone in
                 the hand, offline, scanning, a guided flow?
                        |
                        |-- YES -> CANVAS APP on Dataverse, with
                        |          delegation designed in from
                        |          day one rather than fixed later.
                        |
                        '-- NO  -> MODEL-DRIVEN APP anyway. A
                                   generated interface you never
                                   maintain beats a drawn one
                                   you do.

At any leaf, one override: if the blocker is a single interaction
the platform cannot render rather than the whole application, the
answer is neither app type. It is a code component inside the app
you already have.

What does Power Pages (Portals) development involve?

Power Pages, the product formerly called Dynamics 365 Portals, is how external people read and write your business data without holding a full licence, and building one is a different discipline from building an internal app. Solzet delivers Power Pages portals end to end: discovery and information architecture, UX design and custom styling against your brand, the Dataverse tables, table permissions and web roles that decide who can see which record, the forms, lists and Liquid templates people actually work in, authentication through Microsoft Entra External ID (formerly Azure AD B2C), local accounts or an identity provider you already run, and the integrations that connect the portal to the systems behind it. We build for three audiences: customers (self service, case logging, application and order status, document upload), partners (deal registration, claims, shared pipeline and co-selling), and employees (onboarding, internal requests, field data capture for people who never open the CRM).

Where the product runs out we write code rather than trim the requirement: PCF controls in TypeScript and React embedded in portal forms, custom Liquid and Web API calls for pages the standard components cannot express, custom connectors, and Power Automate behind the submit button for routing, approvals and notifications. We also treat a portal as a production system rather than a website. That means managed solution ALM so a change reaches production through a pipeline instead of by hand, query and page tuning with caching so response times hold when a renewal deadline puts every user on the site in the same hour, monitoring and alerting on the flows behind the forms, and a security review of every table permission before go live, with audit trails, consent capture and data residency handled for regulated sectors such as financial services, healthcare and the public sector.

A portal almost always sits on the same Dataverse as a CRM, so we keep the portal and the CRM in one team: the same senior people who build the site also do the Dynamics 365 development work behind it, instead of the boundary between two suppliers becoming your problem at integration time.

• UX design and information architecture: user journeys for each audience, wireframes, navigation and page structure, and accessible markup that works on the phone a field user actually holds.
• Custom styling and front end build: your brand applied properly through Bootstrap themes, custom CSS and web templates, responsive layouts, WCAG oriented accessibility, and multilingual sites where the audience needs more than one language.
• Dataverse integration: the data model, table permissions, web roles and column level security that decide who sees what, plus virtual tables and integrations to bring in data the portal does not own.
• Authentication and identity: Microsoft Entra External ID, local accounts, and federated sign in through an existing identity provider, with invitation and self registration flows and multi factor authentication where the sector requires it.
• Pro code extension: PCF controls in TypeScript and React, Liquid and Web API for what the standard components cannot render, custom connectors, and Power Automate for the process behind every submitted form.
• High traffic and regulated industry management: capacity planning and load testing before go live, caching and page performance tuning, monitoring and alerting, audit trails and consent capture, data residency, and a documented security review of every permission rule.
• Life after go live: managed solution ALM across development, test and production, release wave regression testing twice a year, analytics on what visitors actually use, and a monthly support allocation for changes.

When should you use Power Apps instead of custom development?

Power Apps is the right choice when you need a business application built in weeks rather than months, when the primary data store is Dataverse or SharePoint, when citizen developers should be able to maintain the app after deployment, and when the application does not require sub-millisecond performance or complex real-time processing. Common use cases include inspection and audit apps, expense approval workflows, inventory tracking, employee onboarding portals, and field data collection. For scenarios requiring custom UI components beyond what standard controls offer, we build PCF (PowerApps Component Framework) controls in TypeScript and React - giving you the best of both worlds: low-code architecture with pro-code UI precision.

Custom development is the better call in the opposite cases, and because we deliver both we will tell you which side of the line you are on. When the application is really a CRM that has to run without per-user Microsoft licensing, when you need full ownership of the code, the hosting and the data model, or when the organization does not run on Microsoft 365 at all, we build it as a custom CRM on React, Node.js, PostgreSQL, or .NET rather than forcing it onto Power Apps.

How does Solzet handle Power Automate RPA for legacy systems?

Many organizations run critical processes on legacy applications - desktop ERP systems, mainframe green-screen terminals, or Windows-only tools with no API. Power Automate desktop flows let us automate these by recording and scripting UI interactions: clicking buttons, filling forms, extracting data from screens, and passing it to cloud flows for further processing. Solzet designs RPA solutions with resilience in mind - we build error handling, retry logic, and monitoring dashboards so you know when a flow fails and why. We also evaluate whether RPA is the right long-term answer or a bridge while you modernize the underlying system, and advise accordingly.