Modernizing the Document Set `NewDocSet` Form

Microsoft modernized Document Sets a few years ago – sort of. They really didn’t finish the job, and they seem to be under the impression that few people use Document Sets. Everyone I know who understands good Information Architecture (IA) knows about Document Sets, and they use them when they make sense – which can be frequently.

Microsoft stopped the modernization process without modernizing the NewDocSet form. If you don’t use these scripts (there’s no way to do this in the user interfaces), the NewDocSet form will look something like this. It’s classic and unattractive, though it does work just fine.

Wouldn’t this be nicer, though? It fits into the modern UI and acts more like all other NewForms.

Best of all, you can now apply formatting to the modern form: adding to the header, rearranging columns, putting a link in the footer etc. That’s because the form is now modern!

One of the bright bulbs in the community, Dan Toft – @dan-toft.dk‬ on BlueSky – figured out a way to “modernize” the NewDocSet form for Document Sets and posted a script sample to the Script Samples | PnP Samples called Enable modern creation forms for Document sets.

Dan’s sample works perfectly well when you want to modernize a Content Type which has been enabled in a specific Document Library. I wanted to modernize a bunch of Document Sets, though, and I had defined them in the Content Type Hub – which is still where Content Types end up when you define them in the modern Content Type Gallery.

I adapted Dan’s good work to list out the Content Types in the Content Type Hub which inherit from Document Set, enable you to choose one, change the setting to make the NewDocSet form modern, and if you want, publish the result.

Here’s the resulting PowerShell script:

$tenant = "YourTenantName"
$clientId = "YourAppRegistrationGUID"

$cthConnection = Connect-PnPOnline -ClientId $clientId -Url "https://$($tenant).sharepoint.com/sites/ContentTypeHub" -Interactive

# Get the "Document Set" content types
$cts = Get-PnPContentType | Where-Object { $_.Id.StringValue.StartsWith("0x0120D520") }

foreach ($ct in $cts) {
    $currVal = "❌"
    if($ct.NewFormClientSideComponentId.Length -eq '') {
        $currVal = "✅"
    }
    Write-Host "[$($cts.IndexOf($ct)+1)] $($ct.name) $($currVal)"
}

$CTindex = Read-Host -Prompt "Which content type to you wish to modernize"

# Null out the NewFormClientSideComponentId as that seems to bring it to modern UI
$cts[$CTindex - 1].NewFormClientSideComponentId = $null;
$cts[$CTindex - 1].Update($false);

Invoke-PnPQuery

$ctPub = Read-Host -Prompt "Content Type $($cts[$CTindex-1].Name) updated. Would you like to publish the change? (Y/N)"
if ($ctPub -ne 'Y' -and $ctPub -ne 'y') {
    Write-Host -ForegroundColor Red "Exiting without publishing changes."
    exit
}
else {
    # Publish the changed content type
    Write-Host -ForegroundColor Yellow "Publishing content type $($cts[$CTindex-1].Name) with ID $($cts[$CTindex-1].Id)"
    Publish-PnPContentType -ContentType $cts[$CTindex - 1].Id
}

Write-Host -ForegroundColor Green "All done"

When you run the script, you’ll see something like this:

The Document Set Content Types are listed, showing whether or not the NewDocSet form has been modernized already. ✅ means it has been, ❌ means it has not been.

After choosing the Document Set Content Type you want, you’re prompted to ask if you’d like to publish it. I can think of scenarios when you would (I’m done setting it up) – and when you wouldn’t (I’m still working on it) – so I made it an option.

Here’s hoping this script proves useful to you. I’ll be sure to submit it to the Script Samples | PnP Samples, too. Whenever you’re starting a script, be sure to check for a good sample to start with there.

---

IMPORTANT CAVEAT [Added 2025-07-23]

Today I wanted to revert this change on a Content Type which inherits from Document Set. Unfortunately, between Dan and me both hammering on it, we couldn’t come up with a way to make it work. One would think that replacing the NewFormClientSideComponentId property for the Content Type with the default value it had in it before would be the way to revert the change. For whatever reason – and it’s possible there’s some encoding trick we missed – this doesn’t work.