A large part of our work as SharePoint Expert Consultants is to gather organisational requirements and provide recommendations for systems and architecture that can be used to adapt Microsoft 365 to meet these. When designing solutions, we can consider utilising:
- Out-of-the-box (OOB) technologies such as building SharePoint lists and libraries
- Low-code/No-code solutions for both interfaces and processes such as building within Power Apps, Power Automate and Power BI (the Power Platform)
- Bespoke coded solutions such as extending SharePoint with SPFX
In this detailed overview, we are going to focus on SPFX at a high level, to introduce this as a potential pathway that our customers can use to achieve their goals and objectives.
As the title suggests, this is to be reviewed at the level of a consultancy engagement versus drilling into the deep technical knowledge that our developers hold.
What is SharePoint Framework (SPFX)?
SPFX is the acronym for SharePoint Framework. This is a development model recommended by Microsoft to be used when customising and extending the SharePoint Platform.
You may hear of SPFX being used with other acronyms like Software Development Kit (SDK) and Application Programming Interface (API).
These relate to developers having a set of third-party tools and processes to be used when developing their applications.
Why was SPFX produced?
As SharePoint has continually evolved, its User Interface (UI) has gone through numerous iterations and improvements.
However, some customers still require bespoke developments to extend upon what is provided by SharePoint by default.
SPFX is available to give structure to these custom developments.
Developers needed a set of tools and a framework to assist them in building solutions that would work with Microsoft rather than against it.
This means that as Microsoft 365 evolves there was less of a risk to custom applications breaking.
It also meant that developers could evolve their own applications alongside Microsoft changes to help iterate and continually improve upon them.
SPFX was also produced to enable consistency in design and usability of applications. This all became part of the Microsoft Fluent UI.
Microsoft Fluent UI
Fluent UI is another set of frameworks that is focused on the user experience (UX) and design of applications.
The standards are defined within the Fluent UI website. These standards set out how best to style applications in alignment with the SharePoint platform.
Developers also have access to a set of controls that they can use within their developments.
Some of the following you might recognise from use of the current OOB web parts provided within SharePoint:
SharePoint Framework for Document Card Control
This is used in SharePoint Highlighted Content Web Part
SharePoint Framework for Command Bar Control
This is used within SharePoint Lists and Libraries
SharePoint Framework for Calendar Control
This is used in Lists and Libraries when adding date or time metadata (tags)
As you can see from the examples above, the components reflect what end users are commonly using within SharePoint.
This enables a common design language to be applied to custom applications to avoid increasing the learning curve for your admins, champions and/or page authors.
This commonality improves applications from a usability perspective and offers reasoning for design principles.
How to add SPFX Applications
For administrators, SPFX applications can be added as a package to an existing App Catalog Site or to a newly created App Catalog Site.
However, for the purpose of this blog we will focus on how these are added into a site once the development and administrative work has been finalised.
You will be pleased to know that this is very simple as it is the same route as adding any other web part to a site.
Adding a Web Part
As you can see from the below image, our custom web parts are available within the same menu as all OOB web parts.
This means that from an end user perspective, any customer applications that have been added to their tenancy or at least to the site they are working on will be available to add through a simple click of a few buttons.
The same applies to configuration.
Configuring a Web Part
For those who work on editing SharePoint Pages, you will see that the below configuration route for a custom web part is identical to how you are used to configuring OOB web parts.
The only difference will be the options provided, as is the case (for example) with Hero Banner configuration options being different to Quick Links.
The use of standard controls means that your current page authors, champions and administrators are already learning skills to help them configure any custom SPFX applications, as they will have a level of familiarity if these are added.
The scale of SharePoint Framework (SPFX)
It is important to note that as with any development the scale of the application will differ.
In my experience I have seen SPFX utilised to bridge gaps in the SharePoint platform through the creation of small web parts such as, notifications, accordions, and carousels.
However, I have also seen SPFX used to create full project tracking solutions and document auditing systems which have completely replaced third party tools.
Moreover, SPFX can be used to build and deploy applications into Microsoft Teams to extend those solution capabilities.
This will help tie its interface and your Intranet together seamlessly, which is becoming a lot more critical in the current Hybrid Working times.
Please also note that SPFX can be utilised within the SharePoint Classic UX if a move to the Modern UX is restricted.
This shows that the scale of SPFX and how it can extend SharePoint is only limited by time, resources, budget, and your imagination.
Final Thoughts about SharePoint Framework
In Summary, SPFX is a framework utilised by developers to build custom solutions within SharePoint and extend the OOB functionality that is available.
However, they can do this without impacting usability or building something that feels out of place within a SharePoint environment.
It is my view that SPFX should always be a technological consideration during any SharePoint and Microsoft 365 project.
It should also be considered during tendering processes or third-party tool analysis.
This is because there is always the potential to build a system that specifically meets an organisation’s needs, using licences they already have in place (improving the return on investment).
Furthermore, an upfront cost approach to development vs ongoing licence fees for a third-party system of which you may only be using a minimal percentage of may make better financial sense.
As with all projects, our recommendation would be to analyse and prioritise requirements and objectives. Once complete these can be reviewed against numerous options, of which SPFX should be one.