Microsoft Flow

It was fairly easy to say to SharePoint Workflow (both in 2010 and 2013 versions) that certain action or actions should be executed with the elevated permissions.

That was a handful solution every time we wanted users to be able to update an item during the process, to which they don’t have write access directly.

How was it done in SharePoint 2010 and 2103 Workflows?

It was fairly easy. Once in a designer you simply had to click on the icon “Impersonation Step” (SP 2010):

SharePoint Designer 2010, Impersonation Step, Workflow 2010
SharePoint Designer 2010, Impersonation Step, Workflow 2010

If you were lucky enough to have Workflow Manager in the farm and therefore available SharePoint 2013 Workflows, you could use “App Step” instead of “Impersonation Step”. First you needed to enable “Workflow can use app permissions” site feature:

SharePoint 2013 Workflow, feature: "Workflow can use app permissions"
SharePoint 2013 Workflow, feature: “Workflow can use app permissions”

And then ready to go!

SharePoint Designer 2013, App Step, Workflow 2013
SharePoint Designer 2013, App Step, Workflow 2013

Find more about these features on Melissa Hubbard‘s blog: https://melihubb.com/2017/04/11/app-step-vs-impersonation-step/

How this can be done in Microsoft Flow?

There are possibly many more ways than described by me below, however there is one principal rule behind them: you have to loose context of a user, so that Flow will use the credentials defined for the connection while it was created (usually Flow author, but you can use of course credentials of a pre-created “Service Account”).

Let’s imagine a scenario: you have a Flow, that handles the approvals and is triggered once an item is created (or modified, or both). Now you’d like to change status in the related item every time approval completes, but the user executing it shouldn’t have rights to modify the item anymore. See how this can be solved.

1) Trigger Flow via HTTP Request

Create second Flow that is being triggered using “When a HTTP request is received” action. Define it’s Request Body, e.g.:

{ "ItemID": 1, "NewStatus": "Completed" }

Remember to use also the “Response” action, so that the primary Flow will wait until update is completed:

Update item in SharePoint using pre-defined connection, no user context
Update item in SharePoint using pre-defined connection, no user context

Then simply call this Flow using “HTTP” action from the primary Flow.

Please remember, that using HTTP action in Flow requires Flow P1 subscription for author and users who are executing the Flow.

2) Trigger Flow via Azure Queue

In this solution you again have to create a second Flow, that is being triggered by “Azure Queues” action. Then once in your main Flow a task is completed, you need to simply put a message on the queue, e.g.:

Putting message on Azure Queue
Putting message on Azure Queue

Next create a second flow, that will read that message and update SharePoint item accordingly:

Getting message from Azure Queue and parsing it
Getting message from Azure Queue and parsing it

Although for this solution you don’t need Flow P1 subscription, but instead you need Azure Subscription available. The Azure Queue uses “Pay-as-you-go” model (see pricing: https://azure.microsoft.com/en-us/pricing/details/storage/queues/)

In this approach the main Flow will not wait until the second Flow is completed, since they are running totally independently. You can build a workaround, e.g. a loop that is checking if there are any messages in a queue and if there is a response message from the second Flow – move on. Otherwise pause for e.g. 10 seconds:

Pause until response message is present in the Azure Queue
Pause until response message is present in the Azure Queue

You can as well count messages in the Queue, once number is 0 means the item is updated.

3) Trigger Flow via Azure Service Bus

Similar to Azure Queue, Service Bus also offers a queue, where primary Flow can store a message and the second one, that is triggered using the “When a message is received in queue” action. Then it updates the item and finally can delete the message from queue.

Azure Service Bus to trigger Microsoft Flow
Azure Service Bus to trigger Microsoft Flow

For this solution you also need Azure Subscription available. The Azure Service Bus uses “Pay-as-you-go” model (see pricing: https://azure.microsoft.com/en-in/pricing/details/service-bus/)

Learn here what are the differences between Azure Service Bus and Storage Queue:

  1. https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted
  2. https://www.c-sharpcorner.com/UploadFile/fe6121/deep-dive-into-azure-storage-queue-vs-azure-service-bus-queu/

4) Use Azure Function

The last solution I would be thinking of is the Azure Function. However it is the most complicated approach and I see no real benefits. Also, to call an Azure Function you again have to do it by either HTTP trigger, or Queue trigger, so you need still to have either P1 subscription or only Azure Subscription.

The major benefit from using Azure Function is that you can register it in AAD and grant it access using “Application permissions”:

Granting application permissions to SharePoint in AAD
Granting application permissions to SharePoint in AAD

This will result in a real case, that an item is actually being updated by a system account, not any named “service account”.

Thanks for reading! If you have any questions leave them in comments box below or contact me directly!