Will the SharePoint Framework be the recommended way to brand Site Collections replacing Master Pages, Composed Looks and Alternate CSS? What SharePoint Framework capabilities, other than Client-Side Web Parts, can we expect to see in the future?
Recently we had the pleasure of hosting two webinars introducing the SharePoint Framework – a new model for building SharePoint customizations. Bill Baer and Vesa Juvonen from the Microsoft SharePoint Product Group presented the vision behind the SharePoint Framework and how it will help organizations build modern SharePoint solutions.
Recordings and presentations from both webinars are available online at
During the webinars you asked Bill and Vesa over 200 questions! While they couldn’t answer all of them during the webinar, we promised you to follow up on them. Following is the first set of questions related to the SharePoint Framework and Bill’s and Vesa’s answers. In this articles series we will share more questions and answers on the topics:
Q2.1 Will the SharePoint Framework be the recommended way to brand Site Collections replacing Master Pages, Composed Looks and Alternate CSS?
SharePoint Framework as such does not influence the actual branding capabilities. We are however designing the new branding capabilities and options for the future in engineering, but detailed schedule is not yet locked. SharePoint Framework client-based web parts will work in both classic pages and also in the modern experiences.
Q2.2 What capabilities will the SharePoint Framework offer for integrating with and customizing the SharePoint User Experience?
SharePoint Framework as such does not influence the actual branding capabilities. We are however designing the new branding capabilities and options for the future in engineering, but detailed schedule is not yet locked. SharePoint Framework client-based web parts will work in both classic pages and also in the modern experiences.
Q2.3 Is it possible to manipulate the global navigation using the SharePoint Framework?
The engineering team is currently investigating different options to provide these kind of capabilities on publishing and non-publishing sites using the SharePoint Framework. Stay tuned for updates.
Q2.4 Will it be possible to use the SharePoint Framework to customize modern UI controls, similarly to how we can do that in the classic UI today?
The engineering team is currently researching different concepts for customizing SharePoint UI. Stay tuned for more information in this area.
Q2.5 Will it be possible to connect Web Parts with each other, similarly to classic Web Parts we built in the past?
The engineering team is currently investigating the concept of connected Web Parts and how they would work in the SharePoint Framework. More information about this capability should be shared in the near future.
Q2.6 What personalization capabilities will Client-Side Web Part support?
Currently Web Parts display the same contents to all users. A Web Part could use the information about the current user to adjust its contents but that would be a Web Part-specific implementation rather than a capability supported by the SharePoint Framework.
Q2.7 What is the recommended approach for provisioning assets such as Columns or Content Types with the SharePoint Framework?
The current recommended approach for provisioning SharePoint assets is by leveraging the remote provisioning techniques described at https://msdn.microsoft.com/en-us/pnp_articles/pnp-remote-provisioning. It’s up to you to decide which implementation (PnP Partner Pack, custom provider-hosted Add-in or the Web Part itself) suits your requirements the best. Engineering teams are also working on future native remote provisioning options. Stay tuned for updates.
Q2.8 How are SharePoint Framework solutions versioned? Can we have multiple versions of the solution/Web Part running side-by-side or is there only one version available in the particular tenant?
This slightly depends on your implementation style and the chosen version path. Since actual JavaScript files which are the functionality of the client-side web part are stored in centralized location, not in the actual sites, you can control if you push updates immediately to all instances or if you’d like to push a separate version of your customization.
Q2.9 Is it possible to deploy SharePoint Framework solutions from the App Catalog so that they can be centrally managed and cannot be removed by site owners?
This is not currently included in the Developer Preview, but is a great suggestion for needed capability. Would suggest to enter an idea on the following GitHub list for tracking purposes – https://github.com/SharePoint/sp-dev-docs/issues.
Q2.10 Will SharePoint Framework solutions support OAuth and connecting to the Microsoft Graph?
Because SharePoint Framework Client-Side Web Parts run as a part of the page, there is no way for them to secure their access token from other elements on the page. The engineering team is currently researching the different ways in which developers could securely connect to Microsoft Graph. More information about this should be shared in the near future.
Q2.11 Can we expect additional capabilities in the Managed Metadata REST API?
REST APIs are the native way for SharePoint Framework client-side web parts to communicate with SharePoint. This means that we are looking into enhancing existing APIs and addressing needed gaps gradually.
Q2.12 Are SharePoint Framework solutions subject to the same permissions restrictions as SharePoint Add-ins?
SharePoint Framework solutions are executed as a part of the page and under the context of the current user. They are not isolated with iframes the same way SharePoint Add-ins are and they are not granted explicit permissions.
For more information see also https://rencore.com/blog/use-new-sharepoint-framework/.
Q2.13 Are there any plans to allow publishing SharePoint Framework solutions in the Office Store?
Engineering is investigating different options to provide store capabilities also for SPFx elements. Since SPFx solutions are though executed as part of the page under the context of the current user, similar oAuth model as wtih add-ins is not present.
Q2.14 What capabilities, other than Client-Side Web Parts, can we expect to see in the SharePoint Framework in the future?
The engineering team is investigating releasing additional shapes and parts as part of the SharePoint Framework. Stay tuned for updates.
Q2.15 Is it possible to export Web Parts built on the SharePoint Framework and import them in the previous versions of SharePoint?
The engineering team is currently investigating the support for exporting and importing Client-Side Web Parts. As SharePoint Framework is supported in SharePoint Online, and soon in SharePoint 2016, it will not be possible to import Client-Side Web Parts to older versions of SharePoint.
Q2.16 How does the SharePoint Framework ensure that different Web Parts using different (versions of) frameworks on the same page won’t collide with each other?
SharePoint Framework uses the JavaScript module pattern which helps isolating the building blocks of the different Web Parts on the page and ensuring that the different versions won’t conflict with each other. The module pattern works only with frameworks that are provided as modules so if you want to be sure that your framework won’t collide with other scripts on the page, you should check if it’s distributed as a module that can be referenced from Client-Side Web Parts.
Q2.17 Is it possible to elevate permissions in Client-Side Web Parts?
Client-Side Web Parts are built with JavaScript and run in the context of the current user. With that, there is no support for elevating privileges. If your solution requires elevating user’s privileges, then you should consider combining your Client-Side Web Part with a SharePoint Add-in.
For more information see also https://rencore.com/blog/use-new-sharepoint-framework/.
Q2.18 Is using Webhooks a more reliable way of handling events in SharePoint than using Remote Event Receivers?
WebHooks are industry standard model for http based events used by also by multiple other services than Office 365. Comparing to Remote Event Receivers, Webhooks are easier to use and offer a retry mechanism with an incremental back off strategy. For more information about Webhooks visithttps://dev.office.com/blogs/introducing-sharepoint-webhooks.
Q2.19 Do you need to authenticate before communicating with SharePoint APIs?
Because Client-Side Web Parts are a part of the page and run in the context of the current user, it is not necessary to authenticate before calling SharePoint APIs. Calling SharePoint APIs from Client-Side Web Parts happens client-side and the authentication cookies present in the browser are automatically sent with the request to SharePoint.
Q2.20 What is the recommended approach for integrating with the business layer in SharePoint Framework solutions?
SharePoint Framework solutions focus on the UI part of the customization. Using services and web-based APIs they can connect to other systems that implement business logic and perform complex or long-running operations.
Q2.21 Is it possible to connect Client-Side Web Parts to SQL databases or are they only limited to lists?
Client-Side Web Parts use web-based APIs to connect to other systems. If you have a server-side API that communicates with a SQL database or another system, then you could leverage it in your Client-Side Web Part.
In the next article we will share more of Bill’s and Vesa’s answers, this time related to developer tooling that supports building SharePoint Framework solutions. Meanwhile, if you have any more questions related to SharePoint Framework capabilities please don’t hesitate to ask using the comments and we will try to get you an answer.
With SPFx now considered one of the most popular extensibility points across Microsoft 365, and SPFx being the only way to extend the modern platform, SPFx Pre-built applications are now available in Microsoft AppSource. The Rencore Code App Analyzer is one such free application publicly available for admins and platform owners to identify and understand application architecture.
Click the link below to head over to AppSource!