In this next post within my series on solution architecture for the Power Platform we’ll take a look at a next consideration we should think about when it comes to designing Power Platform solutions being our interaction with data. There’s a whole host of things we have to consider and think about when it comes to data and the solutions we’re building, given pretty much EVERYTHING we’re doing sits around data. Data is SUPER key when it comes to solving business problems, so do NOT look at this area lightly at all! Data is KEY 🔑 friends! (Pun not intended)
Where is the data?
So the first question we have to ask is ‘where is the data’ or ‘where will it be’? Now the pretty fantastic thing here, like with most forms of development is that this isn’t actually a huge question when it comes to developing on the Power Platform. Regardless of where our data is, we’ll be able to connect to it from the Power Platform. We should still think about this though as it will affect the work item breakdown and solution design we come up with.
Microsoft Dataverse
So we can store data inside of the platform as a starting point using Dataverse.
The thing to remember here though, is the broad capabilities that Dataverse has to offer more than just being a database. Whether its the ability to implement low-code business rules, out-the-box security backed by Microsoft Entra ID, or the ability to integrate with data lakes, there’s a whole host of capabilities Dataverse has to offer that as a solution architect you should be aware of and take into account when choosing a data platform.
Data outside of the platform
So the next thing we can do as mentioned, is interact with data that sits outside of the platform. We do this using any of the 1000+ connectors that exist for the Power Platform out the box. Oh and if that isn’t enough, we can build our own custom connectors from APIs to leverage inside of the platform.
Not only that but let’s say you have data existing in another database such as a SQL Server and you want to utilise the benefits of Dataverse say and need to build a model-driven app solution that interacts with that data… in these scenarios we can look to virtual tables to bring that data into Dataverse and interact with it in a similar way.
Real-time analytics
Now when it comes to working with Dataverse, every interaction and CRUD operation against the data platform is carried out with an API call to the Dataverse API. If you’re working with requirements for things like real-time analytics and reporting where a data analyst might need to see live versions of the data in your Dataverse instance regularly, then calling the Dataverse API for this or using a Dataverse connector say isn’t going to achieve that requirement.
In these cases solution architects should be aware of the capabilities around Azure Synapse Link, Microsoft Fabric and real-time analytics using data lakes.
Consider contextual data
An absolutely huge factor I like to educate friends on in the data space is HOW we use data and some of the data we can be interacting with that we don’t in the best way possible all the time perhaps. It’s super important that we think about the potential capability of using data contextually in our solutions to improve user experience whether this be in the UI or even something like automations.
A fantastic source of data we can use contextually for Microsoft 365 customers lives in the Microsoft Graph. Learn more about contextual data and Microsoft Graph in my series here…
Custom APIs
The next thing to consider is making custom APIs available for your service or solution you’re building. Don’t think you need to work with more custom development to be able to build custom APIs and combine different operations and logic into an API. Dataverse allows us to do this. In my next blog post, we’ll look more into the methods that exist for implementing custom logic when building Power Platform solutions 🚀