Should we use same Dataverse Table in Multiple Solutions?

(2) Share

Report

Posted on by MWork

Hi all,

Should I and/or Can I use the same Dataverse table in multiple solutions?

For example, I will be using Departments, Buildings and Users tables in different apps

What are the best practices to do that?

Should I create a solution that contain these (Main) tables and link in other solutions?
Or it is better to create/duplicate these in each solution?

I was reading in Microsoft documentation regarding solutions in ALM the following (which did not make any sense to me)

"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. (me: 🤯🥴😱🤪) 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."

Isn't the whole idea of solutions is to gather all types of data in one place??

I am almost sure I am missing something here, but honestly I am a bit lost 😕

We are in the first stages of using Power Platform within our organization in a more professional manner

I wanted to make sure we start in a correct way, to be able to scale up as we grow

Thank you!

Categories:

Microsoft Dataverse with Power Apps

I have the same question (0)

All responses (5)

Answers (1)

ChrisPiasecki 6,422 Most Valuable Professional on at

Like (2)

Report

Hi @MWork,

Managing multiple solutions adds extra overhead, especially if you use automated pipelines to build and deploy solutions across multiple environments. In most scenarios I will use a single solution which avoid the extra complexity and solution layering.

---
Please click Accept as Solution if my post answered your question. This will help others find solutions to similar questions. If you like my post and/or find it helpful, please consider giving it a Thumbs Up.

Was this reply helpful? Yes No
EricRegnier 8,720 Most Valuable Professional on at

Like (4)

Report
Hi @MWork,

It really depends on the complexity of your solution(s), type of solutions managed/unmanaged used and new or existing production solutions/environments. I can understand the ALM doc might be hard to understand at first because there are lot of concepts. Furthermore, managing a healthy Dataverse/Power PLatform ALM is complex because it's so important and there's no one strategy for everyone. If you are new to this, I suggest to get experts or partners involved to get setup correctly at first as changing afterwards is difficult.

In general, here are my rule of thumb which follow the ALM best practices:

As @ChrisPiasecki said, if the solution is simple and you really have one solution/module, meaning you're not deploying 2 types of modules into one solution (eg customer service and HR functionally) then keeping it simple with one solution is best. Use managed solution.

If not, then this is when it needs to be well thought of.
Environment (env) setup: have a dev env per managed solution produced/exported. If you have >1 then seriously consider having a base/core/common env. The core solution will imported (as managed) into the other dev and downstream envs. This practice is called Solution Segmentation and Layering.

If you have existing prod env(s) and using unmanaged solution(s), stick to unamanged solutions for now and convert to managed when your env and solution strategy is established and respected. Use same publisher and prefix in all environments in case components need to change “owner”.

Hope this helps a little!

1 people found this reply helpful.

Was this reply helpful? Yes No
MWork 16 on at

Like (0)

Report

Dear @ChrisPiasecki and @EricRegnier , thank you both for taking the time to reply to my question
I agree, it will depend on the complexity of the solution

To understand you correctly,
I can build one solution that contain these shared tables and add all of the apps and flows that use these tables to that one solution, correct?

For the other part of the question, do you agree with the documentation?
"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"

I have around 25 flows and 3 apps currently, does that mean I must put all of the flows in one solution? and all of the apps in one solution? shouldn't each one of the flows/apps has it's own solution?

Thank you in advance, and I agree with @EricRegnier , we might need to get experts help to set up the structure for our company

Regards

Was this reply helpful? Yes No
Verified answer

EricRegnier 8,720 Most Valuable Professional on at

Like (1)

Report

Hi @MWork, apologies ofr late reply. To answer your 1st question around "one solution that contain these shared tables and add all of the apps and flows that use these tables to that one solution", that is correct that one solution can contain all.

For "Segment your solutions by component type", yes depending on your overall complexity and solution strategy. For instance, in an unmanaged scenario, I have a solution containing all the dashboards and one for security roles that is imported at the end after all other solutions.

"25 flows and 3 apps currently, does that mean I must put all of the flows in one solution". If all flows and apps are inter-related or have dependencies, then I would keep in one. If they are completely seperate you can split them if the deployment cadence is different for them, and to speed up release time. You can also split by functionality, meaning you can have one solution for App 1 and its 5 flows and another for App 2 and its related flows, and so on...

Hope this clarifies a little

Was this reply helpful? Yes No
MWork 16 on at

Like (0)

Report

Thank you @EricRegnier it does, I think when I read the documentation it throw me off
Thank you again for taking the time to reply 🙂
Regards

Was this reply helpful? Yes No