The SharePoint Guru

 When you use the inbuilt Power Automate SharePoint "Update item" or "Update file properties" and want to use a variable for that, you lose all the prepopulated columns: For general quick Power Automates - "Update item" is fine, but if you work with other developers or promote these across Power Platform Environments and hook them up to different lists/libraries, you may want to be able to quickly set that information at the top of the Automate. Not have to scroll through tens/hundreds of steps to change the target list URL everywhere. This is where "Send an HTTP Request to SharePoint" comes in, you just have to know how to use the SharePoint REST API, or follow my guide below. My Target library has two additional metadata columns which I'll show you how to update, "Document Type" and "Item Types", the latter being a choice field. For the example below I show what this might look if you are passing an Id of an item from a

NOTE: This makes a “pseudo” document set, use the VTI bin method to create a full blown document set, however perhaps some of the steps could be useful to you. 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:  https://karinebosch.wordpress.com/2018/11/08/microsoft-flow-create-a-document-set/ https://knowhere365.space/microsoft-flow-sharepoint-document-set-creation/ 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: https://www.spjeff.com/2009/03/13/history-of-_vti_bin/ 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  

I'm based in the UK and my current customer relies on the content type hub to provide their information management policies across SharePoint. It's not a new thing and the use of content type hub publishing has been with us since 2010. I've even worked with a colleague a few years ago to create an automated publisher for SharePoint Online, which authenticated against the SPO chub page and used scraping to press that 'Publish' button! Many customers rely on it, so why did Microsoft break it? As content types take time to publish to new site collections during creation I've often had to code a 'poller' to check if the content types are available, once that SharePoint timer job has done its thing the next phase of provisioning can continue, such as applying these to inbuilt document libraries to enforce an information management policy. This is very similar to my current customers provisioning tool. The only thing - these content types have stopped appearin