Calculating working days in Power Automate or Logic Apps

Note: there's currently an issue with images in Blogger . If you can't see the images in this post, you can  read the article on the Chorus website instead. Here’s a common scenario for any kind of SLA-driven process – calculate a target date or a due date for a task based on a number of working days. In most cases, we can take working days to be everything except weekends and public holidays. Let’s take a look at how you might go about it in Power Automate or Azure Logic Apps. Note: the approach is identical regardless of whether you go with Power Automate or Logic Apps – I’m using Logic Apps in this case because the HTTP connector requires a premium license in Power Automate.  The challenge Given a start date and the number of working days we need to add, calculate a target date. High-level approach The algorithm works like this: Add one day at a time to our start date – let’s call this the running date. If the running date is not a weekend or a public ho

Don't get caught out by Office 365 CDN settings

Quick note on something that caught me out today. Suppose you've developed your SPFx solution, you've tested it on developer tenancies, and you're ready to push it out on your client's Office 365 tenancy. You drop it into the App Catalog, and you see the following: Well that's not good. It's enabled... it's a valid app package... but it's failed to deploy. In the App Package Error Message column, we've got a generic Deployment failed. Correlation ID... message that doesn't shed much light on the situation. This turned out to be a simple oversight in Office 365 CDN settings. If  you're bundling client-side assets into your sppkg file (as is the default from SFPx 1.4 onwards), rather than deploying them to a separate CDN, you must make sure the public CDN is enabled on your Office 365 tenancy. It's a requirement that's well-covered in the SPFx documentation, but it might not be the first thing that comes to mind when you see a g

Permissions required to edit Quick Launch navigation links

Just a quick one today. A client needed to allow a group of users to add navigation links to the Quick Launch on their SharePoint Online sites: We mistakenly assumed that granting the Design permission level would be sufficient. That's not the case on SharePoint Online when the Publishing Infrastructure site collection feature is enabled. The EDIT LINKS link doesn't show up until you grant the Manage Hierarchy permission level. Alternatively, if you want to get granular, you need the Manage Web Site site permission.

Targeted Links in a Modern SharePoint UI

Recently I was advising a client on building out intranet-style content on SharePoint Online. I walked them through communication sites and modern team sites, demonstrated the mobile-friendly responsive rendering, the ease of editing, and so on. Then came the killer question: "how do I target my navigation links to different users?" This might well be on Microsoft's product backlog... but at the time of writing, there's no support for audience targeting with communication sites or modern team sites. So how do we use targeted navigation without losing the benefits of the modern UI? After a bit of trial-and-error we came up with a working solution using modern pages within classic SharePoint sites. There are quite a few gotchas, hence this post. Step 1: Create a suitable site Create or locate a classic SharePoint site (e.g. using the  Team Site - SharePoint Online configuration template). Gotcha #1: Don't use a publishing site template, or you won't be c

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="" Libr

Versioning SharePoint Framework Packages

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

Server Resource Quota in SharePoint Online

Q. What does the Server Resource Quota setting do in SharePoint Online? A. Right now, nothing. Nothing at all. Earlier this week I was talking to an IT Manager who's been troubleshooting some performance issues on a SharePoint Online site collection. As part of his investigation, he raised the issue with Microsoft Support. Among other things, the support engineer advised him to increase the Server Resource Quota for the site collection. Microsoft Support should really know better. For the avoidance of doubt, the Server Resource Quota existed solely to limit the amount of server resources that any sandboxed solutions running in the site collection can consume over a 24-hour period. As code-based sandboxed solutions have been blocked entirely in SharePoint Online from July 2016 , this setting now does absolutely nothing at all . I'd assume that in time it will disappear from the admin center UI.