Use Power Automate to create a Document Set – The easy way!

I’ve recently been working with improving some workflows which use Document Sets and stumbled into a problem. Online when you search for “Document Sets using Power Automate” you get posts such as:

Now these posts have helped a lot of people but there is one drawback to them and most of the others I can find online. They rely on the use of _vti_bin (sometimes referred to as SP 2010 REST API)

If you don’t know much about the history of VTI go check this out:

It’s pretty vintage now.

The customer I’ve been working with has a handful of SharePoint 2010 workflows we discovered using the SharePoint Modernisation Scanner and we know that these are due for deprecation any time soon. During updating the Document Set workflows and doing some testing, on my first try it broke, a combination of some long days and other weird issues we’re having on the tenant led me down some rabbit holes and a panic that maybe Microsoft also removed the _vti_bin end points too.

They haven’t - it turns out I had a bad slug but it then enabled me to make these simpler solutions, and neither rely on directly sending http requests to the vti_bin API:

Create a document set the easy way:

Yup - that’s all you need to do, find out the Document Set ID from the Document Library – and update a folder’s metadata. You’ll need to specify a manual setting in the ContentTypeId field, but that’s it!

If you’re now asking – that’s great but I want to be able to do that using all variables, well I've got you covered too:

The trigger could be anything you like, e.g. from a selected item in a SharePoint list 

  • NewDocSetName – the actual name of the new Document Set to be created
  • DocumentLibName – the title of the document library where you want the document set to be created
  • DocSetContentTypeId – You need to go into the Library Settings and open the document set content type you’ve added to the list. In the URL when you’ve opened the link to the content type you’ll find the ID, similar to this: 0x0120D5200010BEA7FB30F01740988C0050C9C11D43
  • SiteUrl – the Url of the Site/Subsite
  • Get ListItemEntityTypeFullName, you need to send a HTTP request to the list to find out what the entity type name is to be able to change the items metadata
  • This is a “Parse Json” step. I run the flow once (it’ll fail) to then get the output from the step above to use as the schema
  • Creates the folder
  • Set folder as Document Set – I've copied down the important stuff below:
    • Uri: _api/web/lists/GetByTitle('Documents')/items(@{outputs('Create_new_folder')?['body/ID']})
    • Accept: application/json;odata=verbose
    • Content-Type: application/json;odata=verbose
    • X-HTTP-Method: MERGE
    • IF-MATCH: *
    • Body: { '__metadata': { 'type': '@{body('ListItemEntityTypeFullName')?['d']?'ListItemEntityTypeFullName']}' }, 'ContentTypeId':'@{variables('DocSetContentTypeId')}'}
Hope it helps!


  1. This seemed great at first, but I noticed that it creates an empty Document Set. One major benefit of using Document Sets is that it gives you a set of template files whenever you create a new one. By creating a regular folder first and then changing its content type, you don't get the template files you've assigned to the Document Set. Any ideas how to fix that part?

    1. You are already in power automate, so you can use that to upload your files! You could store them in a management document library with the docid marked as metadata/ folders. Loop through and load them in

  2. As @Harry Grant pointed out, this doesn't actually work properly. In addition to not applying templates properly (which is minor), it also suffers from a secondary symptom in that the the document set that is created isn't 100% an actual document set. In many respects it looks like it, and quacks like it, but look a bit more carefully and it just isn't.

    It's kind of like when you try to create a document set in SharePoint 2013 workflows - which also don't work.

    You can see this if you:
    1. Try to copy or move a document into the document set, using the "Move to..." actions in Modern Experience. You'll see that the icon for the document set in the 'destination picker' is still the folder icon - it's not actually the document set icon.

    2. Switch back to the classic experience, and open up the document set. It behaves like a folder - not a document set. You don't get the "Document Set View" where you can see the properties at the top in a banner, and all the contents of it at the bottom.

    So ultimately while this is a neat trick, it isn't a good solution as it creates bogus document sets that don't actually work properly.

    Currently the only way I have this working is using Plumsail Actions - which has an inbuilt function to create document sets that does work properly.

    1. Interestingly I have some other code that moves these document sets to other libraries, once moved the icon is as expected after moving (a document set icon), I take your points, if an icon and classic experience are important to you... you can happily use the other method using vti_bin.

      This is just an experienced shared

    2. These are just the two issues that I identified - there may be more that I didn't notice in the short time I was using it, which could cause problems later down the track.

      There's obviously an underlying cause of why the folders don't fully behave like document sets after they've been changed - and as I don't know what it is, I wouldn't like to commit to this approach without being certain that it isn't hiding any more serious gremlins. YMMV of course.

  3. Great article, but another issue is the fact that you can't have any required fields in your Document Set for this to work. Otherwise if you do, it'll fail at the "Create new folder" step.

    To make matters worse, for some reason if you change those field(s) to longer be required (for example, to get around this issue), there's still something stuck telling Flow (and PowerApps btw) that the field(s) are still required. It's a mess!

    1. Hi StevenS, if you use the second approach (where you can specify the site url etc. in variables), in the final step you can add in the required field values that you want. I tried it out and seems to work ok. I created a new site column "Test" which was required, added this to the Document Set content type on the library. In the http request you'd then change the body to:

      '__metadata': { 'type': '@{body('ListItemEntityTypeFullName')?['d']?['ListItemEntityTypeFullName']}' },
      'ContentTypeId': '@{variables('DocSetContentTypeId')}',
      'Test': 'Hello'

      My required "Test" column then has a value of "Hello"

      Hope it helps


Post a comment

Popular posts from this blog

SPFx Christmas Banner Treat

SPOMigration Retrying due to error -2130246326