Unanswered

Need advice on building solution layers

(0) Share

Report

Posted on by Eccountable

I have been using this product since MS CRM 3.0 was released and I am a developer by trade. I am building a complex application using both Canvas and Model driven apps on Dataverse and I am looking for some advise on best practices to build using application layers. Most of my experience has been working with single solution files delivered as unmanaged, but we have multiple people working now in a single dev environment and the customer prefers managed solutions.

Therefore, I think we should use segmented solutions to draw clear boundaries around where certain configuration parts are built. My plan is/was to emulate (something like) the ADX solution layer approach, and create a core solution with just table schema and metadata, one for automation, one for security, and a UI solution with forms and views (my memory is probably faulty in this regard).

I have read the Solution Lifecycle Management PDF and it simply notes that there are challenges with this approach, but nothing I can start with. Can someone give me some of their lessons learned/best practices about how I should layer solutions?

Thanks in advance.

Categories:

Power Apps Pro Dev & ISV

I have the same question (0)

All responses (6)

Answers (0)

Sort by

Parvez Ghumra 1,579 Moderator on at

Like (3)

Report
Copy link

Link copied!

Hi @eccountable,

I believe Microsoft still recommend building a single unmanaged solution per development environment, so that would potentially mean multiple different development environments for each 'layer', and each one being promoted to the development environment corresponding to higher layers as managed.

If your solution segmentation is based on technical boundaries (ie. component types), this can become quite expensive and complex to implement, so the approach I have taken so far is to have all my unmanaged solutions built in a single development environment. The Microsoft recommendation could potentially be more practical if your segmentation was based on another dimension (eg. based on geographic region, or business process/functionality etc)

I have been trying to work out a clean separation/segregation approach for solutions based on component types in my head for a while. The following is the best I could come up with but haven't tried it yet, so not 100% sure it would work. Hopefully it gives you a bit of a starting point. The idea is to think about potential component inter-dependencies and plan the correct solution to place each component type in in order to deploy in a fixed order gracefully. So any additional component you introduce, would need to be planned into the correct existing solution or introduced into a new solution in the correct place. I haven't considered here things like SLAs, Templates and many other component types that you should consider.

Solution 1: Custom Connectors and PCF Controls
Solution 2: Data Model (Entity, Columns, Choices, Web Resources, Security Roles, Field Security Profiles)

Solution 3: Plugin Assemblies, SDK Message Processing Steps, Custom Workflow Assemblies, Classic Workflows, Custom Actions, Custom APIs
Solution 4: UI (Forms, Views, Charts, Dashboards, Business Rules, Business Process Flows, Reports)
Solution 5: Cloud Flows and Connection References
Solution 6: Model-Driven Applications and Sitemaps, Canvas Apps, Custom Pages

Hope this helps. Happy to discuss further.

Was this reply helpful? Yes No
a33ik 3,306 Most Valuable Professional on at

Like (2)

Report
Copy link

Link copied!
@eccountable we use a pretty much similar structure of solutions that @parvezghumra provided with a slight variation.

@parvezghumra just for my understanding - when the custom entity is added how do you split Data Model (entity itself) and UI - Forms and Views one from another? It doesn't look like something doable for new custom entities.

Here is the structure we used in one of the projects I'm currently working on:

WebResources and PCFs

Core - Entities, Fields, Views, Dashboards, Global Optionsets, Connection Roles

Misc - Knowledge Management, Email Templates, Environment Variables, Record Creation, and Update Rules

.Net Components - Plugins Assemblies, Plugins, Plugin Steps (Excluding steps that handle actions' messages), Custom Workflow Steps

Processes - Workflows, BPFs, Actions with steps that handle actions, Custom API

Flows - Connection References, Custom Connectors, Power Automate Flows

Security - Security Roles, FLS Profiles

Applications - Model Driven Apps, Canvas Apps, Custom Pages, SiteMaps, Component Libraries, Settings

If you have anything extra that is not listed you will have to either find the most appropriate solution or add a new solution that has dependencies only on previous elements

Was this reply helpful? Yes No
Parvez Ghumra 1,579 Moderator on at

Like (1)

Report
Copy link

Link copied!

@a33ik That's a great point that I hadn't considered. Thanks for raising. As I said, I haven't tried and tested this particular approach yet 😃 Based on this I would assume you would place your forms into your 'Core' solution with Views? If that's true, wouldn't your Security Roles need to go into the 'Core' solution too because of potential dependencies that forms can have on them?

Now that you mention it, and having thought this through again, I think there's no option but to move forms and views out of solution 4 and include into solution 2 instead if you're following the pattern I suggested in my previous comment?

Great discussion, and this is always a fascinating discussion!

Was this reply helpful? Yes No
a33ik 3,306 Most Valuable Professional on at

Like (1)

Report
Copy link

Link copied!

@parvezghumra good point on Forms that are dependent on Security Roles. In this case, I believe Security Roles can be placed into "Core" solution.

Was this reply helpful? Yes No
Eccountable 48 on at

Like (1)

Report
Copy link

Link copied!
Thanks @parvezghumra and @a33ik (Andrew). The layers work, but the stumbling block is that when I create a custom table, it creates forms and views in the core solution that cannot be removed. That means if I add lookups, subgrids, or quick views to the forms, then my core solution begins to have dependencies to objects in the UI solution. Now my plan is to use a pristine 'core' environment where I create the tables but do nothing else, and export that core solution to my dev environment as managed (thus mimicking the CDS managed layer). Then I can build my segmented solutions on top of that in a single environment. Here is my model / deployment order:
Utility - Reusable code that is not specific to an environment, such as a PCF, web resource, or JS
Core - Custom tables
Foundation - Additional fields, relationships, global choice, table metadata
Automation - Business logic such as WF, CF, Plugin, data duplication rules, connection references
Security - Security Roles and FLS profiles
UI - App, site map, forms, views, JS, BR, dashboards, template, canvas page
I am able to successfully build and deploy layers of managed solutions to a production environment, although this was a very simple test run with a couple tables and not a fully-loaded development effort. One more thing I learned was that the publisher I created in the Core environment is not available in my Dev environment, so I also had to create a solution for just the publisher and import it as unmanaged into the Dev environment so that I didn't end up with more than one publisher.

I will be updating this thread as I learn more.

Was this reply helpful? Yes No
Parvez Ghumra 1,579 Moderator on at

Like (0)

Report
Copy link

Link copied!

Nice work @eccountable. Sounds like you're on the right track

Was this reply helpful? Yes No