In this blog post continuing on an introduction to Microsoft Graph and utilising the wider Microsoft Cloud ecosystem to build solutions with better impact and improved user experience on low code, we’re going to take a look at an initial idea I’ve had to how we can view solutions when thinking about this context.
If you’re enjoying this series on Microsoft Graph and utilising the wider Microsoft Cloud ecosystem when building on low code and Power Platform, be sure to subscribe to my blog to have these posts and others on Microsoft Cloud technologies and low code delivered to your inbox daily this year!
SubscribeThe three solutions
So as I said, recently when thinking about what we can accomplish by using Microsoft Graph, and contextual data from the wider Microsoft Cloud when building on the Power Platform, it got me thinking about the way, in general, we built solutions. I thought about different solutions I’ve built in the past, solutions I’ve seen others build and more, and categorised these solutions into three areas within the context of using Microsoft Graph and contextual data.
Fitting business requirements with platform only objects
The first area I thought about putting a solution into was a category of a solution that ‘fits business requirements with platform only objects.’
What I mean by this is solutions that only utilise simple, and perhaps maybe sometimes more complex, objects that we can create within a low code platform, in our case here, Power Platform. Here I mean objects such as apps, tables within the platform, flows, processes etc
When I think of these solutions I don’t think of solutions that include interactions with data outside of the platform so much, for example the contextual data in Microsoft Graph.
More often than not I can imagine the solutions that fit into this block are going to be more basic, rather than solutions that perhaps are considered more complex.
Examples of solutions in this category might be things such as task management applications, clocking in and out apps, timesheets, leave requests and other basic solutions.
Building solutions to solely interact with and present data from the Microsoft Cloud
Now moving on from solutions that sit a bit less by themselves and don’t just rely on the objects made available with the low code platform, in this case Power Platform, the second category I thought about putting solutions into with this idea, is a category of solutions that are built to solely interact with and present data from the Microsoft Cloud.
Here I’m talking as simple as calling data from the Microsoft Cloud using the Graph API, and displaying that in some way.
We might transform the data and produce reports from it in Power BI, perhaps even storing it somewhere first like Dataverse in between.
But these solutions don’t go much further than that and combine this idea with the previous we looked at which involves translating business requirements into solutions built with more low code objects from the Power Platform like apps and flows.
Building solutions to fit business requirements that utilise context from the Microsoft Cloud
Now the final type of solution or category that I came up with is completely just a combination of the previous two where I commonly see solutions also increase in complexity.
These are the types of solutions where we’ll use low code objects and building blocks to fit business requirements, but we also use contextual data from the Microsoft Cloud via the Microsoft Graph to support the solutions impact and user experience.
An example might be a Dynamics 365 solution for managing tickets and service cases. That would be the low code solution alone, but having it categorised into this type of solution might involve using contextual data from Microsoft Graph to be able to check resource availability of engineers with a certain title and level in the organisation to get hold of resource quickly for scenarios such as P1 or high priority cases.
Another example might be getting people’s availability when booking events off the back of a record in a Dynamics 365 app or Power Apps solution to prevent the need to spend extra time navigating away to Outlook to get this data from another interface.
I think this third type of solution is where building with low code can get really powerful, with us using the contextual data we create subconsciously on a day to day basis to support our solutions and increase productivity.
Scope for reinventing the wheel
An additional thought to these categorisations that I was thinking about links to these categories and is how each of them have different levels of scope for reinventing the wheel. Personally I think that this scope is high with the first type of solution and reduces towards the third type of solution.
Overview
If you want to stop building solutions that sit in the first category of just fitting business requirements with platform only objects, and you want to start to build solutions that fit business requirements whilst utilising wider platform context, keep following this series on Microsoft Graph and Power Platform.
Make sure you subscribe to my blog to get all my latest posts directly in your inbox.