Speaking and Hackathon at Digital Workplace Conference Australia - Melbourne


In a little less than a month on August 15-16, I'll be presenting in Melbourne at the Digital Workplace Conference Australia 2018.  


(I still fondly remember this conference as the previously annual Australian SharePoint Conference - but all things evolve.  SharePoint to SharePoint Online to Office 365, and the workplace evolved from portals to intranet to social platforms to conversational platforms).

Flow and Functions: level up our Serverless Toolkit in Office 365

I will be presenting an amped up talk covering the implementation and automation with Microsoft Flow and Azure Functions.  This is one of several sessions on Microsoft Flow at this conference so I will be covering implementation and mastery at level 200+  (But because it's Flow, it'll still look deceivingly simple!)

John join forces with Paul Culmsee and Ashlee at #DWCAU pre-conf hackathon

I want to also mention that I'm helping out with Paul Culmsee and Ashlee's PowerApps and Flow Workshop/Hackathon on 14 August 2018


I personally don't know how much PowerApps and Flow raw potential would be in that room in the hackathon.  I really want to find out and I hope you would too.  Space for this is limited - please consider this one day pre-conference workshop.

"Learn PowerApps and Flow from experts and build an app that you need." says John.

"Two MVPs for the price of one" says Paul.  I'll just leave this here.

Whether at the conference, and/or the hackathon, I hope to see you there in Melbourne.

Flow For-Selected-Item trigger and SharePoint Site Pages, in a detective story

This is a long blog post, there are two parts:

  1. How do you make a SharePoint For Selected Item in Flow, and have it appear on the SharePoint Site Pages library
  2. Explain the magic rituals you just did to figure all this out

The Problem

Paul Matthews reached out and asked if it's possible to create a "For a selected item" Flow against Site Pages.  

I was able to reproduce what he's asking fairly quickly.


The Solution

May be you just want the solution.  The solution is that you need to use the "list guid" as the custom value for the SharePoint For Selected Item trigger, not the List Title.


The Detective Novella

Ah you are still here.  OK, buckle yourself in, we are going another Flow adventure.

First, when realizing that the For a Selected Item doesn't appear in Site Pages, I immediately call the SharePoint REST method SyncFlowInstances()

I do this of course, with another Flow.

This returns empty array for SynchronizationData.  This means:

SharePoint Site Pages don't know anything about my Flow.  It thinks there's no Flow connected to it.

Create an Out of Box Request sign-off Flow on Site Pages

SyncFlowInstances returns this Request sign-off Flow

So we know Flow can run on the Site Pages library, just not "Our" Flow.

I want to compare the JSON definition differences.

The Request sign-off Flow is owned by the SharePoint list, not by me.  So I can't read its definitions (I can't even see it in my list of Flows view)

So I created a Flow to assign the Request sign-off Flow to me.

This is necessary to add myself as a Owner to this Flow.

Now I open these two Flows with Flow Studio.

I can see both the working Flow (on the left) and the not-working Flow (on the right)


Checking the trigger JSON, I find that the Flow on the right (not working) has "Site Pages" as the name, but on the left (working) has a GUID as its name.


We explained the problem - it is the Site Pages not appearing as a choice - it's not a List nor a base Document Library.  Typing the name "Site Pages" doesn't work.

The solution is to use the list Guid.

And the debugging steps takes us to SyncFlowInstances, Modify FLow as Admin to assign a new template flow back to me as the owner, and finally using Flow Studio to change the existing "Site Pages" to the list guid.




Office 365 Saturday Canberra 2018 #O365CBR #SPSCBR

This Saturday - 14 July, we'll be converging on SharePoint and Office 365 Saturday Canberra.  I'm planning to take my time and drive down for the weekend.



The event is held at Microsoft office this time (so not at the previous Clifton's venue).  We will be covering a mix of Office 365, modern SharePoint, and security topics.

I'll be around all day as well - ask me anything about SharePoint, Flow, PowerApps, Office Development, Todo, Xbox and everything!

I believe we have an Xbox One and a bunch of swag to give away too!  But you are definitely coming for the wide range of content and topics, and definitely not for the swag.

We hope to see you there!


10 Things in Microsoft Flow that isn't in Azure Logic Apps

Sorry about the catchy headline.  I will start by saying I am perfectly ready to see a response post containing 20 things in Azure Logic Apps that we wish are in Microsoft Flow.  The point of this post isn't about whether one product is better than another product, it is simply to highlight the very-intentional design differences and how as users we have access to both and should make our choice accordingly.

If a comparison must be made, then I think in reality, they are better seen as two siblings - LogicApps is the big sibling with more features, Flow piggybacks LogicApps, but itself has several unique tricks and sometimes, features do move between them.  I love both teams & products.

To best describe Flow to an Azure / Logic Apps person, Flow is Logic Apps + power-user / human workflow-focused workloads, combined with a mobile experience and better in-product integration.  As a result, it caters to a whole different set of scenarios that Logic Apps isn't focused on.


1. Resource-Owned Flows

Flows can have multiple owners, but it can also have a Resource as a owner.  The best example of this is in SharePoint connector.  A Flow can be 'owned' by the List or Library resource - so if we grant a user library owner permissions - that user automatically can see and modify the Flows owned by the resource.  This is awesome because we don't need to manage two sets of user ownership sets.



2. Run-as user

Several Flow connectors has a concept of the Run-As user, that is, the user can select a resource like a document or a library, and run the Flow as the current user.

LogicApps connectors can only run as the maker.

3. Approvals

Flow implements a simple set of approvals API with both one-must-approve as well as everyone-must-approve, this is setup with Office 365's Actionable Messages, so tasks can be completed directly from email.  These are also available within the Flow Mobile app.  These approval tasks can be reassigned, and there is a history trail of them in Flow.

In LogicApps - human approvals can be built Outlook's Send Approval Email.





4. Notifications

Flow can send Mobile Notifications to the accompanying Flow mobile app.  


5. Flow Buttons

Flow has digital buttons called "Flow Buttons" these appear as quick triggers on the Flow Mobile App, but is also a really easy way to set up a run-now test trigger.


6. PowerApps Trigger

Flow has a PowerApps trigger (and response) that can send structured JSON data to and from PowerApps.  This makes it much easier to use Flow as server-side middleware to extend PowerApps (which is client-side).

LogicApps has to publish custom connector (which can then be used in Flow and PowerApps).


7. Environments

Flows are created and grouped within Environments - an environment can have unique assets grouped, as well as shared custom connectors, and data leak prevention policies.

Logic Apps are grouped within subscriptions - you either have access to the subscription or you don't.

8. Selected-Row Trigger

Selected Row is part of the product integration feature of Flow - in which, Flow can be created and ran from within other products as part of an integrated experience.

Two examples we have right now are in SharePoint and (soon) in Excel.
On the roadmap there is also Outlook integration.

This trigger is specific in that in each of these integrated experiences, you can select an existing item (in SharePoint list, in Excel row, or in an email) and start a Flow with that item as the source trigger.  Additionally, Flow can run as the current user (see #2) as part of this integration.


9. Analytics

Flow has several builtin analytics charts out of box with PowerBI.

Logic Apps has Log Analytics integration and users can build their analytics via Insights.





10. Flow Management Connector

In Flow, the Flow Management Connector is a meta-level connector that lets you perform reflection-like actions on the Flows within your current environment.  You can even use Flow to make other Flows.

Somewhere, there is an insane Flow engineer that says wouldn't it be ultra-meta to deploy Flows with Flow.

Logic App's Logic Apps connector only lets you list other Logic Apps in the current subscription and run them.  To deploy LogicApps - talk to Azure Management API to deploy ARM templates.

I use this connector quite often to move Flows around:



Think about this.  Flow can read itself.  Flow can call Azure Machine Learning.  Flow can update itself.


11. Business Process Flows

Business Process Flows replace the old Business Process workflow in Dynamic 365,  and is a way to build a "state machine" that triggers and transitions between different business process stages in Dynamics.


This integration with Dynamics platform isn't available in LogicApps.

(I included an 11th because some may be picky and say well #9 analytics isn't a special power...)

Example of a powerful Flow feature that made it's way back to LogicApps

12. Data Gateway

Flow as part of the Business Application Platform had on-premises integration through the Data Gateway functionality first - including calling on-premises SharePoint, SQL, File System and REST endpoints.

This feature was integrated back to LogicApps later as well.


I connect SharePoint to my Minecraft via the Data Gateway with a custom REST API.



Flow, Logic Apps, Azure Integration - these are a multi-headed effort to move expand in multiple directions, each under a specific product offering.

Specifically, Flow's special powers fall under these categories, some are easy - others not so easy to replicate back in Logic Apps.

  • Flow Mobile app
  • Approvals
  • App-Integrated Flow (SharePoint, Dynamics, Teams, Excel, Outlook)
  • BAP-Integration  (Environments, Data Gateway, PowerApps, PowerBI) 

In Dynamics and Office 365, because we get a generous pool of free Flow runs as part of the license, Microsoft Flow can be cheaper.  Flows cost per run.  So it encourages building long-running, multi-step Flows, suitable for human workflows.

But in my own experience - some of the Flows that I call a lot (but doesn't have too many actions), it's actually cheaper to switch those to Logic Apps.  I consider these Flows more like Middleware calls - HTTP Request, do a few actions, finish.

Also, in building Flow Studio that works across tenants - I've opted to use Logic Apps rather than use the Flow runs of a single Office 365 Tenant.

Different scenarios, for different needs.

A Thesis on the Parse JSON action in Microsoft Flow

Parse JSON can be both intelligent and dumb.  It can help you a lot and it can hinder you just as much.

This blog post, we go deep and study the behaviour of the Parse JSON action, it's various problems and solutions.

Here we tackle the question - How do you use Parse JSON, actually?


  • Getting Started with Parse JSON
  • Problem - way too many properties
  • Problem - the array - item object and auto-wrapping
  • Problem - duplicate properties names?
  • Problem - null value properties
  • Problem - missing properties
  • How to quickly fix the schema
  • Result is Parse JSON will make the Dynamic Content Panel actually intelligent

Getting Started with Parse JSON

In general, the reason we use Parse JSON is because Flow doesn't know the format of the data we are receiving in our actions.  So we always start by running the actual method once - even if the Flow has only been partially completed.  We want to get a sample of the data we'll be seeing.

Look at all these properties in the Dynamic Content Panel.  Looks amazing.  Our problems are about to happen.  Don't worry we'll fix all of them.


Problem 1 - way too many properties

The schema Parse JSON generates is very very verbose.  So there are a lot of properties that we probably just don't care.

So copy the generated JSON Schema from the Parse JSON action, and use a text editor to have a look at it.  Here I'm using VS Code - switch the editor mode to JSON.

We see it has generated type information for various _links properties, or in this example, the halfTime results or odds of a football game.  We don't need this, so we can delete it from the schema.


Problem 2 - the array - item object and auto apply-each wrapping

Notice under the fixtures (array) we have an items property with each object.  This appears under Dynamic Content Panel as "fixtures - Item"

Becareful when clicking on this property, it will immediately unfold with an For-Each block.

It depends whether this is actually what we want - typically, when we aren't in a For-Each block, this is helpful.  But if we are already inside a For-Each block this may create a second nested for-each block and be quite unnecessary and confusing.


Problem 3 - duplicate properties names?

Hey why do I see duplicate names?  How can we tell which one is which?

The simplest way to ease this problem is to delete the properties in the schema that you don't want (same as problem 1).  This will reduce the number of duplicate properties that appears.  But sometimes, we still get some duplicate names - often I see the top level object has a 'name' and the child object has another 'name'

In this case, I check with the hover over to make sure I've selected the right choice.


Problem 4 - null value properties

(This problem category also applies to all type mismatch errors)

In general, Parse JSON generates the schema based on the first object it sees from the sample.  This is not always correct - since sometimes the properties may be null in the later objects.  For example in the football games data - earlier records has scores as integers, but later records haven't been played yet so scores are null.

This error usually fails the Flow.  Another mutation of this problem is when the number is a decimal, but the schema thinks it's integer.

The easiest way to fix nullable-values is to delete the type information for this property.

Using no type information is better than changing to something like type: "object" because the Dynamic Content Panel will always show these properties.

If goalsAwayTeam was set to object, then it wouldn't be available here.


Problem 5 - missing properties

Sometimes, a later object in the array doesn't have a property at all.

The fix is simple - remove the "y" from "required"

But sometimes this is half the problem - because the expression used after this may expect the property to exist and always available.



Parse JSON will make the Dynamic Content Panel actually quite intelligent.  But it requires some clean up maintenance on the JSON schema.

It is up to each scenario to decide if there's value to fix the JSON Schema, or to skip using Parse JSON and just use item()?['property-name'] expressions directly.