One Power Platform solution or several? Design for releases, not modules

A common Power Platform design decision is whether to place everything in one solution or create separate solutions for Sales, Customer Service, integrations, shared tables and other functional areas.

Creating one solution per module sounds organised.

However, a solution name does not create technical isolation.

If several unmanaged solutions are developed in the same Dataverse environment, their changes are applied to the same unmanaged layer. Two developers can still modify the same form, table or application—even when they are working from different solutions.

The solution strategy should therefore reflect how the organisation intends to develop, release, support and replace functionality.

The better question is not:

How many modules do we have?

It is:

Which components must be developed, tested, deployed and serviced together?

Three solution strategies

Microsoft currently describes three main approaches in its Power Platform solution-organisation guidance.

Strategy	Suitable for	Main consideration
One solution	Small or medium implementation with one release cadence	Simple deployment, but harder to modularise later
Multiple solutions in one development environment	Independent functional areas with limited shared components	Separate packages, but no development isolation
Multiple solutions with dedicated development environments	Enterprise implementations with multiple teams or partners	Stronger isolation, with additional governance and deployment complexity

Recommended architecture rules

For an enterprise Power Platform implementation:

1. Design solutions around release and ownership boundaries.
2. Keep the number of solutions as small as practical.
3. Use one publisher across related solutions.
4. Do not place the same unmanaged component in several solutions.
5. Keep dependencies intentional and one-directional.
6. Use a small managed base for genuinely shared components.
7. Give independently maintained applications dedicated development environments.
8. Use managed solutions in test, UAT and production.
9. Segment existing tables to include only changed components.
10. Keep each solution in source control and deploy it through a repeatable pipeline.

Source control is the long-term record of the solution. Microsoft recommends treating it as the single source of truth rather than depending entirely on the current contents of a development environment. See ALM basics with Microsoft Power Platform.