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
Similarly, in Sales and CS solutions
In Shared Components solution
Components that are shared across solutions (i.e. both Sales and CS solutions in this sample)
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.
It's recommended to put custom connectors in their own solution, see https://docs.microsoft.com/en-us/connectors/custom-connectors/customconnectorssolutions#known-limita...
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"
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?
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.
Join us for the next call on August 17, 2022 at 8am PDT.
The first Microsoft-sponsored Power Platform Conference is coming in September. 100+ speakers, 150+ sessions, and what's new and next for Power Platform.
Join us for two optional days of workshops and a 3-day conference, you can choose from over 130 sessions in multiple tracks and 25 workshops.