Crash Course: HTTP to SharePoint in Power Automate

Today we are taking a crash course in the HTTP to SharePoint action in Power Automate.  There's a lot we could talk about to get you up to speed, but at the end of the day you just really need to know how to do the thing.  I've provided super quick explanations, but most importantly I've given you screenshots to use as a reference guide when getting started.

For a condensed, 30 minute overview in video format, check out my session from the Microsoft Power Platform Online Conference 2020!  Don't miss the bonus tips at the end!

HTTP GET

The GET method retrieves items from SharePoint and can be used with or without a specific ID.  Without an ID you'll return all items; with an ID, you'll return only that specific item.

GET All Items

GET Single Item

HTTP POST

The POST method sends data to SharePoint to create an item.  Send metadata to SharePoint using the Body section.  No need to supply values for all fields in the list; just create the item with required metadata.

HTTP PATCH

The PATCH method sends data to SharePoint to update an item.  This method is tricky, and there are a few extras you need to supply:

• Specify the item to update by adding the ID to the end of your URI 
• Add the IF-MATCH header with an asterisk (*) to represent an e-tag

As with the POST method, you don't need to supply values for all fields, just the ones you'd like to update.

HTTP DELETE

The DELETE method does exactly that!  Remember, this is permanent and deletion should only be done programmatically when necessary for a business process.

Don't test using production data! 

If you want additional explanations and some fun examples, here are links to the SharePoint & HTTP videos I've made with Jon Levesque:

• GET
• POST
• PATCH
• DELETE (Forthcoming)

Read More

5 FAQ: Environments & The Power Platform

I recently spoke to a new client about Power Automate, and as I ran through the list of considerations --licensing, self-service purchasing, administration-- I realized that I hadn't provided enough information about environments to really help drive their understanding.  Here was a client that already had a process in place for developing new solutions and responsive tiered help desk support, but they were awash in questions and concerns about how to balance support for creative business users with IT best practices.  Today I want to answer some common questions about environments to bring everyone up to speed.

What is an environment?

At its very basic, an environment is a container for developing and testing in the Power Platform.  Flows, apps, solutions, etc. are environment-specific, though they can be exported from one environment and imported into another so they can be shared with additional users as they move from development to production.  CDS databases are also environment-specific, which helps to separate test data from production data.

Environments in the Power Platform add an important level to the development life cycle, bringing low-code/no-code solutions created by makers and citizen developers into the IT fold in a comfortable and sustainable way.  Along with DLP Policies and administration practices, properly used environments provide a sandbox for development and creativity while maintaining the integrity of production-ready solutions.  

Which environment am I in?

Every tenant comes with a "default" environment.  Everyone has access to the default environment, but other environments can be created for one or more users, effectively creating "development" and "UAT" environments as needed.  Users can only enter environments to which they have been granted access.

The environment for the current logged in user is indicated in the suite bar:

To switch environments, click the current environment name and choose another from the list:

Who can create new environments?

This is actually a tricky question because, by default, a user's license determines whether or not he or she can create an environment.  Before the panic sets in (!!), note that the majority of Office 365 licensed tenant users will not qualify for this.  Only Global (Tenant) administrators and CDS Service administrators can create environments regardless of license, and these folks can restrict environment creation to specific users.  This can be done either in the Power Platform Admin Center or via PowerShell.  For more information about licenses that do allow environment creation, review the current documentation.

How do I create new environments?

To create a new environment, go to the Power Platform Admin Center.  On the left rail, click Environments, then click New.

A pane will appear on the right with a form for the new environment.

There are some other things to consider, such as what type of environment this will be and whether or not a CDS database is required. We won't go into those here, but one major caveat is that every environment--with or without a database-- requires 1GB of available capacity.  To check your current capacity, visit the Capacity page in the Power Platform Admin Center.

OK, I buy it...How Many Environments Do I Need?

Well, it depends.  Since all users have access to the default environment, that's really not the best place to develop and test enterprise critical applications.  Best practices suggest that the default environment is really for personal automation and applications appropriate for small team use.  Examples of these are:

• A flow that notifies me when an email arrives in a shared inbox
• A Power App and associated flow for managing vacation requests/approvals within a small team

If capacity isn't a concern, creating 3 dedicated environments provides the most stable experience for your enterprise applications.  This means 1 development environment, 1 UAT environment, and 1 production environment.  Applications move from development to production in a straight line, and requested changes/updates are made in development, tested by users in UAT, and then deployed to production.  

This will feel very familiar to developers and testers who have been involved in traditional application development.  If this article helped and you're interested in more, you can find additional information on governance and best practices in the updated Power Apps and Power Automate Admin whitepaper.




Photo by CHU TAI on Unsplash

Read More

Getting Started with Child flows in Power Automate

Child flows are new to Power Automate, and although the concept is simple, getting started is a little tricky.  I'll walk you through setting up parent/child flows within a solution and how to move data between the two.

Use a Solution

The first roadblock you might run into is that Child flows must be used inside Solutions.  What is a solution, you say? Well first, you'll find them on the left rail in Power Automate.  Second, solutions are a great way to package up one or more flows for deploying to a production environment.  This means that you don't have to export and import individual flows one at a time; instead, you export and import one solution package. (Want more?  Here's the Microsoft Walkthrough!)

To create a solution, click Solutions and then click + New solution.  Fill out the new solution form in the right rail and click Create.  

The flows

Your instinct might be to create the parent flow first, and that's fine if you have some logic you know you need to implement there first.  However, you cannot add the Run Child Flow action and save your flow without an existing child flow to point to.  For our purposes here let's create the child flow first.  Click the + New drop down in the top toolbar and select Flow.

The trigger for the child flow can be a manual button, but I prefer to use HTTP actions for my trigger and for my response.  I find this to be more flexible, and frankly, this is my comfort zone!  

Let's also add the Get items SharePoint action so that we have some data to send back to the parent flow.  I'm going to limit the count to the first item for the sake of simplicity.  

Now let's add the HTTP Response action as the last part of our child flow.  Here, set the Status Code to 200 to indicate a successful response.  In the Body of the response, add the Body from the previous Get items action.  This will serve the SharePoint items back to the parent flow, making them available for us to use.  Here's our simple child flow in its entirety: 

Make sure you rename your flow and save it.  Now let's work on the parent flow!  

Navigate back to the solution you created.  You may notice that multiple tabs open as you work on flows within a solution.  It's alright to close the extra tabs, but just know that your solution view will be updated with your changes after you save them and click the "done" button in the dialog that pops up.  

Add a new flow from the top toolbar as before.  I'm using a recurrence trigger here, but you can also use a manual trigger.  Add the Run a Child Flow action next, and choose your child flow from the drop-down.  You'll notice that the only choices available are flows within the current solution.  

We aren't finished, but this is a good spot to save the parent flow and do a test run.  What we want is the body of the response coming from the child flow because we are going to use that in a Parse JSON action next.  After your successful test run, go to the child flow inside your solution and click into the most recent run instance.  From there, copy the Body from the Response action.

Navigate back to your parent flow.  Add the Parse JSON action, with the Content being the Body from the Run a Child Flow action.  Click on use a sample payload to generate schema and paste in the response body from the child flow:

Next, let's send an email with some of the information from the child flow.  Add the Office 365 Outlook Send an email action.  For the subject, search within the Dynamic content window for Title.  Add the Title column from the previous Parse JSON action.  Notice that Power Automate will add an Apply to each container for you since it does not know how many items have been returned from the response body, only what columns and data types are being returned.

Save your flow and run a test.  You should receive an email--or emails!-- based on the Get Items action buried in the child flow.  There are a lot of possibilities here, and I'm looking forward to seeing what interesting solutions are out there!



Photo by Sergey Pesterev on Unsplash

Read More

Tools for Newbies: PowerShell

New to SharePoint?  Finding yourself a little overwhelmed?  This is the first in a series of posts about the most useful tools for both SharePoint developers and admins. Whether you're completely new to the game or you've been in it since the beginning, these skills are invaluable.  I'll guide you through getting set up and point you toward resources that I find extremely helpful.

Today's Tool: PowerShell

Too on the nose?

I use PowerShell weekly, sometimes daily depending on what's on my plate.  This is one of those skills that is necessary for both developers and admins to know, and definitely useful for power users to understand.  Even if you're not allowed to run PowerShell at your job--maybe you're a site owner without SharePoint Admin permissions-- it's essential to know what is possible so that you can streamline your requests with IT.

There are so many PowerShell modules available that it can seem a bit overwhelming.  For our purposes, let's focus on the basics of using PowerShell against SharePoint Online.  For this you'll need a special version of the PowerShell console called SharePoint Online Management Shell  (download here!).  Management Shell comes loaded with all the modules you'll need to work with SharePoint Online.

Once you have that installed, go ahead and start up an instance of Management Shell by choosing it from your list of programs.  You'll notice that when it opens it points to a default destination.  If we were going to run a script stored on the file system we would change it, but for now this is fine.

The nuts and bolts

Everything we do in PowerShell starts with what are called cmdlets (pronounced: "Command-lets").  Cmdlets are the building blocks of PowerShell scripts, and each one refers to specific functionality and may take various parameters.  Examples of SharePoint Online cmdlets are:

• Get-SPOSite
• Add-SPOSiteDesign
• Invoke-SPOSiteSwap

When it comes to SharePoint Online, the first cmdlet we need to use is Connect-SPOService.  This is the gate we need to pass through every time we want to work with SPO, and we pass in the SharePoint admin URL as a parameter.

Inside the Management Shell console, type in the cmdlet and your URL as below and press Enter.  When prompted, login using SharePoint Online Administrator credentials.  

Once connected, the SharePoint world is your oyster!  For instance, we can use the Get-SPOSite cmdlet without any parameters to return all the site collections in the tenant.  

To return a specific site, use the -Identity parameter and provide the URL of the site.  To return more information about the site, use the -detailed parameter.

There are cmdlets available for many basic processes, and PowerShell allows you to handle batch and routine processes quickly and easily.  Now that you've gotten your feet wet, go forth and script!  For the full reference, review the Microsoft Documentation.






Header Photo by Jo Szczepanska on Unsplash

Body Photo by Aaron Burden on Unsplash

Read More

Documents Sets with REST and Power Automate

With all the functionality available in Power Automate (Microsoft Flow) now, it's a wonder there is no native support for working directly with SharePoint Document Sets.  In this post, I review what Document Sets are, why you should be using them, and how to interact with them using REST and flows.

Update: This post has been updated to reflect best practices regarding the use of odata=nometadata in a production setting.

Why Document Sets?

Document Sets are a super-set of the folder content type in SharePoint.  They are a big part of Classic SharePoint and have recently been integrated into the modern experience in SharePoint and Office365.  Here's some of the functionality you get with Document Sets:

• Metadata at the "Folder" level in Document Libraries
• Unique Permissions at the Document Set level
• Versioning the set, including the files inside 
• Support for file templates

Your business users might already be using these, or they might be using folders and asking why metadata can't be placed on folders in libraries.  Document Sets are extremely useful for organizing content such as legal portfolios, customer documents, and contracts.

The Use Case

I set out to understand how to work with Document Sets and Power Automate when I received a request to create an approval and document repository solution for a client's legal department.  There was a clear need to store contracts inside Document Sets, but there was no desire to manually create and manage those Sets.

The Setup

For this solution I highly recommend setting up a site content type for your Document Set.  This will make it easier to work with and identify exactly which metadata will be included with your new Set.  If you need help getting started with content types, please review the Microsoft documentation.

You'll also need to decide how you are going to manage the request for Document Set creation.  I opted for a request list with an approval process.  

Once the request has been approved we can get to the good stuff!

GET the Content Type ID

The first thing we need to do is get the content type ID of the Document Set.  For this example I created a content type called Project, and I've already added it as an available content type in the Documents document library.  

In your flow, add the action HTTP to SharePoint.  Add in the site and set the Method to GET.  The Uri points to the content types in your library and filters them to find the one named Project.

Go ahead and run your flow.  Next, add a Parse JSON action and point to the body returned from the HTTP call above.  Copy the payload out of your test run and use that to generate the schema for your JSON.

Run your flow again and let's pause here to take a look at what information is coming back.  Remember, we are looking for the Content Type ID.  This is a great time to actually review the body of data returned from the HTTP GET action.  You'll see that the Content Type ID is found in a few places, but most obviously as the value for StringId.   

Initialize and set a string variable to hold the StringId.  It's nested in the body of the response, so you'll need to format your expression like this: 

first(body('Parse_JSON')?['value'])?['StringId']

POST to Create Document Set

Now let's work on the call that will actually create the Document Set.  Add another HTTP to SharePoint action, this time with a POST method.  Note that the Uri actually points to the SharePoint 2010 listdata.svc endpoint for our library.  

In addition to the expected accept application/json header, we need to add a Slug header.  Fun side note, "slug" refers to the working title of a newspaper article prior to going to print.  This use of Slug is clever because we are in fact merely suggesting what the Uri of the new Document Set will be; we are providing a working title for it.

Add in the rest of the header information formatted as above.  The first variable is the suggested title of the Document Set; the second variable is the Content Type ID we previously retrieved.

That is enough to get a new Document Set created in your library!  From here you can do many more interesting things depending on your needs, but that is for another post.

Photo by Jason Wong on Unsplash

Read More

Parallel Branches with flows in Power Automate

Parallel branches have been available in Power Automate (Microsoft Flow) for some time, but I hadn't had the opportunity yet to use them in a production build.  Let's do a super quick refresher today on how to use them.

The Use Case

I needed to implement three parallel approvals, as well as different actions that would occur after approval or rejection in each branch.  I also needed to gather the responses for one overall condition at the end.  This was part of a larger 3 stage serial approval process.

The Set Up

I suggest that you don't set up all of your approvals serially with the intent of moving them around into parallel branches.  If you have the opportunity to start fresh or you are starting from scratch that's the easiest to handle!

However, don't sweat it if you do have a flow you'd like to adjust.  We'll go over how to easily handle that at the end.

Let's do this!

First, create an approval as you would normally by adding the action wherever you need to in your flow.

Next, locate the + button above your approval to Insert a new step.  From here, select Add a parallel branch.

In branch that appears, add actions you'd like to run in parallel, such as another approval.  Go ahead and add any additional actions such as conditions and updating items.  If you want to get fancy and all a third parallel branch, be sure to click the Insert New Step button at the top of the branches and not directly above the actions in one of the branches.  This isn't extremely obvious at first.

When you're ready, let's bring the branches back together using the New Step button.  The branches automatically come together once you choose an action.  Remember, all the actions in each branch have to complete successfully before any actions outside the branches will execute.

Simple, easy, straightforward! As I mentioned, if you're reformatting an existing flow to make your serial approvals run in parallel you can't drag your existing steps next to each other to dynamically create a parallel branch.  However, you get around this by adding a branch and choosing a placeholder action such as Initialize Variable.  After you have that, just drag your approvals into the branch and delete your placeholder.


Photo by Karolien Brughmans on Unsplash

Read More

About this Blog

This has been a long time coming.  I've been thinking about starting this for probably a year...In fact, in my mind the name hasn't changed in that time.  I always knew I wanted to talk about the "in-between."  I recently got the push I needed from a friend.

This blog is about Microsoft SharePoint, the Power Platform, development, and everything in between.  I love what I do, and I'm always sneaking time between other activities to respond to a client in need or to test a new idea.  It's the time between life's major activities that we do what we really want to do.  

So for all the devs who can't wait to code when the family is in bed, and all the curious people who must look up absolutely everything on their phones while waiting for an appointment (I can't be the only one, right?) this is for us.  

Stay curious, learn something new, get comfortable with being uncomfortable.



Photo by 🇸🇮 Janko Ferlič - @specialdaddy on Unsplash

Read More