Ian asks, hi, what is the advantage of using Power Automate, or JSON, to retrieve data compared to a direct connection? That is an amazingly wonderful question, and it's also vague enough that you can't really answer it. Are you saying it depends? Well, it depends on what you mean by instead of a direct connection. So my assumption is that he means, why would I use Power Automate to connect this to that versus using an API from some app that he's built that goes straight to your data source? My answer is, well, because it's Power Automate, why wouldn't you use it? Absolutely. So it depends on your- Does the Power Automate, the Power Platform Consultant, yes. Right. So it depends on what you're connecting. If you've got a.NET app and you've got a SQL database, yeah, direct connections, that makes sense. If you're using SharePoint and a Power app, or just SharePoint, or Dataverse, or Microsoft Forms, or fill in the other teams, fill in the other M365 front-end user applications. Power Automate is just so much easier than building a direct connection, assuming that he's talking about like an API to an application that he's building. With Power Automate, you can use the JSON in your data connection, or in your dynamic values. So when you grab, whether you use the SharePoint connector, or you use the parse JSON with like a HTML or HTTP request, the JSON is going to give you every bit of information that you could possibly use. Then as long as you parse it correctly, you can use each of those pieces of information in your dynamic values to do whatever other stuff you need to do in that workflow. If you use the out-of-the-box Power Automate actions, like update SharePoint item, or update Microsoft Excel row, or update a Teams application function, those pieces are all in JSON. They're all using JSON. They're just doing the work for you, so you don't have to write the script for it. So again, it depends on what you're connecting. I always start from the question when it comes to end user behavior is, is it already giving you what you need? Do you need to really rebuild something to give you the same thing? So it comes down to effort and if you don't know the topic, then all the energy going into learn to do exactly the same thing. It doesn't matter what it is in terms of the technology sometimes it's like, hang on, is that effort actually worth it? But until you know the new tech, sometimes it's hard to answer that question. Kind of say that that is a great answer that every ISV gives of the build versus buy argument. And usually the pushback comes not from the customers, but for the consultants that are working with those customers, that would rather build for the hours to build it from scratch. No, it's not that they don't want to do it. They want to go and build the hours to build it from scratch, rather than use the tool of just saying it. Yeah, absolutely. But I see it from, should I move from planner over to list? It's like, well, what are you trying to do to some of the really simple basics? And I go, well, no, you're already getting what you need out of this particular product and let you go into the next level and you want to soup it up. No, not really. And I will then why transfer from one to another if that's not a skill and or technology that you need. But that's my question. Anyway, that's just a bit of an aside. The other piece of this is it's talking about using the Power Automate to retrieve the data versus a connection. So we're assuming that there is a connector in place. If we're getting data like Jonathan said out of SharePoint or an area that's already accessible to Power Automate, it makes perfect sense. But if you're doing like, for example, we've done connections to data that are on-premises, but external to the client. So therefore, we have to go through a data gateway to get that information. There's reasons why you wouldn't do that. So, for example, if I'm getting external data from an on-premises location that's coming in through a data gateway and then coming back to on-premise, I don't know that I would use that particular way of doing it. And I would create the direct connection. I could then use it to grab that data and pull it into something else, but I might need both of those pieces to actually accomplish the goal I'm trying to get to. So it doesn't even have to be an either or question if there's more complexity to it. Exactly. So you're saying we have more questions for the question? No, it's that it could be one or the other or both. It could be. There's three sides to every story. That's right.  Yes.