{"id":1354,"date":"2021-08-05T15:49:15","date_gmt":"2021-08-05T21:49:15","guid":{"rendered":"http:\/\/www.idubbs.com\/blog\/?p=1354"},"modified":"2021-08-05T15:49:15","modified_gmt":"2021-08-05T21:49:15","slug":"modern-sharepoint-power-automate-approval-with-select-user-auto-approve","status":"publish","type":"post","link":"https:\/\/www.idubbs.com\/blog\/2021\/modern-sharepoint-power-automate-approval-with-select-user-auto-approve\/","title":{"rendered":"Modern SharePoint + Power Automate Approval with Select User Auto-Approve"},"content":{"rendered":"

Background <\/h2>\n

I\u2019m still a Power Automate newb. Lots of you have been working with these for years now. I\u2019m legit curious what silly things I\u2019m doing, what other approach I should be taking, what best practices to integrate, etc. <\/p>\n

So let me have it\u2026 in the comments here, in Twitter, whatever. I\u2019m waiting. <\/p>\n

Overview<\/h2>\n

Power Automate backed approval flows for a SharePoint intranet site on the Site Pages library. Pretty slick and polished as a replacement for SharePoint workflows and nice template to look at for Automate newbs. Kudos Microsoft folks. <\/p>\n

Now, however, I\u2019d like to have approvals on my site, but also have them bypassed for certain users \u2013 folks that own the site, do the majority of content generation, etc. I still want the process in place because I have other content contributors that I still want to manage. <\/p>\n

So, we have an out of the box page approval flow that I want to tweak. <\/p>\n

It sounds potentially easy, but we all know better. There will be some pain. And there is. But we can work with it. <\/p>\n

What I did<\/h2>\n

The out of box page approval flow looks as follows:
\"OOB<\/a><\/p>\n

With the exception of a few new variables I added, all changes were limited to the \u201cScope 2\u201d step. When I was finished, the top level view looked like this:
(Yes, I should be consistent with my naming \u2013 I\u2019ll clean that up) <\/p>\n

\"Final<\/a><\/p>\n

I\u2019ll walk through the variables shown above as we go. <\/p>\n

Who Gets Auto-Approved<\/h3>\n

This is a topic that could be debated in terms of the best way to manage the list or folks that get auto-approved. Should you use a list, an Azure Group, a SharePoint Group, or something else? For simplicity\u2019s sake, I\u2019m going with a list. It\u2019s the easiest to maintain visibility and control at the team level without needing to work with a security team every time we need to change a group. I\u2019m also pretty confident that Automate can get to the data I need in a list. I\u2019m not yet sure about the other approaches. Obviously a decision like this may vary org to org. For this example, we\u2019re using a list. <\/p>\n

I created a SharePoint list and called it \u201cAutoApproveNews\u201d. Yep, I\u2019m old school and don\u2019t like spaces in my list names. I\u2019m not messing with the Title field right now, so just left it alone and required. It\u2019ll need to be filled with rubbish for now. The only column I added to the list was AutoApproved as a Person or Group field displaying the Name. Yes, the name might not be unique\u2026 so something to look at later to seal the process up a bit more. Using the email address is probably a nicer, more unique, approach but I haven\u2019t tried that variation yet. <\/p>\n

I didn\u2019t do anything special with permissions for the list while validating this concept, but there are a few ground rules you\u2019d likely want to follow. <\/p>\n