While working on a project at work, I came across a very interesting issue with a Microsoft PowerApps and Power Automate. A number of you probably already know this, but if you trigger a Power Automate Flow from a button within a PowerApps app, the Flow retains the context of the user account that triggered the Flow and not the user account that was used to create the Flow. In most instances this is fine, but what happens when you trigger an approval workflow, that needs to update the content approval status of a list item? It would mean everyone would need an elevated level of access to the SharePoint list. What if that was not an option? What if you only wanted a user to only see and edit list items created by them.
This is where the concept of running a child Flow from the Flow that is triggered from a button in Powerapps. The child Flow will then use the context of the user account that was used to create the flow. In my case, in the parent Flow, I triggered a child Flow when I needed to update the content approval status of the list item. All I needed to do was to pass three parameters to the child Flow, the ID of the list item, the content approval status, and any comments the approver may have entered. In the child Flow then I get the SharePoint list item, and then update the content approval status.
This way, I don't need to give everyone elevated access to the SharePoint list, since I am using an account with elevated access to create the child Flow.
If anyone knows of a better way to handle a situation like this, do let me know.