Call Azure AD secured Azure function from Logic App or another Function with Managed Identity

Sometimes you have a need to call an Azure Function with Azure AD enabled authentication from Logic App or from another Function or Azure Web App. For example, you have an API for your SPFx solution and also have a requirement to build a Logic App, which uses some methods from the web API. In that case, you should somehow perform the authentication to call your Azure AD protected function. You can easily solve this problem with Managed Identity

Let's see how it works in practice. More...

How to use Remote Event Receivers with .NET Core (or .NET 5) and PnP.Framework

In June 2020, a .NET Standard version of SharePoint CSOM was released. It means that now we can build projects for SharePoint, that target multiple platforms. At the beginning of 2021, a .NET Standard version of PnP-Sites-Core was also released (with a brand new name PnP.Framework and an updated codebase). However, there are some limitations in the .NET Standard version of SharePoint CSOM. Especially the lack of Remote Event Receivers (RER). The whole namespace was dropped. In some cases, you cannot replace RER with Webhooks without loss of functionality. Sometimes you just need RER or you're upgrading your code and cannot migrate RERs to webhook, since that's expensive. 

So, let's bring support of Remote Event Receivers back to .NET Core \ .NET 5+.

The source code sample for this blog post is available at GitHub here (the master branch contains code for .NET Core, if you're looking .NET 5 sample, use net5 branch). More...

How-to: Call SharePoint REST API with application permissions from Azure Logic App with Azure Key Vault and Managed Identity

If you have a need to interact with SharePoint API from Power Automate \ Logic Apps, most likely you would select SharePoint connector, which uses user identity for authentication. However, it's also possible to connect to SharePoint REST API with application permissions and certificate authentication. It's fairly easy if you have an Azure Key Vault. 

Here is what steps needed. More...

Simplify secret keys management for M365 applications with Azure Key Vault and Azure Managed Identity

Azure Key Vault simplifies a lot of things when it comes to secrets, passwords, certificate management. There are a lot of different ways of using it for different apps or services. In this post I'm going to cover below scenario: 

  • we have a service, running in the background, which connects to SharePoint API and performs some operations. As a good example, it might be a SharePoint PnP provisioning process running as a daemon through azure functions or azure web job
  • the provisioning process uses Application permissions to access SharePoint API, thus uses certificate-based authentication through Azure AD auth
  • all authentication secrets (certificate in our case) are stored in Azure Key Vault 
  • we do not store any secrets anywhere except Azure Key Vault (not locally in code and not in the azure function or job configuration)
  • we use a brand new PnP Framework!

Interesting? Then please read further below. More...

spfx-fast-serve 3.0: it's all about simplicity

- What?? Two major releases in just two weeks? Should I again migrate?

- Unfortunately, yes, you should migrate again. Fortunately, it's not that difficult. Additionally, 3.0 is a lot more flexible and simple.

Technically, it's the same codebase and functionality as 2.0, however recent findings made me available to drastically change the way of handling the "serve" command. Also, I removed some cli options (pnpm now is supported out-of-the-box, sp-rest-proxy is supported as an extension using webpack.extend.js). Since cli options were changed and the "serve" handling, I had to introduce a new major version. 

The new version gives the below benefits:

  • A lot easier configuration - you don't need a lot of webpack dependencies in your package.json, you don't even need webpack.js in your project tree. As a result, spfx-fast-serve adds only a small footprint to your SPFx project
  • A lot easier migration between SPFx versions - now you don't need to run spfx-fast-serve each time you migrate your project to the next SPFx version, instead, you just need to update a dependency in package.json
  • A lot easier bug fixing - now all fixes are delivered automatically as a regular npm module dependency, no need to update spfx-fast-serve and run it again

Check out what code is added to your gulpfile.js:

const { addFastServe } = require("spfx-fast-serve-helpers");

Check out which additional dependencies you need in your pacakge.json:

"spfx-fast-serve-helpers": "~1.12.0"

1.12 - reflects SPFx version. If you need to migrate to a new SPFx version - you change the minor version for spfx-fast-serve-helpers and that's it.

And finally serve command:

"serve": "gulp bundle --custom-serve --max_old_space_size=4096 && fast-serve"

You can also browse the code of the basic sample here. It contains the bare minimum needed to run 3.x with SPFx 1.12.1.

Check out this doc to learn how to upgrade to the latest 3.x version. If you use spfx-fast-serve, I recommend you migrate to the 3.x version today, because all future updates will be based on the 3.x version only. This version is considered stable and no more major releases planned in the nearest future. 

Title image credits - Business vector created by freepik -

spfx-fast-serve 2.0: new architecture, better extensibility, support of the latest SPFx

In the last few weeks, I was working on spfx-fast-serve v2.0 release. What is spfx-fast-serve?

A command line utility, which modifies your SharePoint Framework solution, so that it runs continuous serve command as fast as possible.

New architecture

At the very beginning, this tool was more like an experiment to see what is possible and also to see the potential limitations. During last year I fixed a bunch of bugs, added support for library components. However, the code was not as good as it should be. It was just a javascript file with all the logic. I see that the usage of spfx-fast-serve is growing, thus decided that it's a good chance to make it better. 

In a new version, everything is done using TypeScript with a lot better architecture. Different commands are responsible for different solution modifications - package.json update, gulpfile update, write webpack.js to disk, etc.  It will be a lot easier to maintain and to upgrade between different SPFx versions. It also easier for potential contributors to make changes. More...

SPFx Check Locale - a nice option to check your localization consistency across SharePoint Framework solution

If you develop multi-lingual SharePoint Framework solutions, you know that you should keep your localization files in sync. You have a "master" file, which defines your localization resources structure, by default it's called "mystrings.d.ts" where you define all different keys. In the corresponding {locale}.js file you implement actual translations. In some cases, when you have a lot of labels after the refactoring you might lose the synchronization between your "mystrings.d.ts" and JS resource files. That leads to empty labels and UI problems in your web parts. SPFx doesn't provide a mechanism to check it. 

Now you can use SPFx Check Locale VSCode add-in and a Nodejs module to perform such checks. 


You can install the addin from here or just search in VScode for "SPFx Check Locale".

The below video describes the core features of the addin: 

If you have and differences between your maser "mystrings.d.ts" and {locale}.js resource, the error will be immediately reported (including line and message). Using the addin you now have a clear visual indication that something is wrong with your localization files. 


You can also integrate SPFx check-locale as an additional quality check into your build pipeline since it's also available as a nodejs module

Install "spfx-check-locale" module and just add the below code to your gulpfile.js:

const checkLocales = require('spfx-check-locale').checkForErrors;

const argv = build.rig.getYargs().argv;
if (argv.production) {
  const check = build.subTask('check-locales', function (gulp, buildOptions, done) {
      projectPath: __dirname,
      printErrors: true
      .then(result => {
        if (result.diagnosticData.length === 0) {
        } else {
          done('Found errors in localization files');

  build.rig.addPostBuildTask(build.task('check-locales', check));

That way before publishing to production you always sure that your resources are good, otherwise your build will fail. The above code performs locale checks only on production builds (argv.production, which is true for gulp bundle --ship). You can also do it on a normal gulp serve, however, it will slow down your build for additional 2-4 seconds. With VSCode add-in it doesn't make a lot of sense to have it in serve command. 

"spfx-check-locale" integrates smoothly with your CI\CD process as well.

How it works

Every SharePoint Framework project contains a config.json file, which lists localizedResources - a collection of project resources. spfx-check-locale module opens every folder with resources and extracts interface name from "mystrings.d.ts" (using TypeScript AST). Then it creates a virtual TypeScript project in memory adding all files inside the resources folder. {locale}.js are renamed to {locale}.ts. For every {locale}.ts it also adds a return value for a function to be equal to the interface name from "mystrings.d.ts". 

For example, a en-us.ts will look like below:

define([], function(): IHelloWorldWebPartStrings {
  return {
    "PropertyPaneDescription": "Description",
    "BasicGroupName": "Group Name",
    "DescriptionFieldLabel": "Description Field"

Next, the module runs TS compilation in memory and VSCode add-in simply maps TS errors to the corresponding lines inside IDE. That way we can see all problems in a real time. 

Title image credits - People vector created by pch.vector -