PCF Controls: Buy, Build, or Customize? A Decision Guide
How to choose between a ready made Power Apps Component Framework component, an in house build, and a tailored control from a specialist PCF development company.
Need a custom UI in Dynamics 365 or Power Apps? Power Apps Component Framework (PCF) controls give you almost complete freedom over how a field, a grid, or a whole section behaves, and they carry development cost and long term maintenance risk with them. This guide is the decision rather than the pitch: when to buy a ready made component from AppSource or a community gallery, when to build one in house from scratch, and when to hire a specialist PCF development company such as Solzet for a tailored control. Worked examples follow for five requests we get often: schedulers, map pickers, large dataset viewers, Gantt timeline views, and interactive scheduling grids.
Should you buy, build or customize a PCF control?
Buy when the behaviour is generic, the lifespan is short or uncertain, the user count is small, and approximately right is good enough. Tags, colour coded choices, formatted fields, basic charts.
Build in house when you already have an engineer who has shipped a managed PCF solution before, and the control is small, internal, and cheap to be wrong about.
Commission a tailored control when it has to know your process, sits on a form the business runs on, has to survive years of release waves, or when the cost of a misunderstanding should sit with the supplier rather than with you.
Check first whether you need a control at all. Business rules, the modern Power Apps grid, first party map controls, the Field Service schedule board, and an embedded canvas app between them answer a large share of what arrives described as a PCF requirement.
Which five questions decide the route?
Work through these in order. Most of the value is in the first one, and most of the cost is in the fourth.
1
Does the platform already do this?
Ask this before anything else, because the cheapest control is the one you never commission. Model-driven apps ship an editable grid and the modern Power Apps grid with in line filtering. Power Apps has first party map controls backed by Azure Maps. Dynamics 365 Field Service has a schedule board. Business rules, form scripting, a well designed view, or an embedded canvas app cover a surprising amount of what arrives on our desk described as a PCF requirement. If a supported first party feature gets you to eighty percent, take the eighty percent.
2
How specific is the behaviour to your business?
A control that renders a tag, a colour coded choice, or a formatted number is generic, and generic is exactly what the galleries are full of. A control that enforces your booking rules, your pricing logic, or your approval sequence is not generic, and no ready made component will get closer than approximately right. The more of your own process the control has to know, the further you move from buying and towards building or commissioning.
3
How long does this have to live?
A control for a campaign, a pilot, or an internal tool that will be redone next year has a very different economic answer from a control that sits on the main case form for the next five years. Ready made components are cheap to start and cost the same every year forever. A commissioned control costs more once and then costs whatever maintenance you choose to buy. Somewhere between year two and year four those two lines usually cross, and where they cross depends on your user count.
4
Who owns it in year two?
The Power Platform ships release waves twice a year, and a control also carries its own dependencies on React and a component library that move on their own schedule. Nothing dramatic happens on release day. The control quietly falls behind until a change request or a browser update exposes it. Whether a named person or supplier owns that control eighteen months from now is a procurement decision made at the start, not a technicality discovered later.
5
What is the blast radius if it is wrong?
A control on a form five people use in an internal process is cheap to get wrong and cheap to redo. A control that every seller or every service agent touches on every record, or one that writes to data your invoicing depends on, is not. High blast radius pushes you towards a route where somebody other than you carries the risk of a misunderstanding, which in practice means a fixed price against an approved specification.
How do the three routes compare side by side?
The rows that decide this are rarely the ones on the quote. Cost every route across all three columns before comparing any two of them on price alone.
Factor
Buy ready made
Build in house
Commission tailored
Time to a working version
Fastest by a wide margin. Import the solution, configure it on the form, and you are looking at it the same day.
Slowest in practice, because the clock starts when somebody on your team has learned the framework, not when they start typing.
In between. A scoping conversation and a written specification come first, then a build measured in days to a few weeks depending on complexity.
What you pay up front
Little or nothing. Community gallery controls are usually free and open source, and AppSource apps normally start with a trial.
Your own engineering time, which is real money even when it does not appear on an invoice, plus the learning curve if this is the first control.
The largest single up front number of the three, and the only one of the three that is knowable before work starts.
What you pay every year
A per user or per tenant subscription in most commercial cases, which grows as your user count grows and never stops.
Nothing to a vendor, and whatever internal capacity you keep aside for release waves and change requests, which teams routinely forget to budget.
Whatever support you choose to buy, from nothing at all to a maintenance arrangement. The control itself is already yours.
Fit to your process
As close as the vendor decided to make it. Configuration options are generous in good components and are still someone else idea of what should be configurable.
Exact, because you decide every behaviour. This is the whole point of the route.
Exact, provided the specification was written properly. The specification is the deliverable that determines whether this is true.
Configurability without a developer
Usually strong. Ready made components have to serve many customers, so they expose a lot of configuration.
Whatever your team built. First controls tend to hard code the things that later need to change.
A scoping decision. Deciding which behaviours a maker changes without calling a developer is part of designing the manifest properties.
Who owns the code and the IP
The vendor. You have a licence to use it, and open source community controls come with a licence you should read before you fork.
You do, completely.
You do, when the contract says so. Solzet assigns IP in the statement of work and delivers source alongside the managed solution.
Where your data goes
Worth checking. Some components stay entirely inside your tenant. Others call a vendor service, a geocoding API, or a licence server, which is a data protection question and not just a technical one.
Wherever you send it, and you know exactly where that is.
Same as building. We work inside your tenant, and any external service a control depends on is named in the specification before it is built.
Release wave risk
The vendor problem, as long as the vendor still exists and still maintains the component. Abandoned gallery controls are a real category.
Yours. Somebody has to test against the next release wave and keep the dependencies current.
Yours to own, and a normal thing to hand back to the people who wrote it under a support arrangement.
Who fixes it the morning it breaks
Vendor support, at vendor speed, on vendor priorities. For a free community control, nobody in particular.
Your own team, if the person who wrote it is still there and still remembers it.
The engineers who built it, which is the main reason to keep a maintenance arrangement rather than take the control and walk away.
Best fit
Generic behaviour, a short or uncertain lifespan, a small user count, and a low blast radius if it is not quite right.
Teams with an existing Power Platform engineer who already ships solutions, and controls that are small, internal, and cheap to be wrong about.
Business critical controls, several controls at once, anything that has to survive years of release waves, and anywhere the cost of a misunderstanding should sit with the supplier.
If the choice you are actually making is between an individual developer and a firm rather than between buying and building, that comparison is covered separately in our guide to hiring PCF developers against freelancers.
What does each route cost that nobody puts on the quote?
Every route has a list like this, including ours. A guide that only makes two of the three uncomfortable is an advertisement.
Buying a ready made component
The subscription is per user in most commercial components, so the price you evaluated at twenty users is not the price you pay at two hundred.
Configuration ends where the vendor decided it ends. The last ten percent of fit is the part your users complain about, and no amount of budget buys it.
A free community control on a gallery is a gift, not a contract. Check the last commit date and the licence before it becomes load bearing, because there is no obligation on anyone to update it for the next release wave.
Some components call out to a vendor service, which means your data leaves your tenant. That is a question for whoever signs your data protection agreements, not for the maker who installed it.
Removing a component later is not free either. Once a field or a grid has been rendered by it for two years, the form, the training, and sometimes the data model have shaped themselves around it.
Building it in house
PCF sits at an unusual intersection. TypeScript and React on one side, Dataverse and solution application lifecycle management on the other. Strong React developers frequently have never packaged a managed solution, and experienced Dynamics consultants frequently have never written a component with a real render lifecycle.
The lifecycle is where first controls go wrong. Work that belongs in init gets repeated on every updateView, and state that should be released in destroy leaks every time a user moves between records. Both look fine in a demo.
A dataset control receives a page of records, not the whole view. Ignoring that produces a control that is perfect against twenty test rows and unusable against a real view.
The build has to be reproducible on a machine other than the one it was written on, or you own a person rather than a deliverable.
The genuine hidden cost is bus factor. One engineer learns your data model, your form, and your users, writes none of it down, and then changes team.
Commissioning a tailored control
It is the slowest of the three to start, because a specification comes before a price and writing one properly takes your time as well as ours.
It is the largest up front number. If the control is generic and short lived, this route is simply the wrong answer and we will say so on the call.
A bad specification produces an expensive control that is exactly wrong. The behaviour has to be described in the language of your users, with the volumes and the edge cases in it, or the change requests start on delivery day.
You still own the control afterwards. Commissioning transfers the build, not the twenty year maintenance question, unless you buy support as well.
If your requirement is generic, a specialist firm is the most expensive way to get something that already exists for free. The first job of a decent supplier is to check that before quoting.
What would we actually advise on five real requests?
These are five PCF requirements we are asked about often, and the answer is different for each one. Most of them usually end in buying, configuring or extending something that already exists, and the two with a report deadline attached start with data rather than a control.
A scheduler or booking board
Check this first
Check what you already own first. If this is field service dispatch, Dynamics 365 Field Service ships a schedule board with resource scheduling, and rebuilding that in a control is an expensive way to arrive at a worse version of it.
What buying looks like
AppSource carries calendar and scheduling components, and for drag and drop over a single booking table with standard working hours they are usually good and quick. Priced per user in most cases.
What building actually involves
This is the request teams most often underestimate, and it is rarely the calendar rendering that costs the money. Recurrence, overlapping and conflicting bookings, resource working hours and exceptions, time zones per resource rather than per viewer, keyboard accessible drag and resize, and what happens when two dispatchers move the same booking at once. On top of that, the mature JavaScript scheduler libraries are commercial products with their own developer licences, so a component licence belongs in the budget before anyone estimates the build.
Our verdict
Buy or commission. Building a real scheduler in house from scratch is where we most often see a Power Platform team lose a quarter, and it is the example where the gap between a convincing demo and a production board is widest.
A map picker or location viewer
Check this first
Power Apps has first party map controls backed by Azure Maps, which need the geospatial features switched on for the environment and an Azure Maps key. Confirm those are not sufficient before commissioning anything.
What buying looks like
Map rendering is a solved problem, and there are good free options. Our own Solzet Map View control renders the records of any model-driven view or subgrid as markers on an interactive Leaflet map driven by latitude and longitude columns, and it is on our controls page alongside the free ones.
What building actually involves
The map is not the cost. Geocoding is. Turning addresses into coordinates is a paid API call for any provider worth using, it belongs cached in Dataverse columns rather than issued on every render, and somebody has to decide what happens to a record whose address does not resolve. There is a data protection question underneath it too, because sending customer addresses to a third party tile or geocoding provider is a decision for whoever owns your data agreements.
Our verdict
Buy or extend, in almost every case. The parts of a map requirement that are genuinely specific to you are the geocoding strategy, the marker clustering at your data volume, and what a click on a marker does next, and those are usually a small extension to an existing control rather than a new one.
A large dataset viewer or custom grid
Check this first
Model-driven apps ship an editable grid and the modern Power Apps grid with in line column filtering. If your requirement is mostly about editing in place or filtering faster, try those before commissioning a control.
What buying looks like
Generic grid components exist and are competent at generic grid things. They start to fall short exactly where your requirement stops being generic: conditional formatting driven by your own rules, columns computed from related records, or bulk actions specific to your process.
What building actually involves
This is where the framework itself sets the difficulty. A dataset control is handed a page of records, not the view. Rendering everything means paging through the dataset API, respecting Dataverse service protection limits, and not holding the whole result set in browser memory. Sorting and filtering belong pushed back to the dataset rather than performed in memory over a page you happen to hold, and rows need virtualising so scrolling stays smooth. None of that work is visible in a demo against twenty records, which is precisely why it gets left out of estimates.
Our verdict
Commission, or build only if you already have an engineer who has shipped a paged dataset control before. This is the example where a specialist earns the difference most clearly, because the entire gap between a demo and production sits in paging and virtualisation work that a demo will never reveal.
A Gantt chart or project timeline view
Check this first
Separate what people want to see from what they want to change. A timeline that shows projects, phases or work orders against dates is a reporting requirement. A timeline where a planner drags a bar to move a date is an editing requirement with conflict rules behind it. Also check whether the projects are already planned in a Microsoft project tool that has its own timeline view, and whether the output has to be exported as evidence for an audit or compliance report, because that one requirement changes the answer.
What buying looks like
There are two quick routes. A Gantt visual from AppSource inside a Power BI report over Dataverse, or a Gantt app or component from AppSource on the form itself. The Power BI route is read only, handles large volumes well because the data model does the work, and gives you export and printable pages for an audit pack, subject to your tenant export settings. An AppSource component can add drag to reschedule, usually priced per user, and its limits on rows, dependencies and time zones need testing against your real data before you commit.
What building actually involves
An embedded canvas app can show a simple timeline and edit dates through a form, and a maker can change it without a deployment, but canvas apps have no native drag on a timeline and hit delegation limits at volume. A purpose built PCF control gives true drag to reschedule, dependencies, paging over large datasets and behaviour that follows your rules, and it is the slowest route: a specification, a commercial Gantt library licence in most cases, keyboard alternatives to dragging, and testing against release waves. The drag interaction patterns we use are the same ones in our Kanban PCF control build guide.
The routes side by side
Route
Time to a working version
What it gives up
Best when
Gantt visual in Power BI over Dataverse
Days, if the dates and relationships are already clean in Dataverse.
Editing. Nobody reschedules from a report, and refresh timing decides how current it is.
The need is visibility or an exportable audit or compliance report.
AppSource Gantt component or app
Days to a couple of weeks, including a proper trial on real data.
Fit and cost control. Per user pricing, vendor limits on volume and rules, and a data protection check if it calls a vendor service.
Drag to reschedule is needed on a standard shape of data and the user count is modest.
Embedded canvas app
One to a few weeks for a maker who knows the data.
Smooth drag interaction and performance at volume, because of delegation limits.
Moderate volumes, simple date edits through a form, and a team that wants to change it without developers.
Purpose built PCF control
The longest: specification, build, library licensing, accessibility and release testing.
Speed to first version, and you own maintenance through every release wave.
High volume, real drag to reschedule with your own conflict rules, and a view the business will use for years.
If a report deadline is weeks away
If an audit or compliance report is due in a few weeks, build the Power BI Gantt over Dataverse first. It is the fastest route, it exports, and it forces the data clean up the report needs anyway. A custom control is usually not the fastest route, because it adds a specification, a build, testing and a release before anyone sees a bar on a timeline. Commission the interactive control afterwards, if planners still need to drag.
Our verdict
Report first, control second. For read only timelines and anything with an audit deadline, a Power BI Gantt visual wins. For drag to reschedule at modest volume, trial an AppSource component. Commission a PCF control when volume, your own scheduling rules and a long lifespan all point the same way, and see our PCF controls development service for how that build is scoped.
An interactive scheduling grid, where an Excel paste workaround is corrupting data
Check this first
Stop the corruption before choosing a user interface. When planners copy rows from Excel into an editable grid or an import because entering them one by one is too slow, the damage is predictable: columns shifted by one, dates read in the wrong day and month order, text pasted into lookups and choices, and rows overwritten that nobody meant to touch. Find the affected records, correct them, and add validation in Dataverse itself, such as a synchronous plug-in, so every entry route is checked and not only the form, which is the approach set out in our guide to enforcing rules before an audit.
What buying looks like
Before any grid, give the paste a validated front door. An Excel template import with column mapping and an error log, or a staging table where pasted rows wait until a flow or plug-in validates lookups, dates and duplicates, keeps the speed users want without letting bad rows into the live table. The editable version of the modern Power Apps grid, configured on the view, then covers in place edits for many teams with no code at all.
What building actually involves
If the grid still has to be interactive beyond that, an embedded canvas app can give a tailored entry screen with validation on every row, maintained by a maker, at moderate volumes. A PCF grid earns its cost when users need spreadsheet speed with safety: keyboard driven entry across many rows, a paste handler that validates each cell and shows errors in place before anything is saved, checks against conflicting bookings, and paging over a large dataset. That is real work in paste parsing, locale aware dates and conflict handling, and it only helps once the server side validation exists, because a grid alone never protects the data from the next import.
The routes side by side
Route
Time to a working version
What it gives up
Best when
Validated intake: template import or staging table with checks
Days to a couple of weeks, alongside the data correction.
Some convenience. Users submit a batch and fix rejected rows rather than seeing errors as they type.
Data is already being corrupted and a report or audit depends on it.
Modern editable grid on a view
Days, as configuration.
Custom paste handling and cross row rules in the grid itself.
In place edits of a few columns, with server side validation behind it.
Embedded canvas app entry screen
One to a few weeks.
Spreadsheet speed and performance at high volume.
A tailored screen with row validation that a maker can maintain.
PCF scheduling grid
The longest, and it depends on the validation already existing.
Speed to first version, and you own the paste and conflict logic for years.
High volume keyboard entry with in place validation and booking conflict checks is part of the daily job.
If a report deadline is weeks away
With a report deadline close, the fastest safe route is data correction plus validated intake, not a new grid. It stops the numbers changing under the report within days, while any custom control would still be in specification. Revisit the interactive grid once the report is out.
Our verdict
Validate first, then pick the grid. Server side validation and a validated import or staging route come before any user interface decision. Most teams then need only the modern editable grid or an embedded canvas app. Commission a PCF scheduling grid when high volume, keyboard speed and in place validation are the daily work, not a one off month end.
What if the best option is not to build a control at all?
No supplier volunteers this one, which is exactly why it belongs on a decision guide. A meaningful share of the PCF requests we are asked to quote have a cheaper answer that is not a control.
Business rules and form logic cover conditional visibility, requirement levels, and simple calculations without any code component at all.
A well designed view with the right columns, sorting, and filters answers a lot of what arrives described as "we need a better grid".
An embedded canvas app gives you a custom screen inside a model-driven form, and a maker can change it without a developer or a deployment.
Power BI embedded in a form covers analytical display far better than a hand built chart control, and somebody else maintains the rendering.
Sometimes the honest answer is that the process is wrong rather than the user interface, and a control will make a bad process faster rather than better.
Why is total cost of ownership where the decision actually lands?
Comparing a subscription against a one off build price is comparing two different kinds of number, and it is why so many of these decisions get made on the wrong basis. A per user subscription is a line that keeps rising as your user count rises and never reaches zero. A commissioned control is a larger number once, followed by whatever maintenance you choose to buy. Somewhere between the second and fourth year those two lines usually cross, and exactly where depends on how many people use it.
That is not an argument for building. It is an argument for costing three years rather than one, in both directions. If the control will be replaced inside eighteen months because the process behind it is still moving, the subscription wins easily and the crossover never arrives. If it is going on the main case form for the rest of the decade at two hundred users, the arithmetic points the other way well before anyone has to argue about fit.
The number people leave out on the build side is year two onwards. A control is not finished at go live: release waves land twice a year, dependencies move on their own schedule, and the form it lives on will be redesigned by somebody eventually. Budget an allowance for that, however small, or you have not costed the build, you have costed the first version of it. This is the same discipline we apply on the licensing and renewal side, where the annual line is the one that decides the outcome.
If commissioning is the answer, what should a specialist firm give you?
Solzet is a Dynamics 365 Customer Engagement and Power Platform consultancy in Yerevan, Armenia, and PowerApps Component Framework development is one of our core services, delivered to end clients and white-label to other Microsoft partners. Here is what that looks like in practice, and it doubles as a checklist for evaluating anyone else.
We check the cheaper answers first
The first conversation is about whether you need a control at all, and then about whether one already exists. We publish free controls ourselves, so pointing you at an existing component rather than a quote is not a loss for us. A supplier who never reaches that conclusion is not scoping, they are selling.
A specification before a price
We scope what the control reads and writes, which hosts it must run in, what it does at your data volumes, and which behaviours a maker must be able to change without a developer. The price is fixed once that specification is approved, which puts the cost of a misunderstanding on us rather than into your change request budget.
A specialist stack rather than a general one
TypeScript and React with Fluent UI so controls look native inside a model-driven app, built with the Power Platform CLI. Simpler field controls are written in plain TypeScript where React would only add weight. Within Microsoft we work on Dynamics 365 Customer Engagement and the Power Platform, and outside it we build custom CRM on React, Node.js, PostgreSQL, and .NET, so the React skills behind a control are in daily use.
A deliverable you own
A versioned managed solution ready to import into your Dataverse environment, the source code in a repository you own, a build another developer can reproduce, and documentation covering the manifest properties and what the control assumes about your data. If we vanished tomorrow, another developer could pick it up, which is the only sensible test of whether a handover was real.
Direct or white-label
Microsoft partners commission controls from us under their own brand for their end clients, working under NDA with their tooling and their repositories. Our case studies include a white-label engagement of eight controls for a UK Microsoft Solutions Partner, delivered into the partner Azure DevOps with their review process.
Certified engineers in one time zone
We deliver from a single hub in Yerevan, Armenia, at GMT+4, which overlaps the Western European working day and reaches the US morning. Our engineers hold Microsoft certifications including PL-200, PL-400, and PL-600 for the Power Platform and MB-210, MB-230, and MB-240 for Dynamics 365 Customer Engagement.
If your requirement is generic, commissioning a specialist firm is the most expensive possible way to obtain something that already exists, sometimes for free. A tag input, a colour coded choice, a JSON viewer, a formatted number: those are gallery territory, and several of them are on our own controls page at no cost. If you have a Power Platform engineer in house who has already shipped a managed solution, a small internal control is a good way for them to build the skill and a poor use of our invoice.
If the requirement is still moving, do not commission anything yet. A specification that changes weekly turns a fixed price into a change request argument, and neither side comes out of that well. Install something quickly, watch what real users complain about for a quarter, and let those complaints become the specification.
And if the problem lives in Business Central, Dynamics 365 Finance, or Supply Chain Management, that is outside what we do at all. On the Microsoft side we work in the Customer Engagement apps of Dynamics 365 and the Power Platform, and for organizations where Microsoft licensing is not the right fit we also build custom CRM on React, Node.js, PostgreSQL, and .NET. Where we are the right answer is a control that has to know your business, run against real data volumes, and still be working after several release waves, built by senior engineers who do this work every week.
What do people ask about buying or building PCF controls?
Should I buy a PCF control or build a custom one?
Buy when the behaviour is generic, the lifespan is short or uncertain, the user count is small, and being approximately right is acceptable. Build or commission when the control has to know your process, when it sits on a form your business runs on, or when it has to survive years of Microsoft release waves. The question that decides it is not the price of the component, it is what the control has to know about your business. A component that renders a tag or a colour coded choice knows nothing about you and should be bought. A component that enforces your booking rules or your pricing logic cannot be bought at any price.
What does a custom PCF control cost?
Effort varies far more by complexity than by supplier. A simple field level control such as a formatted display or an input mask is a short engagement. A medium control such as an interactive chart or a filtered lookup with custom UI is larger. A full dataset control such as a custom grid, a scheduler, or a map visualisation is a project in its own right. The larger cost drivers usually sit outside the code: how many hosts it must support, how much configurability the makers need, and how well specified the behaviour was before anyone started. Solzet quotes a fixed price once the specification is approved rather than an open hourly rate, and offers volume pricing to Microsoft partners commissioning several controls.
Are free PCF controls from a community gallery safe to use in production?
Frequently yes, and we publish free controls ourselves. Treat them as you would any other open source dependency rather than as a product. Read the licence before you fork it, look at when it was last updated and whether anyone is still answering issues, and check whether it calls any service outside your tenant. The risk is not that the code is bad, it is that nobody is under any obligation to update it for the next release wave. If a free control becomes load bearing for a business process, the sensible move is to take ownership of a fork deliberately and budget for maintaining it, rather than discovering the dependency the week it breaks.
Can we start with a ready made component and replace it later?
Yes, and for a genuinely uncertain requirement that is often the best sequence. Install something quickly, let real users work with it for a quarter, and use what they complain about as the specification for the tailored version. Two things make the swap cheaper later. Keep the data in your own Dataverse columns rather than in any structure the component owns, and avoid components that require their own tables to hold what should be your data. Where the swap gets expensive is when the form, the training, and sometimes the data model have shaped themselves around the component behaviour over two years.
Can we customise a PCF control we already have instead of rebuilding it?
Often, and it is usually the cheapest route when the base control is close. If it is open source, the licence decides what you may do, and forking means the fork is now yours and upstream fixes stop arriving on their own. If it is a control a previous supplier built for you, the questions are whether you hold the source, whether the build is reproducible outside their machine, and whether the manifest and packaging were done properly. We take over controls built by other suppliers, and the first piece of work is confirming those three things rather than reading the component code.
What should a commissioned PCF control deliverable include?
A managed solution file ready to import into your Dataverse environment, versioned so an upgrade replaces the control rather than sitting alongside it. The source code in a repository you own, with a build another developer can reproduce on their own machine. Documentation covering the manifest properties, what the control assumes about your data, and how to change it. And a written answer on who owns the intellectual property. If any of those are missing you have a control that works today and no ability to change it tomorrow.
How do we know whether our team can build the control in house?
Ask whoever would build it three questions. What belongs in init as against updateView, and what happens if you create your grid or chart instance inside updateView every time it fires. How you handle a dataset with more rows than the page size. And what exactly gets handed over at the end. The first separates people who have shipped a stateful control from people who have read the documentation, the second is the difference between a demo and production, and the third tells you whether you will own a deliverable or a person. Our guide on hiring PCF developers against freelancers has the full screening list.
Does Solzet build PCF controls for canvas apps as well as model-driven apps?
Yes, and the hosts are a scoping question rather than an afterthought. The same TypeScript and React codebase serves both, but data reaches the control differently: a canvas app has no Dataverse column to bind to, so values arrive through input properties set with Power Fx or a dataset bound to Items, and results go back through output properties. The component framework also has to be switched on per environment before code components appear in Power Apps Studio, and the Dataverse Web API is not available to a control running in a canvas app, so data access belongs on the app side.
What are the options for a Gantt chart or project timeline view inside Dynamics 365?
Four realistic routes. A Gantt visual from AppSource in a Power BI report over Dataverse is fast, handles volume and exports for audit or compliance reporting, but it is read only. An AppSource Gantt component or app can add drag to reschedule, usually priced per user and within the vendor limits. An embedded canvas app suits simple date edits at moderate volume without developers. A purpose built PCF control gives true drag to reschedule with your own rules at high volume, and it is the slowest route to a first version.
Which route is fastest when a report deadline is only weeks away?
Usually not a custom control. A custom control adds a specification, a build, testing and a release before anyone sees results. For a timeline, a Power BI Gantt visual over Dataverse is the fastest route and it exports for the report. Where the report depends on data that users are corrupting through a workaround, correct the data and put validated intake in place first. Commission the interactive control after the deadline if the need is still there.
Pasting from Excel into our Dynamics grid is corrupting data. Do we need a custom grid control?
Not first. Correct the affected records and add validation in Dataverse, such as a synchronous plug-in, so every entry route is checked, then give the paste a validated front door: an Excel template import with an error log, or a staging table validated before rows reach the live table. Many teams then need only the modern editable grid or an embedded canvas app. A PCF grid with in place paste validation is worth commissioning when high volume keyboard entry is daily work.
Do you work on Business Central or Dynamics 365 Finance and Operations?
No. Solzet works on the Customer Engagement side of Dynamics 365, meaning Sales, Customer Service, Field Service, and Customer Insights, plus the Power Platform: Power Apps, Power Automate, Power Pages, Dataverse, and PCF controls. We do not work with Business Central, Finance, or Supply Chain Management. If a control has to display data that lives in one of those, we build the integration from the Power Platform side and work with whoever owns the ERP.
What if we already commissioned a control and it is not working properly?
That is a normal engagement for us and it starts with an assessment rather than a rewrite. Most of the defects we are asked to fix in controls built elsewhere come from the same handful of causes: work that belongs in init repeated on every updateView, state never released in destroy, a dataset control that assumed it received the whole view, or a control that assumed the developer own privileges rather than the calling user security roles. Several of those are cheaper to fix than to rebuild, and we will tell you which case you are in before quoting.
We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both.
Tell us what the control has to do, where it lives, and how many records it faces. We will tell you whether something already does it, whether your own team should build it, or what a tailored one would involve. The first two answers are free and we give them regularly.