How do we change the feature scope for an SPFx extension?

[chrisobriensp]

Category

• Question
• Typo
• Bug
• Additional article idea

Expected or Desired Behavior

When creating an SPFx extension (e.g. application customizer), I expected to be able to change the feature scope when the feature is defined in package-solution.json. The default is a site/web scoped feature, but sometimes we may want a site collection-scoped feature.

Observed Behavior

There is no "scope" property of the feature node, and adding one makes the file fail to be validated against schema in the bundling/build process. The following error is observed:

ERROR: Error parsing file 'package-solution.json'
(#/solution/features/0) Additional properties not allowed: scope

Steps to Reproduce

1. Create an application customizer using the steps outlined in the documentation at https://dev.office.com/sharepoint/docs/spfx/extensions/get-started/build-a-hello-world-extension.
2. Add a "scope" child to a feature node in package-solution.json.
3. Run gulp serve.

Here's an image which shows what I expected to do to change feature scope:

Can this be done? If so, how?

Thanks!

COB.

[VesaJuvonen]

This is not currently supported. All SPFx solution features are always scoped to 'Web' scope. We are though looking into releasing additional switches for the developers, which can be used to push out the SPFx solution to be available cross the site collections in the tenant as long as it's installed on the app catalog. You'd still need to associate the extension to be used in the site collection, but you do not need to install SPFx solution specifically to the sites.

This means that from the deployment perspective, scenario or steps would be following.

1. Deploy your package to app catalog with specific configuration to enable that in the site collections - If it's a web part, it will be available immediately in the web part picker
2. If it's an extension, you'll need to still associate the right ClientComponentId to specific location or to FIeld object
3. You'll use remote provisioning techniques to set the Extension instance on the specific object

In your example case, you are building an ApplicationCustomier - so the process would be following to enable that cross specific or all sites.

• Deploy to app catalog
• Write needed code to associate add CustomAction with specific location and ClientComponentId matching to your manifest identifier
• You can use REST/CSOM/PowerShell for the association, based on your business scenario. PnP PowerShell and PnP Provisioning Engine has native support for associating these settings to site level objects

[chrisobriensp]

Hey Vesa,

OK, that works! I don't mind it being a separate thing to do the association/binding, and there's a lot of control that comes it with it being done that way.

Will PnP XML schema be extended to support this?

Cheers,

COB.

[VesaJuvonen]

Yes - PnP 2017-05 PnP provisioning schema supports this. The engine has not yet been updated to match this requirement due to resource constraints, but coming soon as well. Since we will be however taking a break during July on PnP releases, engine update will be available from August 2017 release forward.

[chrisobriensp]

Great, thanks Vesa. Yes, I see the bits of documentation related to this in the 2017-05 schema (e.g. https://github.com/SharePoint/PnP-Provisioning-Schema/blob/master/ProvisioningSchema-2017-05.md#clientsidepages)

Good news all round, thanks!

Cheers,

COB.

[wobba]

@VesaJuvonen You say the engine has not been updated to associate global apps, but are you implying the code/logic behind this is available? Or is backend and PnP wrapper code targeted for August both? If API's are there to deploy to app catalog and associate to a web today I'd be thrilled :) Having it in PnP is nice and preferrable to me, but not a showstopper :)

[VesaJuvonen]

@wobba - Globally deployed apps/SPFx solution will be soon available with SPFx update for both server and client side. PnP templating does also support associating ClientSideComponentId with the latest schema for the sites, but you can absolutely use also native CSOM to get this completed. Steps to complete the scenario:

1. Get SPFx update available and out
2. Associate ClientSideComponentId with remote APIs for the needed objects in site collections - can be CSOM, REST, PnP Templates etc.

We'll obviously announce the global deploy option across different channels when it's available.

[wobba]

Nice :) The association to add oob parts I have allready tried :) And when you fill the deploy gap, that will be huge for the app/add-in model indeed. You guys are just kicking ass making it fun to create solutions for customers.

[himanjanpati]

Hello @chrisobriensp, can you please let me know how can i staple my extension through out all my site collections after i deploy that inside my app catalog?
Can i get the extension in all my site collection though out my tenant?

[frankchen76]

As @VesaJuvonen mentioned, you can use CSOM, REST or PnP to programmatically associate ClientSideComponentId with the site collection you want.

[Rainson12]

@VesaJuvonen Is there a sample on how to associate my spfx extension to a site collection instead of only a web? Add-PnPCustomAction only adds it to a web scope..