Organizing solutions

[KAL]

Well, after reading documentation around application lifecycle management (ALM) and solutions, particularly organizing solutions and supporting team development I have designed a sample solution organization strategy that I want to apply for an existing project. I want to discuss and refine that design here.

For this sample, I have considered a Microsoft Power Platform environment having Dataverse and first party D365 Sales and Customer Service solutions installed.

In base solution there would be

• Out of the box base tables with new or changed components that refer only to the base solution tables and components. So, for instance, account form having sub grids referring custom sales tables would be created/added through sales solution.
• Custom base tables with all components referring to base solution components (including components created by adding new table to the solution)
• Plugins and workflows referring only to base solution components

Similarly, in Sales and CS solutions

• OOB Sales and CS tables with new or changed components
• Custom Sales and CS tables with all components
• Components of base tables referring to Sales or CS solutions (for e.g. forms having Sales or CS table sub grid or views having columns from Sales or CS tables)
• Plugins and workflows referring to Sales and CS solution components.
• Plugins and workflows related to base solution tables and referring Sales and CS solution components.

In Shared Components solution

Components that are shared across solutions (i.e. both Sales and CS solutions in this sample)

• Custom tables related to both Sales and CS tables
• Any plugins and workflows referring to both Sales and CS solution components
• Security roles, dashboards and  SSRS reports

Apart from above mentioned solutions, I have created a separate solution for custom connectors. But I think these could be added to Shared Components solution also. I am not sure what would be the good practice.

And then separate solutions for apps and flows. I could gather them in one solution but keeping in mind developer isolation scenario where two different developers have to work on apps and flows, I think keeping them separate would be good.

I am not 100% sure I have transformed the information provided in documentation into a good solution organization sample or not. So, please discuss and help me in correcting and refining the sample solution organization strategy. Please see the visual added below.

Best regards,

Khadim Ali

[filcole]

It's recommended to put custom connectors in their own solution, see https://docs.microsoft.com/en-us/connectors/custom-connectors/customconnectorssolutions#known-limita...

[cchannon]

In your base solution, ensure you have included the minimum possible set of base entity components. Even within the same environment, each org is not guaranteed to be on the same Dataverse version or 1st party solution version, so when you put managed content into your solutions, you could inadvertently move unresolved dependencies. If you MUST include first party content in your solutions, include the minimum you possibly can. Do not include the 1st party forms, and do not add 1st party entities with "include all subcomponents"

[KAL]

@cchannon 

Where you said "Do not include the 1st party forms ...". So, for example, if I have added another main form to a base table, contact for instance, or modified the existing main form to include couple of base attributes: Do you suggest to add that form in the sales or customer service solution instead of the base solution?

[cchannon]

What I suggest is that you pretend the first party form doesn't exist at all, and only ever work on forms that you make yourself (i.e. make a NEW main form and only work with that).

Let's take an example here: Dynamics has been rolling out a bunch of AI modules in the last couple years. Let's say they put out a 9.3 release and it adds a column to the Contact record, we'll call it "myprediction". If all Microsoft did was add it to the table, then you would have no problem. But of course they won't do that because they want people to see the features they add. So they add it to their Main form.

Now let's say you follow my advice and never let it be part of your solutions. In that case, you don't care. They could add ANY field and you wouldn't care. BUT, say you don't take this advice and you DO include their form, what happens now if the environment you are exporting from has 9.3, but the environment you are importing to has only 9.2? Well, your import fails of course, because 9.2 doesn't have "myprediction" yet; that won't be installed until 9.3

Now, I will qualify this with the point that usually people don't care about this. For most companies, the worst case scenario here is that they have to wait a couple months before installing the new release. But, under some circumstances it can be worse: What if you are in commercial, but your customer is in GCC? or you are on the latest preview build but your customer isn't? Now you could be waiting 4, 5, maybe 6 months for the target environment to catch up, which is probably unacceptable. Most of my customers are in that GCC bucket, so I am super-sensitive to this topic, but I think it is good practice for everyone.

Bottom line: Don't ever add dependencies on anything you don't control if you have any choice in the matter.