Building a Custom Kanban Board View for Dynamics 365 with PCF
A technical guide for anyone asking whether there is anything ready made or whether they have to build it: what the out of the box control does and exactly where it stops, what is already published, and how a custom PCF board is built, including the business process flow part.
There is something ready made, and you should check it before you build anything. Dynamics 365 Sales ships a Kanban control, but it works only on the Opportunity and Activity tables, only on main grids, and you cannot add or remove fields on its cards. PCF Gallery and Microsoft AppSource list community and commercial Kanban components that go further, at the cost of fit, support, or a per user subscription. You build a custom PowerApps Component Framework control when the board has to run on your own tables, show your own card fields, or move records through business process flow stages under your own rules. This guide covers all four routes and the build in detail.
Two notes before the detail. First, the limitations of the out of the box control described below reflect the current Microsoft Sales documentation at the time of writing, and Microsoft revises it, so confirm anything load bearing on Microsoft Learn before you design around it. Second, custom PowerApps Component Framework development is one of the things Solzet is hired for, by end clients and by Microsoft partners, and we ship our own Kanban control, so what follows is written from delivery rather than from a summary of somebody else’s quickstart.
Four routes to a Kanban board, in the order to try them
Take them in this order. Each one is cheaper than the next, and the only way to know which one you need is to know where the one before it stops.
Route 1. The out of the box Kanban control, if you are on Opportunity or Activity
Dynamics 365 Sales includes a Kanban control that a customizer adds to a public view of the Opportunity or Activity table. It gives you two board types: swim lanes based on status, and for opportunities swim lanes based on the stages of the Sales Process business process flow. It costs nothing and takes minutes. If your board is a sales pipeline over standard opportunities, try this first, because building something you already own is the most expensive mistake on this page.
Route 2. A community control from PCF Gallery
PCF Gallery is a community catalogue of PowerApps Component Framework controls, and it lists several Kanban style components. Most are free and open source on GitHub. That is genuinely useful: you can read the code before you install it, fork it, and see how active the repository is. What you do not get is a support commitment, a roadmap, or any promise that the author will still be maintaining it after the next release wave. Read the repository before you read the screenshots.
Route 3. A commercial app from Microsoft AppSource
AppSource lists commercial Kanban apps with vendors behind them, usually sold on a per user subscription. You get support, updates, and somebody to call. You inherit their data model assumptions, their roadmap, and a running cost that scales with headcount. Some run entirely inside your tenant and some route records through an external service, and which one it is matters enough that it should be a question you ask before the trial rather than after.
Route 4. Build a custom PCF control
You build when the first three leave a real gap: a board on a custom table, card fields nobody else lets you choose, swim lanes from a business process flow other than Sales Process, work in progress limits, drag validation tied to your rules, or a manual card order that persists. A focused control is a matter of days to a few weeks. The rest of this guide is how that build actually goes, including the business process flow part, which is where most first attempts come apart.
The four routes side by side
None of these columns is always right. The first row is the one most teams have not checked, and it is free.
| Route | What it is | What it costs | Where it stops |
|---|---|---|---|
| Out of the box Sales Kanban control | A Microsoft built control added to a public view of the Opportunity or Activity table, with status lanes or Sales Process stage lanes. | Included with your Sales licences. Configuration is minutes, not days. | Opportunity and Activity only. Main grid only, not subgrids. No card field customization, no role based boards, and opportunity stage lanes only for the Sales Process business process flow. |
| Community control from PCF Gallery | An open source PCF control published by a community developer, usually with the source on GitHub and a managed solution to import. | Usually free. Your cost is evaluation time and whatever maintenance you inherit. | No support commitment and no roadmap. Quality and maintenance vary widely, and a control abandoned two release waves ago is still listed exactly the same way as one shipped last month. |
| Commercial app from AppSource | A vendor built and vendor supported Kanban app, installed from Microsoft AppSource into your environment. | Typically a recurring per user or per tenant subscription that grows with your team. | Fits the vendor data model. You inherit their roadmap and their pace on breaking changes, and some route records through an external service, which is a review your security team has to run before the trial. |
| Custom PCF control | A control you own, written in TypeScript and React against the component framework, bound to your view or subgrid. | A one off build cost, then low running cost. No per user licence on the control itself. | Somebody has to own the code, version it, and rebuild it when a library goes end of life. It is the wrong answer for a board the standard control already delivers. |
The commercial side of the last two rows, cost over time, ownership, and what happens when a vendor sunsets a listing, is worked through in our comparison of building a custom Kanban board against buying from AppSource. This page is the technical half.
Where the out of the box Kanban control stops
These are documented limitations rather than opinions, and each one is a reason a particular team ends up building. Find yours here before you price anything.
Two tables only
The Kanban control works on the Opportunity and Activity tables. Not Case, not Lead, not Account, and not your custom table. If your board is over anything else, this route ends here and the question becomes which of the other three you take. This one constraint is why the majority of Kanban conversations in Dynamics 365 end up being build or buy conversations.
Main grid only, not subgrids
The control is supported on the main grid and is not currently supported on subgrids. So you can have a Kanban page in your app, but you cannot put a small board of related records on a parent form. That is a common ask, and it is a real reason teams move to a custom control even while staying on Opportunity.
You cannot change the fields on a card
Microsoft states plainly that you cannot add or remove fields from the cards in the Kanban swim lanes. If your sellers need the account manager, the close date, and a custom risk flag visible without opening the record, the standard control will not do it. Card content is the single most common reason a team that started on the out of the box board asks for something else.
No role based boards
It is not possible to have a role based Kanban view. Every user with access sees the same board configuration. Where a sales manager and a seller genuinely need different lanes or different card content, you are looking at a custom control or at separate apps.
Status lanes are locked to the Status field
The Activity Kanban view is available only for the Status field, and you cannot configure it for another choice column. The status based Opportunity view has the same restriction. If your process lives in a custom choice column, which is extremely common on tables that are not modelled around the standard sales cycle, the standard board cannot show it.
Stage lanes are locked to the Sales Process business process flow
For opportunities, the Kanban view can only be associated with the Sales Process business process flow. Organisations that replaced Sales Process with their own flow, which is most organisations that took business process flows seriously, do not get stage lanes from the standard control at all.
Aggregation is Estimated Revenue only
In the Opportunity Kanban view, aggregation is supported only for the Estimated Revenue field. You cannot total a different column at the top of a lane. Microsoft also documents that aggregation beyond fifty thousand records in a lane is not supported, where the estimated revenue shows blank and the record count reads as fifty thousand plus.
Drag behaviour follows the platform, not your rules
On a status board, dragging a card opens a status change dialog and moving to the Won or Lost lane closes the opportunity. On a stage board, a card can only move to the immediately next or previous lane, and the main form opens during the transition. That is correct platform behaviour, and it is also the behaviour people most often want to change.
Lane loading and mobile
Microsoft documents that the first ten records show in a lane and the rest arrive as you scroll, and that the Kanban view is not supported in the Dynamics 365 for Phones mobile app. If field users need the board on a phone, that is a hard stop on this route rather than a configuration problem.
If none of the above collides with your requirement, configure the standard control and you are finished. It is added from the Components pane of a public view on the Opportunity or Activity table, and if Kanban is not in the list it is under Get more components on the Built by Microsoft tab.
How to evaluate a ready made control before you commit
Product names on a gallery page go stale. These questions do not, and they are what separates a component worth installing from one that quietly becomes your problem.
When did the repository last move, and does it build
For anything from PCF Gallery, open the GitHub repository before the demo video. Look at the date of the last commit, whether issues are being answered, and which version of the component framework tooling it targets. A control that has not been touched in two release waves is not automatically broken, but you are now the maintainer, and you should decide that deliberately rather than discover it during an upgrade.
Does it write through the platform or around it
Ask how the control saves a move. A control that updates records through the platform Web API inherits your security roles, your business rules, and your plugins. One that calls an external endpoint does not, and it can put a record into a state your own logic would have rejected. This is the difference between a board and a back door, and it is worth ten minutes of reading the code.
Does anything leave your tenant
For commercial apps in particular, establish whether records are processed inside your environment or routed through the vendor infrastructure. The answer decides whether this is a five minute install or a data protection review, and finding out after the pilot is a bad way to find out. Vendors who run entirely in tenant will tell you clearly, because it is a selling point.
What happens at your record volumes
A board that is delightful with forty cards can be unusable with four thousand. Test with a realistic dataset in a realistic view, not with the sample data. Ask specifically how the control pages, whether it loads a lane at a time, and what it does when a lane has more records than it can render. Performance problems on a Kanban board are almost always paging problems.
Can it do the transitions your process actually needs
Moving between simple status values is the easy case. Winning an opportunity, resolving a case, and advancing a business process flow stage are not simple column updates, and a control that treats them as such either fails or leaves records in a state the platform did not intend. If those transitions are in your process, prove they work in a trial before anything else.
What does it cost in year three
Put the per user subscription next to a one off build cost across the same period and the same headcount. Neither number wins automatically. A small team with a standard process usually comes out ahead subscribing, and a large team with a specific process usually comes out ahead building. We work this through honestly in our comparison of building against buying, linked below, rather than assuming the answer.
Building the control, step by step
Steps 1 to 5 decide what you are building and make it configurable rather than disposable. Steps 6 to 8 are the board itself. Steps 9 to 12 are the ones that decide whether it survives real records, real security roles, and a second release.
Confirm the standard control genuinely does not fit
Write down the table, the lanes, the card fields, the transitions, and who needs a different view. Then check that list against the out of the box control: Opportunity or Activity only, main grid only, fixed card fields, Status column only, Sales Process only for stage lanes. If nothing on your list collides, configure the standard control and stop. Most boards that get built did not need to be, and the fastest way to find out is fifteen minutes with this list before anyone opens an editor.
Decide whether the board is a dataset control or a standalone page
A Kanban board over a view or a subgrid is a dataset PCF control: the platform hands you the records the view selected, and your control renders them as lanes and cards. That is the right shape for almost every board, because it inherits the view, its filters, and the user security context. Build a canvas app screen or a custom page instead only when the board is one part of a wider composed experience, and check the hosting differences first, because the APIs available to a control are not identical in both places.
Generate the project and pick your rendering stack
Use pac pcf init with a namespace, a name, and the dataset template. Add the react framework option if you want to use the platform React and Fluent libraries, which produces a virtual control with a smaller bundle and visuals that match the rest of the app. Fluent is worth taking here rather than styling from scratch, because a board that looks foreign inside a model-driven app reads as a bolt on no matter how well it works.
Declare the lane source and the card fields in the manifest
Do not hard code the column that defines your lanes. Declare it as an input property so a customizer can point the control at a status column, a custom choice column, or a business process flow, and declare the card fields as a property set on the dataset so they are chosen in the view rather than in your code. This is the difference between a control that serves one board and a control your team can reuse on the next table without a rebuild.
Read the lane definitions from metadata rather than a hard coded list
For a choice column, read the option set metadata so lane headings, order, and colours come from the same place the rest of the app gets them, and stay right when somebody adds an option next quarter. Utility methods including metadata retrieval are available to code components in model-driven apps, which is another reason a board over a model-driven view is the simpler host. Cache the result rather than fetching it on every render.
Page the dataset properly before you render anything
The platform hands your control a page of records, not the whole view. A lane that silently shows the first page is worse than no board at all, because it looks complete. Use the paging API, check whether another page exists, load until you have what a lane needs, and show the user a count and a clear signal when the view is larger than what is on screen. Decide deliberately what happens at high volumes rather than letting the browser decide for you.
Build the drag interaction with a maintained library and a keyboard path
Use a maintained drag and drop library rather than raw HTML5 drag events, which behave inconsistently and are painful on touch. Whatever you pick, test with a mouse, with touch, and with a keyboard, and make sure a card can be moved without dragging at all, because a board that only works by dragging is a board some of your users cannot use. Bundle the library into your control rather than loading it at runtime.
Move the card optimistically, then reconcile with the result
When a user drops a card, move it immediately in the interface, write the change through the Web API available to the component, and put the card back with a clear message if the write fails. Never leave the board showing a state the database does not agree with. The write will fail legitimately, for example when the user lacks privileges on that record or a plugin rejects the change, and the board should show that rather than swallow it.
Handle transitions that are not column updates
Winning or losing an opportunity and resolving a case are platform messages with their own records behind them, not a value you can set on a column, and the Web API surfaced to a code component gives you create, retrieve, update, and delete rather than the ability to invoke those messages. So either open the platform dialog through the navigation API and let the user complete it, or write a trigger value the control can set and let a plugin or a flow run the real message server side. Decide this before you design the lanes, because it changes what dragging into a Closed lane means.
Wire business process flow stages if the lanes are stages
Stage lanes are not a column on the record. The active stage lives on the business process flow instance record, and moving a record means updating that instance rather than the record itself. The platform also restricts an update to the next or previous stage, so a board that lets a user throw a card across four lanes has to either step through them or refuse the drop. The next section covers this in full, because it is where most first attempts come apart.
Decide whether card order inside a lane has to persist
If users expect to rank cards within a lane, that ordering has to live somewhere. A numeric ordering column on the table, written on drop, is the honest answer, and it needs a sensible strategy for inserting between two cards without renumbering the lane on every move. If ordering does not need to persist, sort by a real column such as modified on or estimated close date and say so in the interface, rather than leaving users to wonder why their arrangement did not survive a refresh.
Test at real volume, on the surfaces it ships to, then version it
Test with a production sized view, with a user who holds a restricted security role rather than a system administrator, and on every surface the app runs on. Then version deliberately: every change needs the manifest version bumped and the solution published, or the platform keeps serving the previous bundle and your fix appears to have done nothing. Ship it as a managed solution so it moves cleanly from development to test to production.
If the board pulls in a third party rendering or drag and drop library, the bundling and lifecycle detail is covered in our guide to integrating third party libraries in a PCF control, and if it has to run on a canvas screen rather than a model-driven view, start with using PCF controls in canvas apps, because the data access changes.
Wiring the board to business process flow stages
Stage lanes are the most requested feature on a custom board and the one that breaks the most first attempts, because a stage does not behave like a column and the platform does not let a card go wherever the user throws it.
The stage is not a column on your record
This is the thing that surprises people. A business process flow instance is a row in its own table, one per record per flow, and that row holds the active stage as a lookup to a process stage. Your record carries a reference to the process and the stage, but the authoritative place to change the stage is the instance row. A control that tries to set a stage by updating the record it is rendering will not move the flow.
You can only move to the next or the previous stage
The platform restricts an update of a business process flow instance to an adjacent stage. That is a direct collision with the whole idea of a Kanban board, where the natural gesture is to throw a card from the first lane to the fourth. You have two honest options: step the instance through the intermediate stages in order, or refuse a non adjacent drop and tell the user why. Pick one, make it consistent, and make the interface show which lanes a card can actually reach while it is being dragged.
The traversed path has to stay coherent
The instance also carries the traversed path, a comma separated list of the stages that have been visited. When you move the active stage forward you append to it. Getting this wrong produces a flow that looks correct on the board and behaves oddly on the form, which is the worst class of bug to diagnose because nobody connects the two. Read the traversed path before you write it rather than assuming what it contains.
Stage gates are business rules and they will reject you
Required fields on a stage exist to stop work advancing before it is ready, and they apply to your write just as they apply to the form. A board has to expect the rejection and handle it usefully: put the card back, name the field that blocked it, and offer to open the record. A board that silently fails to advance a stage teaches users not to trust it within a week.
Find the stage list from the process, not from a hard coded array
Lanes should come from the stages defined on the flow, read at runtime and in their configured order. Hard coding stage identifiers works right up until somebody edits the flow, and then it fails on one environment and not another, which is a genuinely unpleasant afternoon. The same rule that applies to option set metadata applies here: read the definition, cache it, do not embed it.
More than one flow can apply to the same table
Where several flows exist for a table, different records can be on different processes, and a single set of lanes cannot represent all of them honestly. Decide the behaviour up front: filter the view to one process, group the board by process, or show records on other processes in a lane of their own. The standard control sidesteps this by supporting only the Sales Process flow, which is exactly the constraint that sends people here.
The practical consequence is a design decision rather than a coding one. Decide early whether your board advances a card one stage at a time, steps it through the stages in between, or refuses the drop, then make the interface honest about it while the card is in the air. Every board that users abandoned that we have been asked to look at got this wrong in one of those three ways.
How Solzet builds Kanban boards for Dynamics 365
Custom PCF development is a core part of our Dynamics 365 Customer Engagement and Power Platform delivery, and a Kanban board is one of the things we are asked for most, so this is what the work looks like when we do it.
We tell you when not to build it
The first thing we do on a Kanban request is check it against the standard control and the components already published. If your board is a sales pipeline over standard opportunities on the Sales Process flow, we will say so, and that conversation costs you nothing. A control that exists to avoid fifteen minutes of configuration is a maintenance cost with no ceiling.
We already ship a Kanban control, so the build starts from working code
The Solzet Kanban Board is our own PCF control that turns a Dynamics grid into a drag and drop workflow, with records as cards and columns as statuses or stages. Where it fits, it is a fast start. Where you need more, we extend it or build to your specification, which is a materially different starting point from a blank project.
Native PCF, not an iframe with a board inside it
The control is a real component framework control in TypeScript and React. It runs inside the Power Apps runtime on model-driven views and subgrids, it honours your security roles because it writes through the platform, and records stay in your tenant. That is the difference between a board that is part of the application and a board that is a website borrowing your data.
The awkward parts are the ones we specify first
Business process flow stages, opportunity and case closure, card ordering, and behaviour at volume. These are the four things that decide whether a board gets used, and they are the four things a demo never shows. We agree them before the build rather than discovering them in user testing.
Delivered as a managed solution with source and lifecycle handled
You receive the managed solution, the source code, and documentation, with versioning that actually moves when the code changes and a clean path from development through test to production. Your team can maintain it after handover, and if you would rather we did, that is an ongoing support arrangement rather than a dependency you did not agree to.
We work white label for Microsoft partners
A significant share of our PCF work is subcontracted by other Microsoft partners under their brand, under NDA, using their tooling and their repositories. That is a normal engagement shape for us rather than an exception, and it is often how a partner covers a TypeScript gap on one project without hiring for it permanently.
Certified engineers in one time zone, inside one specialism
Solzet delivers Dynamics 365 Customer Engagement and the Power Platform: Sales, Customer Service, Field Service, and Customer Insights on Dataverse, plus Power Apps, Power Automate, and PCF. We deliver from a single hub in Yerevan, Armenia, at GMT+4, which overlaps Western European hours and reaches into the US morning, and our engineers hold Microsoft certifications including PL-200, PL-400, and PL-600.
See the Solzet Kanban Board, the rest of our published controls, and our PCF controls development service. If you are weighing a specialist team against a freelancer for this kind of work, we compare the two honestly in hiring PCF developers.
Frequently Asked Questions
Is there a ready made Kanban board for Dynamics 365, or do I have to build one?
There is a ready made one, and whether it is enough depends on one question: which table is your board over. Dynamics 365 Sales includes a Kanban control that a customizer adds to a public view, but it works only on the Opportunity and Activity tables, only on main grids rather than subgrids, and you cannot add or remove fields on its cards. Beyond that, PCF Gallery lists community built Kanban controls that are usually free and open source, and Microsoft AppSource lists commercial apps sold on a subscription with a vendor behind them. You build a custom PowerApps Component Framework control when all three leave a real gap, most often a board on a custom table, specific card content, or lanes from a business process flow other than Sales Process.
What are the limitations of the out of the box Dynamics 365 Kanban view?
Microsoft documents them clearly and they are more restrictive than most people expect. The control works only on the Opportunity and Activity tables. It is supported on the main grid and not on subgrids. You cannot add or remove fields from the cards. Role based boards are not possible, so everyone sees the same configuration. The Activity board and the status based Opportunity board work only with the Status field and not with another choice column. Opportunity stage lanes can only be associated with the Sales Process business process flow. Aggregation is limited to the Estimated Revenue field. And the view is not supported in the Dynamics 365 for Phones mobile app. Any one of those can be the reason a team ends up building.
Can I put a Kanban board on a custom table in a model-driven app?
Not with the standard control, which supports Opportunity and Activity only. For a custom table your options are a community control from PCF Gallery, a commercial app from AppSource that supports custom tables, or a custom PCF control. A custom dataset control is usually the cleanest answer here because it binds to a view of your table, inherits that view filters and the user security context, and lets you choose which columns appear on the card. If you build it with the lane column and the card fields declared as configurable properties rather than hard coded, the same control serves your next table without another build.
How do I make a Kanban board show business process flow stages as columns?
You read the stages from the flow definition and use them as your lanes, and you change a record stage by updating its business process flow instance rather than the record itself. The instance is a row in its own table with the active stage held as a lookup to a process stage, plus a traversed path listing the stages already visited. Two constraints shape the whole design. The platform allows a move to the next or previous stage only, so a board has to either step a card through intermediate stages or refuse a non adjacent drop. And required fields on a stage will reject your update exactly as they would on the form, so the board has to handle the rejection, return the card, and say which field blocked it.
Why does dragging a card to Won not work on my custom board?
Because winning an opportunity is not a column update. It is a platform message with its own record behind it, and the same is true of resolving a case. The Web API surfaced to a code component provides create, retrieve, update, and delete rather than the ability to invoke those messages, so a control cannot simply call them. The two supported patterns are to open the platform dialog through the navigation API and let the user complete the close, which is close to what the standard control does, or to have the control write a trigger value that a plugin or a flow picks up and runs the real message server side. Decide which before you design the lanes, because it changes what a Closed lane means on your board.
How long does a custom PCF Kanban control take to build?
It depends almost entirely on the transitions rather than on the board. A board over a single table with lanes from a choice column and simple drag between values is a matter of days. Business process flow stage lanes, opportunity or case closure, persisted card ordering, work in progress limits, and multiple processes on the same table each add time, and together they are the difference between days and a few weeks. Because we already ship the Solzet Kanban Board, we can usually start from working code rather than a blank project, which moves the estimate down rather than up.
Is a community control from PCF Gallery safe to install in production?
It can be, and it is a decision to make deliberately rather than by default. A code component runs code Microsoft did not write inside your application, so import only from sources you trust and read the repository before the demo. Check when it last changed, whether issues are answered, which tooling version it targets, and whether it writes through the platform Web API rather than calling an external endpoint. If it is open source and maintained, you can also fork it, which is a real advantage over a commercial app. What you do not get is a support commitment, so be honest internally about who owns it the day it breaks.
Will a custom Kanban control survive Microsoft release waves?
PCF is a supported Microsoft extensibility model, built with TypeScript and React and running natively in the Power Apps runtime, so a well built control is designed to survive release waves rather than to be rebuilt each time. The maintenance that does arise usually comes from your own dependencies rather than from the platform, which is one reason we keep third party libraries to what the board genuinely needs and bundle them properly. We ship controls as managed solutions with source, and applying release wave updates can be part of ongoing support.
Can I use a Kanban PCF control in a canvas app as well as a model-driven app?
Yes, with a design change. A dataset control in a canvas app takes its records from the Items property and can be pointed at any tabular source, so the board renders fine. What does not carry over is data access from inside the component, because the Dataverse Web API is not available to code components in canvas apps. So the writes on drop, the metadata reads, and anything to do with business process flow instances have to move into the app using Power Fx and connectors, with the component exposing what the user did through an output property. It is a cleaner separation, and it is more work than lifting the model-driven version across.
Should we build the board or buy one?
Buy, or use what you already own, when your process fits a standard board and you want it working this week. Build when the board has to run on a custom table, show specific card content, follow a business process flow other than Sales Process, enforce your own drag rules, or belong to you rather than to a vendor whose subscription grows with your headcount. The honest test is to write down the five things your board must do, check them against the standard control limitations, then evaluate what is already published before pricing a build. We go through the commercial side of that comparison in detail on our page comparing a custom Kanban build against buying from AppSource.
Tell us what the board has to do
Send us the table, the lanes, the card fields, and what happens when a user drags a card across. You will get a straight answer on whether the standard control, something already published, or a custom build is the right call, and what building it involves. Solzet is a Dynamics 365 Customer Engagement and Power Platform consultancy in Yerevan, Armenia, working with clients and Microsoft partners across Europe and the US.