Category Archives: Power Automate

Modern SharePoint Page Approval with Power Automate: Message Optional


The current iteration of page approvals in SharePoint Online using Modern pages and news is handled by Power Automate – and the integration is pretty slick. Kudos to the Microsoft teams responsible for it (SharePoint + Power Automate).

Approval Flow

Once an approval flow has been configured and a user submits a page, the user is prompted by the following panel:

Approval Panel

Note here that the Message field is required. In many cases, this is fine. There are some circumstances however where site owners may want to make the Message field optional.

The Quick Steps

Without getting into all the nitty gritty, here’s how it’s done (at least one approach):

  1. Go into Power Automate and open the approval flow
  2. On the first step of the flow, expand the “For a selected item” step
  3. For the “Message” property, select the menu (three dots) button and select “Make the field optional”)
    Flow Field Optional
  4. Expand the scope (mine is called “Scope 2”), and the “Start and approval” step
    Approval Details
  5. Click on the “Details” expression (circled above) – which opens the panel for updates
    Approval Expression
  6. Update the expression to include a question mark (“?”) after “triggerBody()” and before “[‘text’]”.
    Expression Text
  7. Click “Update” (see above)
  8. Save the flow, and test

When an approval is submitted, the Message field in the panel should now show as “not required” – no asterisk should be visible. The panel should allow users to leave the field blank and “Submit” the page for approval without error.

Not Required

The Details

One example I’ve seen where this is applicable is a site where there is a content management team that does a significant amount of the page creation, but also has folks outside the normal content team that submit content from time to time. Approval is needed. When the main content team is creating pages – they want to get through it and keep moving. The Message field turns into a “junk” field, they keyboard smash or put some useless text in the field in order to submit the page. This is irritating for users and inserts bad/silly data into the system. Rather than remove the field outright, we’d still like to have it available when needed – by folks outside the team, for example.  

Let’s review how this works. Open up the flow. Then expand the “For a selected item” step (Step 3 above).

Changing the Message field to “Make the field optional” seems pretty straight-forward. It will even work for some flows. But by itself this change will not work for all scenarios. The flow will fail when the Message field is left blank because later in the flow a step attempts to use the text IN the field. When that text is blank, the flow fails. 

If you run/test the flow with no Message text, you can open the failed instance of the flow to see where the error occurred. The scope will show an indication that something is wrong. When you expand the scope you can see the error on the “Start an approval” step. This flow fail is also followed up by a “Something went wrong…”  email from Microsoft Flow.

Broken Flow

Looking at the error message, there’s something wrong with ‘text’, which looks like it’s pointing back to the Message field we changed.

If we test run the flow again, and put text in the message, the flow works fine.

Looking at steps 4-6 above, you can see where the additional change needs to be made – adding a question mark to the expression. This syntax (the “?”) allows the expression to evaluate the Message field – [‘text’] – as Null when it is empty. Before we added the question mark the expression didn’t know what to do with a blank Message field and failed the flow. 

Note: I haven’t been able to find official documentation anywhere on what the “?” syntax is within expressions, how to use it, when to use it, etc. Maybe my search skills are falling off. If you find something from Microsoft, let me know and I’ll update this post and references for it. Until then I’ll include what I did find below.


Paul Stork has the most information I’ve seen on the use of the question mark (?)  thus far as seen in this community post:
Solved: Use of Question Mark(?) in expressions – Power Platform Community ( 

Another blog that references the question mark with regards to a Power Automate expression
Power Automate – how do we check if a property exists in the object? | It Ain’t Boring (

Modern SharePoint + Power Automate Approval with Select User Auto-Approve


I’m still a Power Automate newb. Lots of you have been working with these for years now. I’m legit curious what silly things I’m doing, what other approach I should be taking, what best practices to integrate, etc.

So let me have it… in the comments here, in Twitter, whatever. I’m waiting.


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.

Now, however, I’d like to have approvals on my site, but also have them bypassed for certain users – 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.

So, we have an out of the box page approval flow that I want to tweak.

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

What I did

The out of box page approval flow looks as follows:
OOB Approval Flow

With the exception of a few new variables I added, all changes were limited to the “Scope 2” step. When I was finished, the top level view looked like this:
(Yes, I should be consistent with my naming – I’ll clean that up)

Final Approval Flow

I’ll walk through the variables shown above as we go.

Who Gets Auto-Approved

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’s sake, I’m going with a list. It’s 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’m also pretty confident that Automate can get to the data I need in a list. I’m not yet sure about the other approaches. Obviously a decision like this may vary org to org. For this example, we’re using a list.

I created a SharePoint list and called it “AutoApproveNews”. Yep, I’m old school and don’t like spaces in my list names. I’m not messing with the Title field right now, so just left it alone and required. It’ll 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… 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’t tried that variation yet.

I didn’t do anything special with permissions for the list while validating this concept, but there are a few ground rules you’d likely want to follow.

  • Make sure whatever connection you’re using to SharePoint from Automate has access to the list.
  • Lock down the list to the folks that manage content so random users can’t just add themselves.
  • I also found it useful to remove the list from navigation. Don’t like cluttering things up unnecessarily.

First note on variables

The approach I’m using is that I’m going to get the name of the person submitting the news article, iterate through my list of folks that get auto-approved, and trip a flag that indicates I found a match.

So with that, AutoApproveFlag is created and set to false.

NewsSubmitter is set to the name of the person that added the new news article or page from the “For a selected item” step.
Submit Variable

The other variables are used in the text of the email, so you can fill in whatever fits for you. Here’s what I did for now:
Variable Initialize

You’ll see where they fit in down below.

New Steps

Using as much of the default flow as possible.

  1. After the “Set content approval status – Pending” add a step to “get items from” a SharePoint list and point it to the AutoApprovedNews list we just created.
  2. Add a “Apply to each” step to iterate through the SharePoint list data.
    Add a condition where if a match (comparing the AutoApproved field to the NewsSubmitter variable) is found, set the AutoApproveFlag variable to true.
  3. Add a Condition step. Test for the value of variable AutoApproveFlag – if not true (no matches found), then start the flow approval. I added the condition step and then dragged the existing “Start an approval” step into the No condition.

    Note: Because there will be some conditions where the Approval doesn’t exist, I need to change some of the email steps later in the flow because they use properties of the Approval in their email content – hence the other two variables that were created: strApprover and strComment. (I should be consistent with variable naming, started thinking about that after I was underway – cleanup for later)

  4. The default flow has a Condition step that waits for the approval response. I didn’t see a way to change the condition the way I wanted, so I created a new Condition step to check for an approval response OR check if the AutoApprovedFlag variable was set to true.

    Note: DO NOT delete the original Condition step until after #5 below and you’ve moved/copied the steps from the original to the replacement.

    Original approval

    New Approval

  5. Move or copy the steps in the yes and no conditions to the new condition step (#4 above). I was able to drag and drop some, but also needed to use the preview functionality of copying steps to the clipboard and then used the “Add an action” feature to add from clipboard.
  6. Now you can delete the original Condition you just copied the steps from.
  7. In order to clean up the emails sent later, I needed to replace Approval properties in the email content with variables that would work both when approvals were automatic and manual. In order to make these work, I needed to add a Condition step and Set Variable steps.

    With new Condition rules, moved steps, and an additional Condition step, the flow looks like this:
    After Moves

    Setting the variables as follows:
    Set Approval Vars

  8. Finally, we need to update the email content to replace the Approval properties with variables. Only the “Send email notification” steps (both “Yes” and “No” outcomes) under the scheduling condition (“Check if content has been schedule or not”) need to be updated.

    These are the ones you’re changing:
    Which email steps

    From this:

    To this:

  9. After we’re all done, Scope 2 looks like this:

I think that’s everything. I’ll update if I find additional details.

Recap, Summary

It works. What am I missing? What should I have done different?

Bring it!!

References and stuff

Thanks to Mark Rackley for a few pointers…