Hi there, I am curious about the following usecases.
Is it best practice to create 1 solution per app, thus 1 solution = 1 app OR is it best practice to create 1 solution for multiple apps? Let's say I have 5 apps that are needed for Sales. Is it better to create 5 solutions or just 1 solution named "Sales Solution" and insert the 5 apps into that solution?
I am curious to what is better!
Hi there,
a question related to this: I have multiple apps per solution, say AppA and AppB. When I update just the AppA and redeploy the solution, and run the AppB in the target environment, Powerapps player shows the top banner saying there's new version of the app available (even though it's still the unchanged version of AppB, which is annoying from end-user perspective). Is this by design or just a bug, that will be eventually removed in future? If by design, I guess I'll go with one app per solution, as suggested above.
I searched for advice on this topic and frankly found little.
In our case I built an app a long time ago that really needs to be brought into the future.
It's had a couple of iterations. It started in Lotus Notes and is now in ACCESS. It's a CRM which incorporates service (both calls and visits), as well as parts and sales. All of this has always been under one roof. By that I mean one app with many different components.
As I go down this path I'm looking for opinions regarding the best way to do this... as it relates to the individual components: asset management, service phone calls, service visits, tech scheduling, parts (inventory/shipping/invoicing), and training and document management. It also incorporates sales process tracking.
Now mot of this can obviously done in a single app. I'm wondering if on Power Apps this is the best approach.
I appreciate your thoughts.
Hi @Gjakova ,
Did any of the responses here from the community assist? Please accept if so or let us know if any questions. Thanks much!
Hi @Gjakova ,
My normal approach aligns more with @AhmedSalih here. I normally have multiple apps for one solution as we might create some model / canvas apps all tied to the same system and domain.
The main thing I would focus on is if you are creating a solution that will be stand-alone and may be distributed to other customers etc. you need to focus on the dependencies of this... If you create multiple solutions in the same environment you will get dependencies existing and if you try to break one out, it will be a challenge based on my past experience. If I am trying to create a stand-alone functionality that may be reused across a number of systems / customers / etc. I make sure to create a separate environment for this and a separate solution and deploy this to the other environments as a managed solution. This way you will not create dependencies that should not exist and will help you control through ALM processes. Hope this makes sense.
Hello, @Gjakova , Just to add to @Mira_Ghaly , I prefer to group my apps that are part of one solution together. So, if I have multiple apps that are part of one project, I have them all in one solution. As for the ALM, there is going to be a nice feature for Citizen developer to implement ALM easily and having multiple apps in one solution won't be that hard anymore.
It is very dependant on how you wanna structure your solutions in my point of view it is better if you have a solution per app, it would be easier for ALM and change management as you don't have to deploy the whole solution.
mmbr1606
22
Super User 2025 Season 1
stampcoin
17
ankit_singhal
11
Super User 2025 Season 1