 Eurani asks, one question in PowerApps, can I see if a flow is running? Maybe not in the front-end PowerApp that you've created or you're using, but you are able to go into Power Automate. Then I believe there is a monitor tab on the left rail and underneath monitor, you'll see the different types of activities like Cloudflow activity or desktop flows depending on what you built, but you should be able to see the runs that you have access to. A question that this just makes me think about, it's increasingly coming up is around the governance of PowerApps and Power Automates, those different activities. In fact, I just interviewed somebody this week that has strong recommendations around creating a center of excellence around the citizen developer activities in general, but for tracking all the flows that are available within the organization, is anybody here doing it to that or their organizations doing it to that level where you're tracking, you have more visibility into who created, when, where it's actually deployed and being used? I've only seen it from a developer aspect because it's native to developers to track that stuff, especially when they put it into a CI or what they're following it and they're creating the PowerApp with source control. But I mean, I've never seen it. People are using it, I know for a big insurance company here and they probably have 30 or maybe more than that now, and they're all over the board really. It's just the Wild West right now, and it's like SharePoint when it first came out. The governance around SharePoint is like the Wild West for a lot of people because they really don't grasp the concept of needing standards and things like that. What works you need to understand is it's not just a binary choice, it's not just the turn it all on, let everybody do everything in the Wild West approach, or we don't know what it is, therefore we fear it, lock everything down, and not let people do things that there is. It just scares people away. That's right because they'll go find their way to get their work done, whether or not you give them permission to do it, and so you want to do it in a managed control. Control is probably the wrong word for it. A secure and administered process, that's what governance should be about, is not getting in the way of people getting their work done, but doing it in a safe, measurable, reliable way. Yeah. Norm, go ahead. I thought there is back to that original question. I thought there was some nuance about being able to monitor in the flow itself, or the app. Are you talking about the admin being able to see through the, or were you referring to a... I think he's making a segue because he originally was monitoring what happens with the app, because is anybody actually watching the flows? Is anybody actually making sure that they run, making sure there's no errors, making sure of this and that, and then Christian kind of dived into this overall governance, making sure everybody understands. I think that's where that was going. I don't want to speak for you, Christian, but I think that's where you're going with it. Yeah. Okay. So my assumption when answering was, the user is interacting with the Power App. They've submitted a job or clicked a button that's triggering it, and sometimes you do get a window, a dialog window that comes up and says, you can monitor this flow, and it essentially brings you over to the monitor cloud flow activity for that case, but I don't think that's always the case. So it could be undertaken by a Power Automated Min, but it could also be done as a user. Presumably they can see the flow if they're executing the flow. Interesting. Cool. Yeah, because you just, you click the flow in your My Flows dashboard, and it shows you its history at the bottom of that. And currently I have two of them running, the one that I'm looking at. It's waiting for me to approve my retweets, so. It is an interesting conversation around governance, and a lot of people, you know, maybe probably myself included, probably don't have the full grasp of what governance should look like with the Power Platform. Things like the COE toolkit are a big investment in time and ability. So you come to this point where, you know, guidance, or sorry, governance branches off to guidance and things like Power Automated are great for personal productivity, but you reach that point where I'm running the business of the organization from my personal account, and where's the guidance needs to be there to say perhaps there should be a service type of account or a service principle, depending on the use case. And having the guidance, the mentoring from organizational leaders to help implement that safeguards, the investment that users are making on behalf of the organization. Well, that's it. Oh, sorry, go ahead, Sherry. There's a second question in the list that might be a good thing to kind of roll together. That it's talking about the flows and when do you use, you know, service accounts versus personal accounts? Right. Which is kind of what I was gonna just comment on, Sherry, exactly that point is that there's a key part of any governance strategy is at the beginning, is like stepping back and looking, okay, what is our approach? We're the right ways, like we see now this activity, it's a bit of the wild west out there, now let's step back and say, how do we wanna approach this in general? And it might be that, okay, we're gonna set a policy now that we're going to create these solutions with a service application. Therefore we can then centrally manage, monitor, manage, and we'll only authorize, like it's great if somebody has a need there, but we wanna authorize certain people to go and create those or to launch those and let's, again, put a process in place, not meant to slow down the needs, like the difficulty where a lot of shadow IT happens is where IT is not responsive to the needs of end users, if they have to wait too long for those needs. So if you find it's taking too long, you know, don't be surprised that people then go around the process. Part of that issue is Christian, people should, I mean, if you're in IT and you know that there are people that are engaging this, if it's not something that's kind of like a stealth operation from another department or business unit or something like that, you need to be on top of this because so many times, I'm sure we've all seen this, is that it's really, you're being reactive to everything and the biggest problem is, like you said, you have to go back and you're gonna create the policies around things that are already created and one of the biggest complaints that I've heard of and I've gotten called in to help with is the retrofitting of what was already created to align to these new policies that have been put in place because they didn't have the policies, now they have them and they're like, oh, we gotta change all this now to match what they want us to do. But that's just the reality, that's part of that organic process, new technology, we're learning how to use it, now we understand it, we realize but we need to do it this way, here's why. I just think that you need to make that process transparent, work with those end users and on those flows that are out there, especially if it's getting broad acceptance and it's being used and say, this is why we have to go and rebuild this, anything new, use this and then over time. Like, I don't believe in the rip the Band-Aid off, just kill all those existing flows and now we've created the new way, you have to do something in between to kind of baby step the organization. Sometimes Rip and Replace doesn't work. Right, exactly, but it all starts with being clear and like document, like here's why and it should always be a conversation first before you go in the hammer drops and you will do this. So for my benefit, I've built many flows that are relied on for some key business stuff. And I don't know the difference between a service account and a service principal, is there a difference there? And can you illuminate me please? Well, a service account is a object that is associated with a specific group, a specific role, correct. A service principal can be associated to multiple roles. A principal object can associate itself to multiples and it works mainly with applications or applications that access resources within an infrastructure like Azure. Okay, because they do have service principles in like Google Cloud and they do have a service principal, I don't know if they call them service principles in AWS, but in Azure they use the term service principles. So the service principal is more of an interactive and multi-pronged, I mean, it can use and do multiple things where a service account is kind of a single, it's specific to a role, things like that. Gotcha, cool, thank you. Many of the actions and the triggers that you will create in your flows have been directly associated to your account. If you were to leave your organization and the account becomes deprovisioned over time, well, your flow stops to work. And so this is where we talk about safeguarding that investment, maybe not to govern but just to save the investment is all I'm saying. And how do you bring that to people's attention? Like, do you go, is there some way to look at everyone that's got a flow and go proactively reach out? That's a great question. I would hope that it's in the COE toolkit but I don't know for sure. Yeah. I'd be speaking out of turn. Interesting. Yeah, that's actually a great topic for another day. That actually came up in the interview that I did around the COE, the center of excellence template and what's included and what's there and recommendations like that, we should definitely capture that in another recording. And you're getting a link to the COE stuff, yes? I'll do that right now. Wait. Yeah.