How to provision SharePoint list and resources with only standard Microsoft Flow using ExecuteSiteScriptAction

I wanted to blog about an interesting technique I was testing - how to call ExecuteSiteScriptAction from Microsoft Flow - and using that to provision SharePoint site.

We’ll do this all with Microsoft Flow and it is all part of the Flow / Office-Seeded license so there’s no extra cost.

Steps

  • YouTube: How to create custom SharePoint list in one action using ExecuteSiteScriptAction and Flow

  • Documentation links for Site Design and Scripting

  • ExecuteSiteScriptAction seems to be something new allowing us to directly execute site script without saving it as a site script first

  • Future ideas

I did a recording of this on YouTube last week, this blog post will cover the steps and goes a bit deeper into the technical details.

Documentation links for Site Design and Scripting

  • https://docs.microsoft.com/en-us/sharepoint/dev/declarative-customization/site-design-json-schema

  • https://docs.microsoft.com/en-us/sharepoint/dev/declarative-customization/get-started-create-site-design

ExecuteSiteScriptAction

ExecuteSiteScriptAction is a REST command available on the API, although doesn’t seem to be mentioned in the REST documentation (yet)

  • https://docs.microsoft.com/en-us/sharepoint/dev/declarative-customization/site-design-rest-api#rest-commands

I actually found out about this from reverse engineering the new SharePoint “Create List from Excel Spreadsheet” feature. I was reading how it was done in JavaScript, and came across this end point.

I did a search for ExecuteSiteScriptAction and finds a reference in PnPJS.

  • https://pnp.github.io/pnpjs/sp/site-scripts/#execute-site-script-action

  • https://github.com/pnp/pnpjs/issues/1096


What does this all mean?

ExecuteSiteScriptAction allows us to execute site script directly, without first saving it as a site script and then execute the site script.

So it’s ideal to provision a complex SharePoint resource.

Previously, I do this either via a series of REST calls, or use REST with $batch or call Azure Functions, but all those methods are more complex. Using Site Script is a much easier way to quickly ask SharePoint to provision the resource on the server side, without multiple trips of communicating with the server.

To do this in Flow (watch the video):

Use this in the first compose - create a JSON of the site script to createSPList with several subactions.

{
  "verb": "createSPList",
  "listName": "Customer_Tracking",
  "templateType": 100,
  "subactions": [
    {
      "verb": "setTitle",
      "title": "Customer Tracking"
    },
    {
      "verb": "setDescription",
      "description": "List of Customers and Orders"
    },
    {
      "verb": "addSPField",
      "fieldType": "Text",
      "displayName": "Customer Name",
      "isRequired": false,
      "id": "c532fcb9-cdb3-45c6-8247-c784dcd58e1a",
      "internalName": "customer_name",
      "addToDefaultView": true
    },
    {
      "verb": "addSPField",
      "fieldType": "Text",
      "displayName": "Customer Name 2",
      "isRequired": false,
      "id": "c532fcb9-cdb3-45c6-8247-c784dcd58e1b",
      "internalName": "customer_two",
      "addToDefaultView": true
    },
    {
      "verb": "addSPFieldXml",
      "schemaXml": "<Field ID=\"{c532fcb9-cdb3-45c6-8247-c784dcd58e1c}\" Type=\"Choice\" DisplayName=\"Customer Category\" Required=\"FALSE\" Format=\"Dropdown\" StaticName=\"customer_category\" Name=\"customer_category\"><Default>Operations</Default><CHOICES><CHOICE>Operations</CHOICE><CHOICE>IT</CHOICE><CHOICE>Legal</CHOICE><CHOICE>Engineering</CHOICE></CHOICES></Field>"
    },
    {
      "verb": "addSPField",
      "fieldType": "Text",
      "displayName": "Text Field",
      "isRequired": false,
      "addToDefaultView": true
    },
    {
      "verb": "addSPField",
      "fieldType": "Number",
      "displayName": "Number Field",
      "internalName": "ElectricSlide",
      "addToDefaultView": true,
      "isRequired": true
    }
  ]
}


Then create a second JSON

{
  "actionDefinition": "@{string(outputs('createSPList-definition'))}"
}

Finally, send that to SharePoint via REST

// _api/Microsoft.Sharepoint.Utilities.WebTemplateExtensions.SiteScriptUtility.ExecuteSiteScriptAction()


{
  "accept": "application/json; odata.metadata=minimal",
  "content-type": "application/json;charset=utf-8"
}

That’s it - all the actions are standard, and doesn’t require calling out to a webservice.


Future ideas / Homework

  1. Imagine Flows now can easily call this to create needed SharePoint list if it doesn’t exist.

  2. Or to upgrade SharePoint lists across many sites (use variable for site url).

  3. A new PowerApps can call an accompanied Flow to create the list that it needs.

  4. We can also use many of the other features within Site Script to modify permissions, set theme and colours etc.

  5. We can even use AddSPFieldXML to add complex fields via XML definition.

  6. As a final thought - I think the Site Script definition is a much easier way to define provisioning steps, since it’s really designed to be low code.

  7. Being able to use one technique (Site Script) to provision assets during:

    • Create Sites using out of box experience

    • Invoke with Power Automate (Flow)

    • And we can also invoke Site Script from SPFx in JavaScript through PnPJS

    • This kind of shared skill re-use, and with Microsoft extending site script makes this a great technique to learn and be familiar with.

  8. Daniel Laskewitz reached out and told me that we can add the new SharePoint REST API for creating new sites to completely automate creating new sites as well as provisioning the scripts all using Power Automate. Here’s the doc link he sent me. Thank you Daniel!

    https://docs.microsoft.com/en-us/sharepoint/dev/apis/site-creation-rest





ApolloServer, AzureFunctions and local debugging

I wanted to jog down some notes that’ll help with local debugging of Apollo Server with Azure Functions.

Firstly, due to changes to Azure API routing - specifically x-ms-privatelink-id having strange invalid characters - we need to expand the function handler and blank out the x-ms-privatelink-id property.

https://github.com/Azure/azure-functions-host/issues/6013

Now to get local debug happening - we must configure CORS.

Add the cors settings - origin can be ‘true’ for every url, or ‘http://localhost:4200’ if only for your local build.

Additionally, copy the access-control-request-headers to Access-Control-Request-Headers because ApolloServer applyMiddleWare is case sensitive.

https://github.com/apollographql/apollo-server/issues/4178

const graphqlHandler = server.createHandler({
    cors:{
        origin: true,
        credentials: true,
    }
});
export default (context: Context, req: HttpRequest) => {
    // https://github.com/Azure/azure-functions-host/issues/6013
    req.headers['x-ms-privatelink-id'] = '';
    // apollo-server only reads this specific string
    req.headers['Access-Control-Request-Headers'] = req.headers['Access-Control-Request-Headers'] || req.headers['access-control-request-headers'];
    return graphqlHandler(context, req);
}

These changes by itself isn’t enough, we also need to make sure the Azure Functions runtime is forwarding the options method correctly to our Apollo Server. Make sure ‘methods’ contains ‘options’ otherwise the Azure Functions local runtime will not accept the browser pre-flight request.

(this second one was the one that got me for a while - why wasn’t Apollo Server options being called?!)

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": [
        "get",
        "post",
        "options"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "$return"
    }
  ],
  "scriptFile": "../dist/graphql/index.js"
}

Where to find John presenting in May 2020

We are living right now in a strange time. At home, and virtual events are replacing the traditional physical events.

I’ve agreed to several events and will be presenting all new (or freshly updated) topics for 2020. So while we remain physically distant, if you wanted to see one of my presentations - I’m actually a lot more visible.

May 01 - DC Power Apps & Power Automate usergroup - Why and How to implement Governance of the Power Platform

May 06 - Sydney Serverless meetup - Power Automate - Microsoft’s insane low-code serverless platform

May 11 - M365 May - Deep dive into Approvals in SharePoint and Teams with Power Automate

May 11 - USYD Cloud Society Azure/Power Up! - Intro Power Apps and Power Automate

May 15 - Sydney Power Apps and Flow usergroup - What’s new in Power Virtual Agents with Charles Sterling

May 16 - D365 Automation Saturday - Flow JAM Stack - how to build a complete low-code public website in 40 minutes

May 25 - UNSW Cloud Society - Azure/Power Up! - Intro Power Apps and Power Automate

May 26 - M365 May - Why and How to implement Governance of the Power Platform

May 27-28 - M365 Virtual Marathon - 5 Design Keys to make Flows run insanely fast

May 27-28 - M365 Virtual Marathon - Flow JAM Stack - how to build a complete low-code public website backed by M365

I’m still working on my YouTube series: How to build a public website with a Flow JAM Stack

Because of the events next week, I couldn’t work on an episode this week. But next Saturday’s Flow JAM Stack talk during the Automation Saturday will be a 40 minutes compressed teaser. Hope to catch you at one or many of these upcoming events.

Flow JAM Stack Episode 1 - sending data back with Flow as API

In this follow on episde, we dive a fair way in to see how we can customize Flow’s Request trigger to build a web service (API endpoint) that can be called from our static website.

Episode 1

  • Create a Flow service

  • Configure the form input params

  • Configure the service return HTML Redirect

  • Talk about embedding HTML FORM in static sites, but also hosted site scenarios - SharePoint, Power Apps Portal Apps, WordPress, SquareSpace.

We are deliberately going slowly going through some pitfalls and errors that you may see along the way, so the episode is progressing slowly, but I hope that’s the right direction to do this - we make sure there’s a firm foundation before moving to the next step.

I had initially hoped to get into API management, but it looks like that’ll be in a future episode.

In this episode, we extend the application with a HTML Form that will send messages back to Flow, which we then store into our backend datasource. If you hav...


Building modern public sites (JAM Stack) with Microsoft Flow

Web technologies evolve, and we are on the edge of a new stack, it is called JAMStack.

  • Javascript

  • API

  • Markup

In the world of JAM Stack, we create serverless public sites by hosting them directly from a CDN.

Now there are plenty of frameworks that will move to help developers to create this type of applications right now and next.

What I’m writing about is how citizen developers can take advantage of the same pattern to build public websites

Episode 0

  • Define JAM Stack

  • Set up data source (SharePoint)

  • Set up API (Flow)

  • Set up Storage (Azure Storage)

  • Set up CDN (Cloud Flare)

  • Set up dynamic trigger


Whether you are a Professional Developer or a Citizen Developer - you need to understand the basics of this stack. This will save you a LOT of money.

How we can use Microsoft Flow (Power Automate) to build public websites. This is a how-to video that involves defining the JAM Stack, Microsoft Flow, Azure B...