Master Solution Dependencies like a Boss

Story Time

I’ve been through stuff in this lifetime 👀… And I’m sure you have as well… Nothing prepared me for this…

I recently had the pleasure of reviewing some solutions that needed a bit of TLC. I needed to deploy some of these solutions to various tenants to stabilise version control and the ecosystem as a whole. Boy, was I unprepared.

Upon importing these solutions into the new tenant (this is not a discussion on deployments, so hold your horses), I was in awe of the 158 dependency errors. To say the least, I spent the next 3 days unpicking all the object dependencies until I hit a brick wall with a Dynamics 365 error. ActivityPointerBase. I looked further into the dependencies and confirmed that although the solution was purely Power Platform, it was riddled with D365-related objects, and I still do not know why.

Let’s just say that the solution was partially stabilised, but because of the ActivityPointerBase error and the non-required, yet somehow required, D365 objects, the solution lives in a D365-enabled environment. Feel free to reach out to help me on this 🙏🏻.

But what am I getting to here? Let me elaborate.

What Are Dependencies

Solution dependencies refer to relationships between various related objects in your solution. For example. Say you are building a Power Automate flow that needs to be run via a service account, so you create a connection reference. When adding actions to your flow and selecting your newly created connection reference, the flow now becomes dependent on that object. Let’s take it a step further. In your solution, you also have a Canvas app. This app connects to a custom table called Students and makes use of a custom view in a collection. This custom table lives in a different solution. The Canvas App now becomes dependent on the Students table and view. See where I am going?

Benefits Of Dependencies

A huge benefit of making use of object dependencies is that you are reusing components and objects within the Power Platform. In our example above, it makes more sense to reference the existing Students table and view from your other solution than to have to create another table from scratch. We can take this approach for more complex solutions as well. Say you are developing a variety of solutions that are dependent on each other but also need to function individually. How is that achieved?

We can take the common objects among all these solutions and create a core solution. The core solution will host all these objects, and the segmented solutions can then make use of the core’s dependencies. Yes, you now need to install a core solution, but you are implementing better governance and control over where your common objects live and how they are maintained.

Downside Of Dependencies

Dependency Issues

We’ve probably all come across a dependency issue at some point. They’re a shocker when they surprise you, and more so when you have no clue what you’re importing. Dependency issues occur when your solution references an object that is not included in your solution and does not exist in the environment it is being imported to. Taking our above example into account, Our Canvas app makes use of the Students table, but the table has either not been added to the solution as an object or the solution hosting the original table does not exist in the environment you are importing to. Thus, dependency issues.

The “Add Required Objects” Button

I’m not a fan of this button. More often than not, if you haven’t set up a decent data model and solution architecture, you are unaware of what your solution requires. Pressing this button can sometimes lead to a bit of a mess. Try adding the Accounts table with all objects to a solution and press the “Add required objects” button on it after. The Contact and Invitation tables now show up. Repeat this for the Contact table. Starting with one dependent table in your solution and pressing this button, in two clicks you have 14 solution objects with some adx object 😱 #nightmare

Best Practices for Including Dependencies

If you know you’re going to have dependencies in your solution, it’s better to plan ahead. Aligning this with ALM frameworks and standards and building a data model and solution architect is a great start. This will help you map out exactly where you may run into dependency requirements. Now, citizen developers may not be as familiar with these processes, so here are some ways to help you make use of dependencies in a sustainable environment.

1. Data Model: Whenever building a solution, it is extremely beneficial to map out the data model. A data model will show you what tables you need in your solution, what the relationships are, and where those tables are stored.
2. Solution Architecture: Identifying and documenting what exists in your solution is a must. By writing down what each workflow does, requires, and outputs, you are able to determine if a new object is required or if you can make use of a dependent object. If you are reusing an object, make sure to document it.
3. Segmenting Solutions: When working with large-scale solutions or multiple solution products, it may be ideal to segment dependencies into core and dependent solutions. It’s a great way to maintain a stable version of your base data model without having to worry about where else the dependent objects live.
4. Documentation: Document, document, document! Document your dependencies, including their purpose, source, usage, and any specific configuration. This documentation will be invaluable when it comes to deployments, releases, and updates.
5. Dependency Tracking: Make use of the built-in dependency tracking features within the Power Platform. This will help you visualise and understand how objects rely on each other. This can help you identify potential issues early, so you are not bombarded with errors upon import.

Conclusion

Object dependencies can be tricky and can cause hell of a mess if you’re not careful. However, if you plan correctly and make sure you are on top of your solution architecture, object dependencies can be the backbone of a scalable and sustainable solution.