Automating Navigation Inheritance for SharePoint Sites

Automating site creation processes with SharePoint workflow has cropped up a lot in this blog over the years. The latest battle has been getting newly-created subsites to inherit the top link navigation bar from the site collection root.

In summary...

At the time of writing, you can't switch on navigation inheritance using the REST API. I've tried, exhaustively. Google agrees.

You can switch it on using client-side code (managed client or JavaScript)... but that's no use for applications such as workflow where you're limited to code-free solutions.

However...  if you can do it with client-side code, you can do it by calling the client.svc service with an XML body. It's ugly but effective. Your web service call should look something like this:

Endpoint:
{Web URL}/_vti_bin/client.svc/ProcessQuery

HTTP method:
POST

Headers:
Content-Type: text/xml

Body:
<Request AddExpandoFieldTypeSuffix="true" SchemaVersion="15.0.0.0" LibraryVersion="16.0.0.0" ApplicationName=".NET Library" 
xmlns="http://schemas.microsoft.com/sharepoint/clientquery/2009">
  <Actions>
    <SetProperty Id="1" ObjectPathId="2" Name="UseShared">
      <Parameter Type="Boolean">true</Parameter>
    </SetProperty>
  </Actions>
  <ObjectPaths>
    <Property Id="2" ParentId="3" Name="Navigation" />
    <Identity Id="3" Name="{0}:site:{1}:web:{2}" />
  </ObjectPaths>
</Request>

There are three string placeholders in the XML body above:

  • {0} is the ID of the SPObjectFactory class. At the time of writing, for SharePoint Online at least, this appears to be af552f9e-a032-4000-c7e1-e6a34cfee284|740c6a0b-85e2-48a0-a494-e0f1759d4aa7. It should always be the same, as far as I know - it's currently working for me in two different Office 365 tenancies.
  • {1} is the GUID of your site collection.
  • {2} is the GUID of the web that you want to update.
And that's it. 

(By the way, if you want to see how to bundle it all up into a custom workflow activity, take a look at this post from 2014. Visual Studio workflow activities remain the same now as they were then.)

Comments

Post a comment

Popular posts from this blog

The target principal name is incorrect. Cannot generate SSPI context.

Image
Today's problem occured after I restarted a Hyper-V based SharePoint 2013 farm (Windows Server 2012, one SharePoint 2013 machine, one SQL Server 2012 machine, one DC). I fired up Central Administration and was hit with the following error: Unknown SQL Exception 0 occurred. Additional error information from SQL Server is included below. The target principal name is incorrect. Cannot generate SSPI context. After checking the obvious things - testing connectivity to the DB server, checking the SQL service was running, verifying permissions, etc - I initially figured this was an issue with my Hyper-V snapshots being out of sync, so I ran the SharePoint Products Configuration Wizard. This hit me with the following error: Failed to detect if this server is joined to a server farm. Possible reasons for this failure could be that you no longer have appropriate permissions to the server farm, the database server hosting the server farm is unresponsive, the configuration database is
Read more

Server-side activities have been updated

Image
If you use SharePoint Designer 2013 to build workflows, there's a fair chance you'll have come across the following error message: Server-side activities have been updated. You need to restart SharePoint Designer to use the updated version of activities.  Needless to say, restarting SharePoint Designer rarely makes the error go away. The usual advice is: Approach 1: Clear the cache folders See for example How to Clear Your SharePoint Designer 2010/2013 Cache . If you've just deployed some custom workflow activities to your site, this will probably solve your problem (and you should clear the cache folders every time you deploy custom activities). If the error occurs spontaneously, this approach often won't help. Approach 2: Reinstall SharePoint Designer This might work if you've got a preview version of SharePoint Designer installed. If not, it's unlikely to help. It didn't work for me, and it didn't work for countless others on the forums. Ap
Read more

Versioning SharePoint Framework Packages

Image
TL;DR: Package versioning in SPFx web parts is confusing. Your sites will notify you that an upgrade is available, but will automatically use the latest version of your code regardless. Package versioning behaviour in the SharePoint Framework is currently a little idiosyncratic, and it recently caused us a few headaches. It seems that from a versioning perspective SharePoint (incorrectly) expects the SPFx packages to behave like SharePoint Add-ins. In this post I'll run through some of the issues we encountered and how we worked through it. Context You can version an SPFx package in three places: The SharePoint package manifest , in the package-solution.json file. The component manifests , in one or more .manifest.json files. The NPM package manifest , in the package.json file. In this post we're looking at the SharePoint package manifest (package-solution.json) as this is the version number that SharePoint reads and propagates when you deploy a package to the App
Read more