Update to using Microsoft Flow for approval of site pages

In May of last year I wrote a post which showed how you could implement approval of modern pages in SharePoint using Flow. That post was written before the edit experience implemented the Submit for approval button.

While the built-in approval is nice, Flow approval provides easy to use actionable messages which makes approving that much easier – no need for the approver to visit the page library to actually approve the item.

In my previous post I added a step to check for the Pending status of the page before invoking a Flow approval action in order skip the Draft and Approved states which should be ignored for the Flow itself. This means Flow will trigger more than actually needed – but that was the way to go last year.

Seems the SharePoint triggers have now been updated to support trigger filters, which means the steps can be optimized a bit.

Click the ellipses (…) on the trigger and pick Settings.

In the trigger conditions settings add the following to trigger only for items which are awaiting approval.

@equals(triggerBody()['{ModerationStatus}'],'Pending')

In order to use the content approve action you still need to get the correct ETag, which means the Get file metadata action has to stay.

A simple auto-approve Flow would look like below.

Happy Flowing!

Approve a document in Teams using Adaptive Cards and Flow

Co-incidentally the same scenarios often appear simultaneously from different people at the same time, and this is one of them.

I’ve been assisting with random comments to a client who wants to start an approval on a document, and have that show up as a card with Approve/Decline buttons in Teams. And yesterday the good SharePoint/Flow man himself Chaks at Microsoft reached out with a similar scenario.

Chaks wanted to build a bot for this, and I asked if he had tried the Adaptive Card action in Flow, and have card buttons trigger an approval/decline action via a HTTP trigger. Turns out that adaptive cards via Flow in Teams does not support Action.Http. End of story.

Here I am, having told a client this should be easy, and Chaks telling me I can’t do it. Being me, that’s not acceptable, of course it can be done – and turns out my ego was right this time :D (it’s not always)

Start the approval Flow from SharePoint.

Adaptive card in Teams.

Important: Enable Major, minor versioning and approval on the document library. And I have not put any thoughts into licensing of actions in Flow if any for this scenario.

How??? Let me show you!

Gotcha in Microsoft Flow when modifying properties on a newly created file

This one is a common task, something I've set up a quadrillion times with workflows and event receivers in SharePoint over the past decade or so. And now the time has come to using Microsoft Flow.

The scenario is that when a file is created, you have a piece of business logic which should set metadata on the file. It could be a status flag, a serial number - the business cases are many and diverse.

Read on, young apprentice (you know who you are :) )

Disable Event Firing when Flow updates a SharePoint list item

There’s a lengthy discussion over at https://powerusers.microsoft.com/t5/Flow-Ideas/Disable-Event-Firing-when-Flow-updates-a-SharePoint-list-item/idc-p/271110 to have a Flow trigger on a SharePoint item being modified, and then be able to update that same item in the workflow without causing it to re-trigger, causing a possible infinite loop.

The workaround posted so far is to check on a specific field if you are to update the item or not. This causes Flow to fire twice per item, one for the actual update, and one where it skips the update based on some status logic.

Melissa Hubbard has a post on the workaround solution over at THE INFINITE LOOP: WHAT IT IS AND HOW TO AVOID IT.

[Update]
It is also possible to use the ValidateUpdateListItem REST API as well, but you need to ensure you get the dates formatted correctly. I could not make it work for Norwegian locale, but once setting the locale to English I got it working. Examine the output of the action after a test run to see if dates had issues or not.

A big thank you to John Liu for pointing this out, as I missed the trick of setting the date when testing this API when researching this post.

http://johnliu.net/blog/2019/2/flowninja-hack-78-modifying-modified-by-and-modified-time-with-microsoft-flow

As an update to the JSON payload used in John's post, set bNewDocumentUpdate to true, if you don't want to add a new version to the item you are updating (kind of counter-intuitive).

[Original Post]

The underlying issue causing this behavior is that any update to a SharePoint item will trigger an update event for the list. EXCEPT if you use a method called SystemUpdate, which is only available via the JSOM/CSOM/Native SharePoint API’s, and not the REST API.

This quickly becomes very technical, but until the SharePoint Flow connectors support the ability to update using a System Update, this is what we have to deal with. It is certainly possible to overcome this issue, but it involves a bit of XML which might throw you off. If not, read on.

Gotcha in Microsoft Flow when handling SharePoint list item attachments

I’ve written a couple of these, where I in PowerApps allow the user to upload attachments to a list item. This feature can typically be used to upload documents or photos from the end user.

While list attachments work fine they are often easier managed in a separate document library, or perhaps you want to perform some other action on them. And this is where Flow comes into the picture. When the item is saved in SharePoint associate a Flow which triggers on new items in the list.

What is important to note is that when list items with attachments are created, the item is first created, and then each attachment will be a subsequent operation. When this action is performed using a phone or tablet the attachment upload might take some time, and Flow might very well trigger before all the attachments are done uploading - the effect being that Flow will miss some of the attachments, and your business process can miss some important data.

Sending e-mails in Microsoft Flow using SharePoint

Introduction

A lot of Flow scenarios involve sending alert or information e-mails to someone in your organization.These are typically e-mail which don’t require a response. Something happened, and you want to notify someone. And this is what this post is all about.

Yeah, yeah, we should cut down on e-mails, but that’s not happening any time soon – so read on!

Use Microsoft Flow to implement approval of site pages

Photo by Zachary Nelson at Unsplash

Again I’m late to the party, but Microsoft has released an action to Flow called “Set content approval status”. This action enables you to add content approval not only to list elements and documents in SharePoint, but also to news pages.

Microsoft has talked about content approval for ECM scenarios with communication pages for a while, but until a proper UI is in place, you can get started today!

This is how.

Addendum to Chaks’ post “Deep dive into ‘Get items’ and ‘Get files’ SharePoint actions in Microsoft Flow”

Chaks recently wrote a post where he explained the difference between the two Microsoft Flow SharePoint actions Get items and Get files (properties only).

Behind the scenes they are both calling the following undocumented service which seems to wrap the regular OData call:

/_api/SP.APIHubConnector.GetListItems(listName='MyList',queryOptions=@q)?@q=''"

Good news is you can use both actions interchangeably. If you want to get the properties for a document library using the Get items action simply pick Custom value in the dropdown and enter the title or id for your document library and it works just fine (been using this already a while).

So, to me, having the Get files (properties only) action seems unnecessary, but for some users it might be easier to understand with two different actions targeted towards lists or libraries.

How to properly use the “Get Manager” Flow action with a SharePoint list

Photo by Olu Eletu at Unsplash.

This is a short one and quite easy. When you create an item in SharePoint the unique identifier for a person field is the claim, while the Get Manager action takes a UPN (user prinipcal name).

For Office 365 they are almost equal. The claim is actually the UPN + a claim prefix.

UPN: john@contoso.com
Claim: i:0#.f|membership|john@contoso.com

If you have a flow triggering on a SharePoint list, you would enter the following expression for the UPN field to strip off the prefix from the claim.

replace(triggerBody()?['Editor']?['Claims'],'i:0#.f|membership|','')

Sure you can use the e-mail address which usually match the UPN, but you would be surprised how often multiple accounts have the same e-mail address - admin accounts, test accounts etc. So using a unique identifier is always a better approach compared to the e-mail address.

Appending field values into a string in Microsoft Flow

Photo by Hans-Peter Gauster on Unsplash

I’m working on implementing a Flow which triggers on a SharePoint list. This list has a managed metadata column where you can select multiple terms. In my Flow I want to append the terms into a single string which I’m persisting on my Microsoft Graph schema extension techmikael_GenericSchema.

The approach I’ll outline does not only apply to taxonomy fields, but for any input which has an array of objects. Below is a sample object array.

[
  {
    "TermGuid": "74c34307-80e8-4e21-a63b-81337e369a5c",
    "WssId": 29,
    "Label": "Term A",
    "Path": null,
    "Value": "Term A|74c34307-80e8-4e21-a63b-81337e369a5c"
  },
  {
    "TermGuid": "db79ec09-34ad-4c60-8f4c-d41248ee09ac",
    "WssId": 450,
    "Label": "Term B",
    "Path": null,
    "Value": "Term B|db79ec09-34ad-4c60-8f4c-d41248ee09ac"
  }
]

The output should pick the Value property and join them together with a semicolon like this:

Term A|74c34307-80e8-4e21-a63b-81337e369a5c;Term B|db79ec09-34ad-4c60-8f4c-d41248ee09ac

How to architect long running flows which exceed the 30 day timeout limit in Microsoft Flow

Photo by Alex Blăjan on Unsplash

Microsoft Flow has a built in timeout of 30 days for any running Flow (Logic Apps has 90 days), which for most scenarios is not a problem.

However, there are business processes that might run longer than 30 days, and I’ll address two common scenarios and how to overcome them.

See https://docs.microsoft.com/en-us/flow/limits-and-config for details on Flow limit and see https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-limits-and-config for limits on Logic Apps.

Scenario 1: Any single action will never last 30 days, but the total Flow might

Let’s imagine you have 5 consecutive actions in your flow, where there is no chance that any of them will run for more than 30 days. For example 5 consecutive approval steps. The way to work around this is to create one flow per approval, and then have them call each other as they go along.

To illustrate the steps I have created two flows. One named “Flow – Initial” and the other “Flow – 2”.

I’ll start with the second flow, as this will be called from the first.

Tip for making a Flow easier to read and author

This tip is if you have one logical path in your flow, and also have an “if” statement somewhere. If you are running if/else branches of actions, it won’t help you much.

The following flow has two conditions. If something A, then tweet, and if also something B, tweet some more.

I however find it quickly messy to write a lot of steps inside the “Yes” branches. Instead you can author the same flow with and empty “Yes” branch, and terminate in each “No” branch.

If you then rename your conditions to something useful and collapse them, the flow is much easier to read and author in my opinion.

Conditional approval in Microsoft Flow

I’m working on self-service solution in Office 365 where a requirement is that your manager has to approve your request. If however you don’t have a manager, then the approval step should be skipped.

Flow has an action for retrieving a users manager, so that part is easy. However, if the user does not have a manager, the Flow action will fail. The solution here is to add a parallel branch below the Get manager action. In one path you set the action to run if the previous action failed, in the other if the previous action was successful, like the image below.

Using Flow to promote better document sharing and collaboration in your organization

During lunch today I mentioned a customer sending me a document attachment in an e-mail, instead of what clearly should have been a sharing link to the file.

Outlook has excellent capabilities for sending sharing links instead of attachments, and especially internally in organization this should be the preferred approach to avoid e-mail bloat and multiple versions of the truth. Forcing people to change is not easy, but the conversation let to the following Flow urging your colleagues to do the right thing :)

Blocking vs. non-blocking Flows

Microsoft Flow has many triggers and one of the most useful ones is the HTTP request trigger, where an external party can call a specified endpoint with a message which will trigger the workflow. Basically this feature has two modes, one where the workflow executes logic and returns the outcome and the other where it does not need to return the outcome.

If you have an application which is translating text and you want the text back to the application you can create a Flow similar to the one below. A request which takes a string as input, the text is then translated to Norwegian, and returned at the end.

When running a REST query against the Flow URL using for example PowerShell we get the expected result back.

> $json = '{"thetext":"This is a test"}'
> Invoke-RestMethod -Method Post -Uri $uri -Body $json -ContentType "application/json"
dette er en test

This above operation is a blocking one. If you however want the translated text to be sent out as an e-mail, you remove the Response action and add an e-mail action.

When you now call the Flow URL you will immediately get a 200 success back, while the workflow executes the steps you have added. A non-blocking workflow.

Summary

If you want to use Microsoft Flow as an API in your application with input and output you can include both a Request and Response step. The calling application will then wait until a response is returned (or it times out). If you however want to use Microsoft Flow to execute an fire and forget action, omit the Response step, and the workflow will start executing while your calling application immediately can continue, regardless of what happens in the workflow.

Maybe the most useful Azure function ever! – Introducing a proper Swagger definition generator

This post relates to Azure functions written in C#, hosted as a Function App – and maybe the title is a tiny bit clickbaity ;)

I’m in a project where writing small Azure functions to accomplish pieces of functionality is a very good fit, and the tasks will be connected in a workflow – Microsoft Flow or Logic Apps. With the latest update for Visual Studio 2017, creating an Azure Function project and publish the function to Azure is super easy.

The tricky part comes when you want to consume those functions somewhere else using a Swagger definition file to describe your API.

The people over at the Azure team has been kind enough to add functionality to automatically generate a Swagger definition. The problem is that the output of this preview functionality is, to put it in nice terms, the equivalent to a table of contents, where the book was left out.



There are some blog posts out there on how you can write that book to get a working definition, but manual work when you have already defined the functions pretty well in code is not my cup of tea.

Digression

If an Azure function project had been a WebAPI or similar, you could have installed Swashbuckle, and you would have gotten a nice Swagger definition just like that. The fact that Azure functions are compiled to a class DLL, and that Swashbuckle does not work against a DLL in any easy fashion, I saw two options. A shadow API with Swashbuckle, or roll my own.

I started out with the first option where I created a shadow WebAPI project, copying all my Azure Function signatures, and then manually copying out parts to generate a proper Swagger definition. But I quickly discovered this was still too much manual work for my taste.

Option two it is – generate the mofo myself!

That left me with option two, write my own Swagger generator. The Swagger spec itself is not too complicated, and as Azure uses v2, that’s what I set to use as well. I’m no stranger to reflection on .Net DLL’s, having worked with SharePoint for many years, as well as writing other types of generators, so that’s what I did.

I created an Azure function in my project which at run time reflects on the current assembly, finds all methods marked to be Azure functions, then inspect their ins and outs, and construct a full fledged Swagger definition.

It’s not complicated, but a bit tedious to support all the scenarios I wanted to support. I wanted to support input via the path, as query parameters and JSON objects in the body – which is the most useful one in my opinion. It took me one working day, 7.5h to have this up and ready to go, with ~400 lines of code. Imagine if the Azure team could have spend the same? But then again, I wouldn’t have this blog post :)

Microsoft Flow, the lazy coder’s alternative to SharePoint web hooks

SharePoint web hooks has made it out from preview and into general availability, and is a great way for applications to act on changes to items in SharePoint. Think workflows where you want to run custom business logic when someone creates or edits an item. For the old-timers a web hook is just a new type of event receiver on the created/updated/deleted events.

The good thing about web hooks is that you can tack them on using either an Microsoft Azure Active Directory application or a SharePoint add-in, using application credentials. This of course is the proper way to do it, so if you are coder-proper, then stop reading now.

So why do it the lazy way using Microsoft Flow?

If you go the route of creating a web hook programmatically you have some plumbing to do up front:

• Get an administrator to register your AAD app or SharePoint add-in
• Write code to subscribe the web hook to events on the list/library
• Write code to re-new the web hook subscription once it expires (max 6 months)
• Write code to fetch the data of the item which triggered the event

The lazy approach is somewhat a smoother ride, and is what I used at a recent hackathon to get things working fast. The drawback is that Microsoft Flow runs in user context, so you only get events on items you or the account you used to authorize a particular connection have access to – but this might work our just fine for many scenarios. Using a service account is one possibility.

If all you want is access to the data of a created/modified item and want to pass it to a custom API, then using Microsoft Flow makes it very easy. One trigger action which return data for all item fields, and one HTTP action (with swagger if you fancy that) to your custom API with a payload of your choice and you’re set. You can focus purely on the API logic and let Microsoft Flow handle the eventing for you. If you want to handle both created and modified items you need to create two flows.



I'll be fair and say that Microsoft Flow currently does not handle everything and come with some caveats.

• Currently no support for updating taxonomy field
• Currently no support for updating lookup fields
• Currently no support for updating choice fields
• Currently no support for updating people fields
• Updated items will have “you” or the account used in the connection to SharePoint as the last modified user
• Updating a list with more than 12 lookup/taxonomy columns will report as failed, even though they work

As you can see, the weak points for now are on updating items, not getting the values of the item itself - so happy flowing!