From Cross-Dependencies to Scalability: How We Built a "Super Core" for Power Platform Solutions

From Cross-Dependencies to Scalability: How We Built a "Super Core" for Power Platform Solutions

If you’ve ever worked on a large Power Platform project, you’ll know that managing multiple interconnected solutions is like walking a tightrope—it’s tricky, nerve-wracking, and one misstep can cause chaos. Let me share how we turned our tangled mess of cross-dependent solutions into a streamlined, scalable architecture with a "Super Core" at its heart.

The Struggle: When 7 Solutions Became a Nightmare

A while back, we had 7 primary solutions in our project. At first, it seemed like a reasonable setup — each solution had a purpose, and everything was in its place. Or so we thought.

In reality, these solutions were so intertwined that publishing them felt like trying to untangle a pair of headphones from your pocket. Here’s what we faced:

- Cross-Dependency Chaos: We couldn’t publish Solution #1 until Solution #2 was published. But guess what? Solution #2 couldn’t be published until Solution #1 was ready. This infinite loop left us banging our heads on the desk more often than we’d like to admit.

This problem is pretty well described in Rob Wood article, I recommend reading it:

https://rnwood.co.uk/posts/why-going-round-in-circles-with-power-platform-solution-dependencies-hurts/


- Bloated Solutions: One of the solutions ballooned to 10 megabytes, and importing it into the target environment took anywhere from 6 to 10 hours. More often than not, the import failed because of some forgotten dependency.

- Deployment Stress: Even the smallest change felt like we were defusing a bomb. Would it work? Would it fail? Would it break something else? Every deployment was a gamble.

The Breakthrough: Building a "Super Core"

After enough late nights and headaches, we decided it was time for a fresh start. The solution? A Super Core architecture that would simplify our structure, reduce dependencies, and make deployments less stressful.

Here’s what we did:

1. Super Core Solution:

We created one centralized solution - Super Core - to house all of our customizations. This became the foundation for everything else.

Thus, all components from 7 solutions were moved into one, and the old 7 solutions were completely removed from the system and all target environments.

2. Base Solutions:

On top of Super Core, we built 7 Base Solutions, each focusing on a specific area like customer management, product data, or case handling. These solutions are self-contained but rely on Super Core for shared logic and data.

3. Business Solutions:

Finally, we added 6 Business Solutions, tailored to specific departments or processes. These solutions are lightweight and independent of each other, which means fewer headaches and more flexibility.

After importing the Managed version of Super Core into the targeting environment, it was possible to painlessly remove all the previous 7 solutions that were no longer needed.

Of course, after that, we created new, fresh and empty solutions that would contain only fresh changes to existing components and new components.

This three-tier architecture — Super Core → Base Solutions → Business Solutions — gave us the clarity and control we needed to scale and maintain our system.


When we redesigned our architecture, one big question was: horizontal or vertical?

- Horizontal Structure:

This approach splits solutions by technical layers (e.g., entities, plugins, workflows). While it’s great for smaller projects, it creates cross-dependencies in larger systems and makes aligning with business processes difficult:

Horizontal Approach (like an example)

- Vertical Structure:

Here, solutions are divided by business capabilities (e.g., sales, customer service). It’s more aligned with how businesses operate and reduces interdependencies, but it requires careful planning to avoid redundancy.

Our Hybrid Approach:

We combined the best of both worlds:

- Super Core: A horizontal solution that serves as the technical backbone.

- Base Solutions: Vertical solutions that group related functionalities.

- Business Solutions: Highly focused vertical solutions for specific teams or processes.

This hybrid model allowed us to balance technical cohesion with business alignment.

How We Migrated to Super Core

Migrating components from the old solutions to Super Core was no small feat, but we had some trusty tools to help us out:

- XRMToolBox’s Solution Components Mover Tool: This tool was a lifesaver for moving components from one solution to another:

https://www.xrmtoolbox.com/plugins/MsCrmTools.SolutionComponentsMover/

- ADO Power DevOps Tools, Copy Solution Components:

https://marketplace.visualstudio.com/items?itemName=WaelHamze.xrm-ci-framework-build-tasks

Our CI/CD pipelines used this step to automate the transfer of components during builds and deployments.

With these tools, we have moved components of all of our 7 solutions into Super Core.

Move Components

The New Strategy: A Clean Slate Every Few Months

The key question you may have is: how and when to upgrade Super Core, especially if we need to remove some components from it?!

To keep things tidy and efficient, we implemented a follow-up strategy for maintaining Super Core:

1. Component Migration: Every 6 months we migrate all new or updated components from our 13 solutions into Super Core. Also, we remove any components from Super Core that we no longer need.

2. One-Step Upgrade: We perform a one-step upgrade of Super Core, refining and consolidating components to keep it optimized.

3. Fresh Solutions: After upgrading Super Core, we replace the existing 13 solutions with clean versions that contain only the latest changes. This keeps our environments clean and eliminates the clutter of old, unused components.

4. Start Fresh: With the clean slate, we move forward with leaner, more manageable solutions until the next migration cycle.

This approach not only keeps our architecture healthy but also simplifies deployments and reduces risks.


General scheme of the applied approach

Results and Lessons Learned

The difference was night and day. After implementing the Super Core architecture:

- Faster Imports: That bloated 10MB solution that used to take 10 hours to import? It’s gone. Our new solutions are more compact, and importing them all to the target environment (btw, this is a managed solution upgrades) takes up to 1 hour. That's a win!

- Partial import: we don't have to do an import of all 13 solutions. We import only what has changed.

- No More Dependency Loops: Publishing is straightforward and stress-free.

- Simpler Deployments: Teams can work independently without stepping on each other’s toes.

But it wasn’t all smooth sailing. Here’s what we learned:

- Migration Takes Time: Moving components into Super Core required careful planning and patience.

- Discipline Is Key: Teams had to stick to the new structure and avoid slipping back into old habits.

- Training Matters: Educating teams on the new architecture was critical to its success.

Final Thoughts

Transitioning to a Super Core architecture was one of the best decisions we’ve made. It gave us the clarity, control, and scalability we needed to handle a growing system while reducing the headaches of cross-dependencies.

If you’re facing similar challenges in your Power Platform projects, I can’t recommend this approach enough. And don’t forget to use tools like Solution Components Mover and Power DevOps Tools to make the migration smoother.

Let me know — have you tried a similar approach? What challenges have you faced with solution dependencies? I’d love to hear your thoughts and experiences in the comments.

Here’s to a cleaner, faster, and more efficient Power Platform in 2025! ??

#powerplatform #powerapps #dataverse #solutions #microsoft

Benedikt Bergmann

Microsoft Business Applications MVP | Gesch?ftsführer CRM Konsulterna Deutschland

3 周

Very nice write-up. Thanks for sharing! I find that the vertical structure easily creates cross-dependencies. Horizontal is usually fine since one can plan for the dependencies to be just in one direction. One reason is that different departments often use the same components (especially for example Contact and Account table). How do you handle those cross-dependencies? With a setup like this, I often recommend a different environment structure than just DEV, Test and Production. Something more complex with different DEV environments building on top of each other. This makes handling of dependencies much easier. What is your environment setup for this approach?

Tony Mykhaylovsky

CRM Dynamics Consultant/Developer

1 个月

We are starting to be in a similar boat. Thank you for sharing, Valentin. Aaron Vogt, please take a look

Rob Wood

Microsoft FastTrack Recognised - Principal Architect at TTEC Digital

1 个月

Thanks for sharing your story. I'm glad you found a balance that works for your team.

Achyuth Naveen Vajh

Software Engineer at Amazon

1 个月

Totally crazy adventure! Cool.

Valentin Gasenko

Microsoft MVP | Power Platform Solution Architect

1 个月

Alistair S., I couldn't help but mention you. Read the article, what do you think????

回复

要查看或添加评论,请登录

Valentin Gasenko的更多文章

社区洞察

其他会员也浏览了