Abstract: Microsoft recently released a new page and web part model called the SharePoint Framework (SPFx). Microsoft used this new framework to build the Modern list and library user experiences that have been rolling out to SharePoint Online. As you’ll see in the session, developing for the SharePoint Framework is nothing like “traditional” SharePoint development. There’s no File | New Project in Visual Studio; instead we’ll be using tools like Node, Yeoman, Gulp and TypeScript. We’re not in Kansas anymore Toto.

The first stream covers how to setup the Azure Function App, how to configure Azure AD authentication, how to code the Azure Function in Visual Studio, and how to build the SharePoint Framework web part that consumes the Azure Function.

The second stream adds some detail that was missing in the first stream. Specifically it covers how to debug the locally executing Azure Function and updates the SharePoint Framework web part to more clearly demonstrate the use of delegated authentication.

In late July I recorded an interview with Paul Schaeflein on the topic for the Microsoft 365 Developer Podcast: Azure Functions and SharePoint with Rob Windsor.

I’ve also been working on a three-part blog series on how to get started building Azure functions that interact with SharePoint using the Client Object Model over on the PAIT Group blog.

Part 1 – Registering an application with Azure Active Directory
Part 2 – Developing Azure Functions in Visual Studio
Part 3 – Creating an Deploying an Azure Function App (Coming soon)

I plan to do additional content on this topic in the future so look out for additional blog posts, YouTube videos, and conference talks.

July 16: The Inspire session where the licensing changes were first announced: Microsoft Power Platform business model and licensing updates.

July 25: A post on the PowerApps blog from Charles Lamanna summarizing what what covered in the Inspire session: New licensing options for PowerApps and Microsoft Flow standalone paid plans.

August 29: A summary similar to the Charles’ blog post on the Microsoft licensing site: Updates to Microsoft 365, Dynamics 365, PowerApps and Flow Licensing.

August 29: A FAQ with additional information about the licensing changes: PowerApps and Microsoft Flow licensing FAQs for October 2019.

There are two things to note here: 1) the official documentation on PowerApps and Flow licensing has not been updated yet, and 2) the information contained in the above resources has evolved since July. The point I’m trying to make is that there is a chance that the licensing rules may not have reached their final state.

If you are looking for a summary of the changes you can check out my post on the PAIT Group blog: An Office 365 Users Guide to PowerApps and Flow Licensing – October 2019 Edition.

Finally I discussed this topic with Andrew Connell on episode 312 of the Microsoft Cloud Show: Inspire Tidbits and Big Cloud Wins.

If you are not familiar with Scopes, their main purpose is to act as a container for one or more actions. One of the benefits of using Scopes is that you can collapse them enabling you to get a big picture view of your flow without having to scroll all over the place. However in this case we are also using the Scopes to clearly show both the success and failure paths for the Flow.

I’ve used the pattern shown above in several of the flows I’ve built but I have always had one issue. If I was inside the Fail or Timeout Scope I knew something went wrong, but I didn’t think there was a way to determine exactly what that was. This issue bugged me so much that I kept searching until I finally found some Logic Apps documentation that discussed the @result() expression. Power Automate is built on top of Logic Apps so most things that apply to Logic Apps also apply to Flow.

The @result() expression accepts the name of a Scope as a parameter and returns a JSON array of objects that represent the results of the execution of each action within the Scope. The schema of the objects returned will vary depending on the type of action but all objects will have some common properties. The properties that are of interest in terms of error handling are: name, code and status.

The name property value is the name of the action, the code property value is a very terse description of the error, and the status property value indicates whether the action succeeded, failed, timed out, or was skipped.

Below are a couple example objects for actions that failed. You can see they both have the terse error description in the code property but they also have more detailed error information in other properties (note the error message in the second example was truncated for inclusion in this post). The issue is that the paths to the properties that contain the detailed error information are different in the two objects. It’s definitely possible to extract the detailed error information, you would just add a series of conditions that check for the existence of the different properties that could potentially hold it. However in this blog post we are going to keep things simple and just focus on how we can extract the error information that is common to all objects representing an action.

{
   "name": "Example_Action_That_Failed",
   "inputs": {
      "uri": "https://myfailedaction.azurewebsites.net",
      "method": "POST"
   },
   "outputs": {
      "statusCode": 404,
      "headers": {
         "Date": "Thu, 11 Aug 2016 03:18:18 GMT",
         "Server": "Microsoft-IIS/8.0",
         "X-Powered-By": "ASP.NET",
         "Content-Length": "68",
         "Content-Type": "application/json"
      },
      "body": {
         "code": "ResourceNotFound",
         "message": "/docs/folder-name/resource-name does not exist"
      }
   },
   "startTime": "2016-08-11T03:18:19.7755341Z",
   "endTime": "2016-08-11T03:18:20.2598835Z",
   "trackingId": "bdd82e28-ba2c-4160-a700-e3a8f1a38e22",
   "clientTrackingId": "08587307213861835591296330354",
   "code": "NotFound",
   "status": "Failed"
}

{
    "name": "Set_variable_2",
    "startTime": "2019-04-15T22:12:02.1199356Z",
    "endTime": "2019-04-15T22:12:02.1199356Z",
    "trackingId": "7fdf54a0-ab29-4087-affd-319864513ed9",
    "clientTrackingId": "08586462405637382345452520112CU22",
    "clientKeywords": [
        "testFlow"
    ],
    "code": "BadRequest",
    "status": "Failed",
    "error": {
        "code": "InvalidTemplate",
        "message": "Unable to process template language expressions ..."
    }
}

We’ll start by adding an Initialize variable action above the Main Scope. This action will initialize a String variable named ErrorDetails to an empty string.

Then inside the Fail or Timeout Scope, add a Filter array action. We will use this action to get the details of the actions inside the Main Scope that either failed or timed out. To do this we’ll set the the From property value (marked as 1 in the screen capture) to the expression result(‘Main’), we’ll set the left-hand side of the filter condition (marked as 2 in the screen capture) to the expression: createArray(‘Failed’, ‘TimedOut’), and we’ll set the right-hand side of the filter condition (marked as 3 in the screen capture) to the expression item()[‘status’].

Add an Apply to each action below the Filter array action. This action should iterate over the output of the Filter array action. In most cases the output array will only contain a single object but it is possible that it could contain multiple objects.

Add an Append to string variable action inside the Apply to each action. Will use this action to append the the error information for the current result to the ErrorDetails string variable. The expression marked as 1 injects the value of the name property: items(‘Apply_to_each_result’)[‘name’]. The expression marked as 2 injects the value of the status property: items(‘Apply_to_each_result’)[‘status’]. The expression marked as 3 injects the value of the code property: items(‘Apply_to_each_result’)[‘code’].

Add a Send an email action below the Apply to each action. We’ll use this action to notify one or more users that the Flow failed or timed out. Set the To property to the user(s) you wish to notify, set the Subject property to something appropriate for your situation, and set the Importance property to High.

In the Body, start by adding the ErrorDetails variable value. Then we’ll add a link that the Flow owners can click to see the run history for the Flow. I got the expression to build the link from the Try, Catch and Finally Flow template: concat(‘https://flow.microsoft.com/manage/environments/’,
workflow()?[‘tags’][‘environmentName’], ‘/flows/’,workflow()?[‘name’], ‘/runs/’,
workflow()?[‘run’][‘name’]).

We are now ready to test the flow. To do this I am going to add an action to the Main Scope that I know will fail. I am going to add a Get item action where I’ll attempt to get an item that does not exist from a SharePoint list.

The example flow I’m using for this blog post has a manual trigger so I can test by clicking the Test button at the top-right of the Flow designer.

Looking at the flow run history you’ll see that the Get item action failed which took us into the Fail or Timeout scope where all the actions ran successfully.

Checking the email for the Rob Windsor account we find the email message generated by the Send an email action.

Being able to notify a user that a flow failed or timed out has value but being able to provide detail about what action(s) failed or timed out takes that value to the next level.

I did some Googling and I found several posts that showed how to register an add-in, make app-only permissions requests for the add-in, trust the add-in, and then use the HTTP action in Flow to get the bearer (access) token using the add-in Client ID and Secret so you could then use the HTTP action to make the REST API call. I followed the steps described in the posts and was able to make the REST API call to move the list item. This is one example of the posts to which I’m referring: How to Call the SharePoint REST Webservice from Microsoft Flow.

A short time later I was looking for something else when I noticed the ‘Send an HTTP request to SharePoint’ action. This action could have been named ‘Make a SharePoint REST API Call’ because that is exactly what it enables you to do – without having to go through all the setup described above.

In the example below I’m using the ‘Send an HTTP request to SharePoint’ action to execute a CAML query. Note that I am not passing the form digest in the headers. This is not required from what I’ve seen so far.