Organize your solutions

Before you create solutions, take some time to plan ahead. For example, think about how many solutions you want to release and whether the solutions will share components.

Also, determine how many Microsoft Dataverse environments you'll need to develop your line of solutions. You can use a single environment for most strategies described in this article. However, if you decide to have only one environment and later realize that you need more, it can be challenging to change the solutions if people have already installed them. Using multiple environments, although introducing more complexity, can provide better flexibility.

The following sections describe different strategies for managing solutions listed in order from simple to more complex.

Single solution

By creating a solution, you establish a working set of customizations. This makes it easier to find items that you have customized.

This approach is recommended when you only want to create a single managed solution. If you think you may have to split up the solution in the future, consider using multiple solutions.

Multiple solutions

If you have two unrelated solutions that don't share components, the most direct approach is to create two unmanaged solutions.

Note

It is very common in solutions to modify the application ribbons or the site map. If both of your solutions modify these solution components, they are shared components. See the following section to see how to work with shared components.

Multiple solution layering and dependencies

When you import different solutions into your target environment, you are often creating layers where the existing solution lies underneath the one being imported. When it comes to solution layering, it is important that you don't have cross-solution dependencies. Having multiple solutions in the same environment using the same unmanaged component should be avoided. This is especially true with tables.

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.

When you are designing your solution layers and you want to have a structured approach for apps you should start with a base layer. Later, you import additional solutions that will reside on top of the base layer. Subsequently, you have a base layer and extension layers on top that extend that base layer.

When you manage your projects this way, we recommend that you use a separate environment for each layer. Build your solution layering using these steps.

1. Before you create the solutions in the following steps, use a single publisher for all your solutions across your environments. More information: Solution publisher

2. In the "base" environment, you have your base solution with the unmanaged tables from that environment and no other tables. You then export this solution as managed.

3. You set up a second environment for the extension or "app" layer that will later reside on top of the base layer.

4. You import the managed base layer into the app layer environment and create an unmanaged solution for the app layer.

   

You can now extend the data model by adding additional tables, columns, table relationships, and so on, into the app solution. Then, export the app solution as managed. Notice that the app solution will have dependencies on the base layer solution.

In your production environment, you import the managed base layer and then import the managed app layer. This creates two managed layers in the environment with clear dependencies between the two managed solutions. Managing multiple solutions this way won't create cross-solution dependencies, which can cause solution maintenance issues, such as removing the top layer if needed.

Repeat this segmentation pattern to have as many different solutions as you need to maintain. Although we recommend that you keep the number of solutions as small as possible to keep your solution layering manageable.

See also

Use segmented solutions
Scenario 5: Supporting team development