You’re offline. This is a read only version of the page.
The idea is to minimize the complexity of the solutions by avoiding dependencies that cross solution boundaries. But sometimes its actually simpler to split things up into multiple solutions. For example, I have a Dataverse table used by more than one App/flow. I could have one solution that has everything in it. But that could become quite large. Or I can have one solution for each set of related apps and flows and one solution for the Dataverse table. Having the table in a different solution will mean I have to import that before importing any of the other solutions. But it also means that I don't have to import all the apps/flows into an environment if I don't want to. There are different ways to organize things. Use different solutions where it makes sense to organize dependencies into a separate group or put everything together to avoid cross dependencies. There is no perfect way to do it each scenario requires different handling.
Sorry, you cleared up my questions mostly, but now I did actually think of one more question: on the documentation about organizing solutions, it says
Segment your solutions by component type when there are no cross-dependency risks. For example, have one solution that includes all of your tables, another solution that has all of your plug-ins, and a third solution that has all of your flows. These different components don’t have risks of cross-solution dependencies. Therefore, it is safe to have multiple solutions formed this way in the same environment.
Don’t have two different solutions in an environment where both contain tables. This is because there are frequently risks of a single relationship between tables, which creates a cross-solution dependency and causes solution upgrade or delete issues in the target environment at a later point in time.
I have seen people not suggesting to do this and instead just group by the related components that are needed by the app/bot/etc you are creating like you are saying. If we stick to having several completely separate applications in the environment that both have their own tables and components (and are all just in the same environment because they need to access the Dataverse database), how does this "cross-solution dependency" develop?
For the most part your statements are all correct. Its a little different if using the PVA client inside Teams instead of the regular Web PVA client. When in Teams a special environment is created in the Team when you create a new bot the first time. Everything created in that Team using either the PVA or Power Apps client will then go into a specific solution in that environment. In a regular environment bots you create are added to a default solution in that environment. So it depends on what the environment picker is set to where a new bot goes. But you can always create it in a specific solution by using the New Button in the solution.
Solutions are simply packages of items and dependencies that can be moved by exporting/importing them between environments. Its the best way to move things from a Dev to Test to Production environment. But there is no explicit way to set permissions at the solution level on the things inside the environment. Instead you set the permissions as you normally would on the Bot or database. There are permission settings that apply to what you can do with a solution, like import and export it.
In general then environments are a place where you can have a segregated space to control apps, flows, bots, etc. If the data source is Dataverse that will be specific to the environment also. If its something like SharePoint then its independent of the environment.
Solutions are a way to package up related components and move them from one environment to another. This is important because dependencies between components can become lost or broken if they aren't moved together. For example, if you have a bot that calls a flow and you don't move them with a solution you may need to re-add the flow to the bot after importing both in the new solution.
I hope that helps. Let me know if anything is still unclear or you have more questions.
#1
Romain The Low-Code...
99
#2
Pablo Roldan
61
#3
Michael E. Gernaey
26
Super User 2025 Season 1
Share
Report
All responses (
Answers (
