You’re offline. This is a read only version of the page.
I currently have all the objects of a model driven app I'm building in a single solution. Now as the thing is growing, I'm trying to split the whole up into smaller solutions that would follow a reasonable dividion and ease deployment from DEV to PROD. Also I recently faced some solution import errors based on business rules being on/off and inability to "Upgrade solution" to the next new version in PROD environment. My current idea of the division is the following:
1 Base solution
2 Business rules and processes
3 Cloud workflows (including connection references maybe)
I'm now trying to move my business rules from the original (1 Base solution) to the new solution (2 Business rules and processes). I've added those there, so they now exist in two solutions. I'd now like to delete those from the original solution and keep updating them in solution 2. All of this is in the same (DEV) environment. How could I do that? Is it reasonable to do this type of a division?
Left photo: In the original solution I'm not able to remove those business rules from the solution, just delete?
Right photo: In the new solution I'm able to remove business rules from the solution, or delete
Thanks @gowrihalan04 , this is helpful! If you know any other resources or posts about good practices for dividing solutions taking dependencies into account I'd be interested as well!
Hi @AnttiKai The proposed solutions is based on my experience as well as the Proper dependency management. I used these solution in all my past implementations. In the early stage of the development we wont get issues. But when the solution becomes bigger and dependencies become complex and components gets added, it is really important to order solution in certain order understanding the dependency. For example I have kept web resource as first solution. If I import my entity solution without webresource and if my entity has a JS registered on the form ideally solution will fail because web resource is not available yet. You can keep the web resource in your entity solution itself but image your dataverse is bit complex and you created so many entities in it. Your solution become heavier so you might end up dividing the solution.
So based on your solution size you should choose number of solutions and components within the solution.
Thanks for the comment @gowrihalan04 !
I'm thinking of dividing business rules to their own solution due to recent errors in solution imports that track down to business rules / workflows. With the divisions of solution that you proposed, what is the reasoning behind or is it purely from experience? Is there something about ease of implementation or ALM, or osmething else? Or are the divisions based only on what is easy to understand and work with for the developers?
Hey @AhmedSalih
I originally created the tables inside the 1. solution and all development has been done there. Now I'm thinking of dividing into separate solutions.
@AnttiKai Business rules are part of entity components. So Would recommend you to keep it with your Entity,views,fields. You can bind processes and cloud flows in one solution. It dependents on complexity/size of the solution. If it is small implementation you can have single solution. If it medium then you can have 3 solutions(webresource,configuration,security role in 1, plugin assembly and steps in 2nd solution, and OOB WF and flows in 3rd solution). If it big implementation better to have multiple solution like below.
1. Web resource (JS,HTML,JPG,PNG,JSON,JQuery)
2. Configurations (entity components (entity,fields,views,business rules,sitemap))
3. Customization (plugin assembly,steps, WF assembly)
4. Process (OOB WF and Flows).
5. Security roles
Hello, @AnttiKai, did you create your table initially inside the first Solution, or you added them to it?
#1
WarrenBelz
637
Most Valuable Professional
#2
stampcoin
570
Super User 2025 Season 2
#3
Power Apps 1919
473
Share
Report
All responses (
Answers (
