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.
