Solutions are a foundation of developing on the
Let’s say you have a marketing team. That team has a new process they want to implement using the Power Platform. They want a way to store, track, and rate new ideas – as well as a way for management to approve these ideas. I would consider this process one “solution”. That solution (let’s call it ‘Marketing Ideas’) will likely contain many things. Maybe a new table to store requests, a flow to trigger approvals, and an app for users to interact with – all contained in our ‘Marketing Ideas’ solution. Once you’re done developing those components, you can package up the solution and move it to production, or maybe a UAT environment. If you want more details on HOW you might do this, take a look at
As your solution gets used, the marketing team finds new ways to improve it – as well as a few bugs (oops). When personally put in this situation, I USED to create a totally new solution for each new feature or bug fix. I could pick and choose which new things to roll out to production, with the added benefit of avoiding impressively slow export/import times. That was before I learned about
Creating a solution patch has been a feature for a long time (even before the Power Platform formally existed), but it seems like not many people know or talk about it. For me, it’s a game changer. And for you, it will make managing these new features and bugs MUCH easier to manage. For each new feature or bug fix, you’ll create a solution patch. Within each patch, you can add just the components needed for that feature or fix. You can then either pick and choose which patches to roll out, or roll up all the patches back into the parent ‘Marketing Ideas’ solution.
Thanks for reading, and I hope this tip saves you some time, effort, and sanity next time you’re working with solutions!