The Structure of a Dynamics 365 Solution

At first, a solution is just a folder: a named collection of references to components that live in the environment. Still, its structure decides how easily a system can be delivered and maintained later. Here is a walk through the building blocks that matter.

The Publisher

Every solution belongs to a publisher, and the publisher brings the name prefix that ends up in front of every technical name. This link is permanent. You can switch the publisher for the solution. The components already created keep their old prefix forever.

The publisher also carries the option value prefix. It applies to every choice column created under it, global and local alike. This one is hard to correct later as well, because the numeric values are stored in the data. How to pick both correctly from the start is covered in Choosing Publisher and Prefix.

Components and their subsets

A solution can contain a component completely or in parts. If you add a table with all its objects, everything travels with every export. That includes foreign columns that happen to hang on the table. You can also add it in segments, with only selected columns, forms, views and charts. Then the export stays lean and the dependencies stay manageable.

Segmentation is the recommended approach today. It has one quirk: what is not in the solution is not delivered. A column that someone created in development but never added to the solution is missing in the target environment. If the error is noticed at all, it happens during testing.

The navigation of an app is a component of its own too. It only travels along if it is in the solution. See SiteMap XML Explained.

Dependencies

Components refer to each other: a form to columns, a flow to a table. If a reference points to something outside your own solution, a dependency arises on the solution that the target component comes from.

These dependencies are stored in the "solution.xml" of the export and are checked during import. If a required solution is missing in the target environment, the import fails. In grown environments, often nobody has the full picture of the dependency web anymore. At the same time, it is the part that decides the import order.

The version

Solutions carry a four-part version number. For managed solutions, the platform enforces it: a version with a lower number than the installed one cannot be imported. For unmanaged solutions it is not enforced. There, an import with a lower number is possible and reliably causes confusion. A new version is then applied as an upgrade or update. The import type you choose decides whether anything is deleted in the target environment. The version number only pays off with discipline. That means counting it up with every export and adding a short note on what changed.

A simple scheme has proven itself: major version for larger rebuilds, minor version per delivery, build for interim states and revision for hotfixes. Microsoft recommends this as best practice as well. More important than the scheme is that there is one and everyone sticks to it.

How to recognize a good structure

Whether a solution is well structured shows in three places. It can be delivered independently of others, without a fixed order that has to be observed first. Its content can be described in one sentence, for example as the sales module or the integration to the ERP. And its export stays at a size where an import takes minutes instead of hours.

If you cannot answer these three questions for an existing solution, you probably do not have a solution. You have a container that everything has moved into over the years. That can be repaired too, just not on the side.