Options to consider for SharePoint Framework solutions deployment

There are various options to package and deploy a SPFx solution and as part of packaging and deployment process, the devs have to identify a best approach for their team. Sometimes it becomes a nightmare to plan the right approach for your solution, if you haven’t weighed the options properly.

Working at multiple implementations of SPFx solution for sometime now, I have been able to get an idea of various options and approach for them. Hence in this blog, we will at these options and look at merits and limitations for each.

At a high level, below are the main components that are deployed as part of SPFx package deployment:

1. The minified js file for all code

2. The webpart manifest file

3. Webpart compiled file

4. The package (.pckg) file with all package information

Deployment Options

Please check this blog for an overview of the steps for building and packaging a SPFx solution. The packaged solution (.sppkg) file can then be deployed to a App catalog site. The assets of the package (point 1-3 of above) could be deployed by any of the four below options. We will look at the merits and limitations for each.

1. Deploy to Azure CDN 

The assets could be deployed to an Azure CDN. The deployment script is already a part of SPFx solution and could be done from within the solution. More detailed steps for setting this up are here.

Note: Please remember to enable CORS on the storage account before deployment of the package. 
If CORS is not enabled before CDN profile is used, you might have delete and recreate the Storage account.

Merits:

  • Easy deployment using gulp
  • Faster access to assets and web part resources because of CDN hosting
  • Add geographical restrictions (if needed)

Limitations:

  • Dependency on Azure Subscription
  • Proper set up steps required for setting up Azure CDN. In some cases if the CDN if not set properly, then the deployment has to be done again.
  • Since the assets are deployed to a CDN endpoint, so if assets need restricted access then this mayn’t be recommended

2. Deploy to Office 365 Public CDN

For this option, you will need to enable and set up Office 365 CDN in your tenancy before deployment. For more details of setting this up, check the link here.

Merits:

  • Faster access to assets and web part resources because of CDN hosting
  • No Azure subscription requirement
  • Content is accessible from SharePoint Interface

Limitations:

  • Manual copy of assets files to CDN enabled SharePoint library
  • Office 365 CDN is a tenant setting and has to be enabled for the whole tenancy
  • Since the assets are deployed to a CDN endpoint, so if assets needs restricted access then this mayn’t be recommended
  • Accidental deletion could cause issues

3. Deploy to SharePoint document library

This is also an option to copy for the compiled assets to be copied to a SharePoint document library anywhere in the tenancy. Setting this up is quite simple, first set the setting “includeClientSideAssets”: false in package-solution.json file and then set the CDN details in write-manifests.json  file.

Merits:

  • No need of additional Azure hosting or enabling Office 365 CDN
  • Access to Assets files from SharePoint interface

Limitations:

  • Manual Copy of assets file to SharePoint library
  • Accidental deletion could cause issues

3. Include as part of Solution Package (Deploy to ClientAssets in App Catalog)

From SPFx version 1.4, it is possible to include assets as part of the package file and deploy it to the hidden ClientAssets library residing in App Catalog. It is set in the package-solution.json file “includeClientSideAssets”: true.

Merits:

  • No extra steps needed to package and deploy assets

Limitations:

  • Increases the payload of the package file
  • Risk for Tenant admins to deploy script files to the Tenant App Catalog.

Conclusion

In this blog, we saw the various options for SPFx deployment, and merits and limitations of each approach.

Happy Coding !!!

Microsoft Teams Governance and Security : Part 1 – What does it mean for your organisation?

Microsoft Teams has added a lot of value to organisations looking for effective and fast collaboration. Additionally, Teams has enabled users to share and manage information at a single location seamlessly without moving content around to meet their content needs. But the key to using Teams effectively is how to implement it pragmatically across teams and users without impacting normal business processes.

There are various ways to implement Teams effectively but one of the key required implementation criteria is Governance and security. Now having done Microsoft teams deployment and implementation for last few years, I have been answering some of these queries for multiple organisations of various sizes; from few hundreds to thousands.

Some of the below queries might seem familiar to something that your organisation might be thinking of, and hence in this upcoming blog series we will be looking at answering some of them.

  1. How well can Microsoft Teams be Governed?
  2. What are the fundamentals of implementing Teams Governance?
  3. How do we manage creation and lifecycle of Microsoft Teams?
  4. What do we need to consider about data security and policies ?
  5. How about managing guests and how well can we audit them?
  6. What about roles and how well can we manage it in Teams flat structure?

To start with, in this blog, we will look at Teams governance plan at a high-level and fundamentals before deep diving into some of the core logistics and implementation criteria

Teams Governance Plan

The Teams Governance Plan could be classified under four broad headers. There are other ways we could try to approach it but below is the simplest broad groupings that I find useful.

  • Users and Secure Access
  • Creation Rules and Naming Standards
  • Compliance, Classification and Security
  • Teams and Content Lifecycle management

There is another aspect of Teams governance which is Teams Apps Governance, that I consider as a separate part of governance scope and will list it out in another blog series.

Now let’s take a high-level look at each of these categories. In the upcoming blogs of this series, we will deep dive into each of these concepts and get a plan for implementing each.

In the above diagram, as we can see there is an underlying layer of Teams Architecture which is critical for the successful ongoing management of the Governance Plan. We will talk more about Teams architecture in another series of upcoming blogs.

Users and Secure Access

Users and Secure Access are keys tounderstand the scope and how well a Team can be managed. In other words, it gives us an idea of how we can create an effective governing structure and plan for proper management of access for its users and content.

Teams, at a high level, provides us with three broad groupings of users.

  • Owners
  • Members
  • Guests

Now this might look simple but there are a lot of aspects that might influence how best we can use the concept of owners, members and guests to secure access to content. The guest access is one of the critical aspects of Teams security planning. We will look at how to manage the guest access in Teams in a later blog part of this series. There is also known concept of Channel moderators which is not use to its fullest as of now.

In a separate blog of this series, we will explore this in more detail and look at guest access options and possible scenarios to manage.

Creation Rules and naming standards

Creating the right number of Teams is critical for operational management of Teams and prevent uncontrolled sprawl of Teams. Now there is no direct answer to how many Teams is the right number and various factors influence what would be governing reason for putting control on creation of teams. In later blogs, we will look at what kind of creation rules we should have and how to better name them, so it is easier to locate and find them.

Note: We will look at some of these governing factors such as organisation structure, 
working model of business teams that influence creation of teams in the Team Architecture blog series

Compliance, Classification and Security

Classification and compliance are critical for organisations to manage the requirements for legal and more importantly preventing data loss both intentionally and unintentionally.

Traditionally, users had to create and collaborate on content separately and then move it to a Records management tool for managing compliance and classification. However, this means that either some of the compliance rules have been forgone during creation or have duplication of data.

Hence having an upfront security and compliance architecture helps to manage and contain important information at a single location without losing track of it

In the upcoming blogs, we will look at classification and compliance in detail and how implementing them can significantly reduce the risk of data loss.

Teams and Content Lifecycle management

Teams and Content Lifecycle Plan is an important part in keeping the content in your collaboration space current and managed properly.

For example, if the content in your sites are more than 10 years old, is it of any beneficial to retain the content for this long? Also, in certain cases organisations require the content to either renewed such as contracts or archived so that the content is not lost. In all these cases, we need to provide rules and criteria to provide guidance to what happens to the content past its life period.

The automated management of Teams as a whole or content individually provides administrators a centralized overview and control of content that might be dispersed and managed across various Teams, SharePoint sites and Groups.

In the upcoming blogs, we will look at the various options available and ways to make the Teams and content life-cycle smarter.

Conclusion

In this blog, we looked at the high-level governance areas for a Teams Governance implementation. Remember, don’t make governance at the last part of your Teams deployment, but it should go hand in hand with your implementation. 

As a final reminder, please keep an eye for the upcoming blogs, where we will look at each of the above in detail and get an understanding of how to use them effectively.

  • Users and Secure Access
  • Creation Rules and Naming Standards
  • Compliance, Classification and Security
  • Teams and Content Lifecycle management

Simplify building apps in Microsoft Teams Part 2 – Features and Components analysis

5-10 min read(medium)

In the previous blog here, we looked at the various scopes and solution components that could be built into Microsoft Teams. Also, I mentioned some of the questions that we could get while working on a solution with the various options possible in Microsoft Teams. In this blog, we will compare the ins and outs of these solution components and the challenges we are trying to answer.

Components

Before we start looking into details of how to use components effectively, below is the quick list of components that we discussed in the last blog for reference. For more details, check the previous blog here.

  1. Personal Apps / Tabs
  2. Channel Tabs
  3. Bots
  4. Messaging Extensions
  5. Connectors
  6. Task Modules

Each of the component has their strength and merits that makes them best for specific scenarios. Below in the capability chart section we will look at hosting and architecture scenarios for these components.

Capability chart

There are various cool features with components but as we all know one size doesn’t fit all. Hence, we must match the suitability of the components to the hosting requirements.

For e.g. Personal tabs are user specific but if we want to deploy the app to every user of the firm then the best way is to host the solution at the tenant catalog and then install the app for users using a script. It is also possible for a user to upload the app individually for personal use if an app package file is provided.

To capture all the possible scenarios, below is a capability chart for each of the components at various levels of IT requirements. The Capability Chart shows the relationship of the components with various architectural requirements for each.

We will look at the following levels. There are other levels we could evaluate on but below are few fundamental ones:

  1. Application Scope: Scope at which application can be installed and accessible
  2. Set up configuration: Allow to configure the component when or after installation
  3. Impact Scope: Scope of impact in case of anything breaks or changes
  4. Risk Index: Risk associated with the component’s use and application
  5. Role Based Access Control (RBAC): This is useful to restrict access based on the user roles or security levels
  6. Deployment Scope: Scope of deployment supported by the component

The above will help the architecture and design team to decide which of the options works well for the solution from hosting, deployment and management perspective.

Solutions Map

The capability chart gives us a list of limitations or technological boundaries for the components. If capability scope is flexible, then it now up to business requirements for identifying the best component option. So, we can use the solution map (as below) to see which one of the component options could be best fit for the solution.

The other aspect of the solution model is what requirements and factors that we are trying to fulfill with the solutions. If the requirements are more towards a particular scope, then we can align the solution towards that component.

For eg. Bots are good for Q&A requirements where instead of a Questionnaire form, we have a conversational bot on the other end which understands the user requirements and provides the answer choices.

We can distribute the solutions broadly in one of the below categories

  • Focus work: Relates to requirements which allow user to get information without moving around apps or through multiple business apps from a single place
  • Governance: Relates to control and management of the environment. It also includes capturing information that enables users/admins to use this information for tracking and managing the platform better
  • Team work: Relates to easy collaboration and share information among team members to allow faster team work
  • Integrated Solutions: Related to connecting more than one business applications to share / gather / use information from multiple scenarios
  • Custom Single Page App (SPA): This allows to create Single Page Applications such as Gmail, which will allow users to work on a single screen instead of browsing many pages of the app
  • Third party or Internal Apps: This could be third party vendor app requirements or custom internal apps built to support
  • Alerts / Messages: This allows to receive alerts from other systems or send messages to other systems to allow sharing of information
  • Data Sharing: This allows to send data from teams to external systems that can consume the data
  • Question / Answer Scenarios: Relates to scenarios where user can ask questions and get answers for those questions, which is really common with the chat based interface

Conclusion

In this blog, we have looked at a capability chart and solution map for components which gives us a technical and function overview of the them and some scenarios to use them. In the upcoming blog, Part 3, we will look at how we go about planning the build of a component and introduction to the SIMplE model.

Simplify building apps in Microsoft Teams Part 1 – Overview and Concepts

10-20 min read(long)

Developing Apps and extensions for business processes in Microsoft Teams is easy and flexible. This provides a greater opportunity for Organisations to build and sustain solutions without worrying about additional hosting for integration or custom build applications. The bigger challenge lies in creating the apps and solutions in Teams. In this blog series, we will look at how to improve Team development using the SIMplE framework.

Since this is the first part of the series, we will try get familiar with the Microsoft Teams Dev landscape and some of the qualms with it. In this blog, we will briefly look at Microsoft Teams Dev landscape and some of the challenges around the Teams platform. In the next upcoming blogs, we will look at how to improve this using the framework I am proposing – SIMplE

Note: SIMplE framework is not coined or promoted by Microsoft. This is a concept I came up with by working with many agile projects for Microsoft Teams Development. Actually not only Microsoft Teams projects but other projects too can benefit from it. Feel free to use it as necessary in projects. Happy to gather feedback.

Microsoft Teams Dev concepts

Microsoft Teams varied solution landscape provides us with greater flexibility to create and provides solutions at multiple ways, but it brings up a new challenge for developers such as,

  • What is the best option to implement a particular requirement – should it be a Bot or an App or a Tab?
  • What is the easiest and faster way to implement the solutions? Since Teams is all about quicker and faster outputs right 🙂
  • How to manage deployment and incremental releases in sync without overriding user experience
  • How to create a scope of scalability and flexibility with any custom components

Hence in this blog series, we will look at how to simplify and build custom Microsoft Teams solutions in a faster and efficient way using the SIMplE Framework.

In this blog, lets’ start with an idea of the Teams development landscape and look at the broad level components in Microsoft Teams. Microsoft Teams provides a wide variety of components that we could extend for building any custom requirements. Below is the high level list of these components:

  • Personal Apps / Tabs
  • Channel Tabs
  • Bots
  • Messaging Extensions
  • Connectors
  • Task Modules
  • External Hosted apps

The above options are spread out in Teams across various scopes as listed below

  • Teams Channels
  • Personal Chat
  • Group Chat
  • Personal Tabs

Below is a brief graphical representation of the Developer landscape in Teams. As it is evident in the image, the components are distributed across multiple layers and hence can be hosted and managed at each level.

Lets’ look in brief to understand what each of the scopes and components is in the scope of building a Microsoft Teams solution

Scopes

Team Channels

Team Channels are channels in Teams where we can host apps (tabs) and bots for custom solutions. We could also add message extensions that could work on a post or a conversation. As such, channels provide a great way to restrict context of discussion to a particular topic or requirement.

Some of the examples of custom components :

  1. Custom Apps with third party integrations
  2. Message extensions to search particular content
  3. Bots to have 1:1 questions or to act on a particular requests such as booking a meeting on best available time on one’s calendar

Personal chat

Personal chats are 1:1 chats with any user in the company or guest. This is a great way to share content with users and allow to use custom apps/bots for applications
Some of the example of components :

  1. Custom Apps with third party integrations with personal scope
  2. Message extensions for searching content through a repository for both the users have access to.
  3. Bots as 1:1 conversational agents to ask queries and support, for e.g. retriving user information from any system, FAQ etc.

Note: Adding bot to a personal chat with a another user makes the chat a group chat as the Bot is also treated as a user. So the best way to use bots in personal 1:1 chat is to use via Messaging extension, so could be restricted to chat messages only but giving up direct interactions

Group chats

Groups chats are chat with 1: many users. Similar to personal chats these have the same scope but the bots could act here as a user in the conversation instead of a passive agent.

Personal Tabs

Personal Tabs allow to provision a single page app or business purposed app in Microsoft teams that work on the current user context. These are same like Teams tab/apps but don’t need a Team to be hosted. This gives more of a personal context to the app. The benefit is that we could use Microsoft Teams to host apps that are specific to user personal use with deploying additional applications.
Some of the business requirements could be:

  1. Custom business apps that can work with O365 sign on.
  2. Dashboard apps that show business specific information
  3. A page from your Intranet or web apps where the code is still hosted on your hosted platform, just displayed in Teams

So above scopes gives us an idea on where to use the components and how to restrict the usage of them.

Now let’s look at the components in more detail.

Components

Personal Apps / Tabs

Personal Apps are similar to Personal Tabs in functionality, so please refer to Personal Tabs above for more informaiton. Technically, personal apps are custom built single page applications hosted on your Teams environment.
To get an understanding on configuring Personal Apps using Microsoft graph, please check here
Below are few of the key features of Personal Apps

  1. Personal Apps need a web application which could be hosted in Azure, AWS or any other hosting locations such as SharePoint. If the app is on an on-prem server, then we might have to take into account trusted locations and information exchange with the app in Teams environment
  2. These need an Azure AD app if it needs user contextual information from teams or O365 environment
  3. Will need an app package file either generated from App Studio or text editor with the details of the app. More details about will be in an upcoming blog.
  4. Personal apps cannot be shared with other users
  5. The layout could be full width of the screen except the top and left hand navigation as seen in the screenshot above
  6. Uninstalling a personal app mayn’t remove the user cache so when installed again the user might be able to restore earlier information
  7. Personal Tabs are not configurable
  8. Access to install the app can be controlled through policies. We will look at these options in another upcoming blog.

Note: Some of the Microsoft Graph Apis to programmatically deploy apps are still in beta release, so they might change.

Channel Tabs

Apps, pages, and solutions could be hosted on the team channel tabs similar to Personal Apps. The context of the component is however related to the teams and channels it is on, so we could fetch the teams context and work on it. Architecturally the structure is same as in case of the personal apps just the scope is shifted to Teams channels.
To get an understanding on configuring tabs using Microsoft graph, please check here
Additional to the features of the personal apps, below are few more additions to channel tab apps:

  1. The scope in Channel tabs is Teams context and can fetch channel and teams information
  2. The tab can be shared with other users as links
  3. One of the configurations for tab will need link to the content, website and uninstall links. This will help clean up any additional content related to the tab
  4. The tabs can be configured dynamically with properties
  5. Requires app package and deployment as Personal Apps. Please see above for more information

Bots

Bots are conversational AI interfaces which could be used to have 1:1 (personal chats) or 1: many (conversations or posts) chats and information sharing with an user. Bots could be dialog based and can be used with Azure Cognitive services to help with intelligence by language understanding, image processing or even with complex information processing. For more information on bot concepts, please check this blog.
Some of the key features of bots are:

  1. Bots can be involved by mentioning their name
  2. Bots can work in all scopes such as personal chat, group chat and teams channel
  3. Bots can be auto triggered using proactive messaging.
  4. Support for accepting files, images, speech and text based inputs from users
  5. Bots can support adaptive cards
  6. Bots need Azure hosting for the code and then an Teams app package to be installed for a team or organisation
  7. Bots can be resued on other channels and not only teams

Messaging extensions

Messaging extensions are apps that can be invoked from the message/conversation menu while writing a message or replying them. Below is a quick screeshot of it. For e.g. an user can post a gif image or praise a colleague in a message put on teams, what could be better way to praise them 🙂

Some of the considerations for messaging extensions are as follows:

  1. Allows to create content rich infomation on teams
  2. Can be used to invoke bots and other components
  3. Allows to interact an app in a conversation
  4. Support for personal, group or team scope during messaging
  5. It could be either based on a search text (Search) or from conversation context or menu (Action)
  6. Support for configurable settings that could be set while installing a messaging extension
  7. This also supports custom sign-in for connectors or third party services

Connectors

Connectors are external connections that will allow a team or channel to receive notifications, alerts or information from outside the teams environment. This is really helpful for keeping up-to-date with information for your users so that they don’t have to go find from other sources. Some of the examples of connectors could be responses to a form survey that was shared externally, share information from external systems, environment alerts, important notices that need to be broadcasted.

Some of the key considerations for Connectors are as follows:

  1. Connectors support actionable messages so action can be taken back to the source if supported
  2. Connectors also support rich cards so can be arranged or aligned to user requirements
  3. Connectors can be set per channel

Task Modules

Task modules allow to create modal pop-up experience in Teams when using a bot, connector or messaging extension. Task modules allow to put information easily on a Teams channel or app in a modal dialog without need of a custom app.
Some of the key features of Task modules are:

  1. Task modules can act as active forms and advanced than adaptive cards
  2. Task modules are like tabs inside a pop-up window
  3. The Task modules could be send via email or embed on a page and invoked via deep links
  4. Task modules support color and icon options to brand it as per purpose

Conclusion

In this blog, we got a high level overview of the components and scopes provided by Microsoft Teams for development. As we saw, there are various options to create custom applications on Teams. In the upcoming blogs in this series we will look at ins and outs of the components and pains of building apps. And then, we will see how we could use the Simple Framework to simplify it.

Happy Coding !!!

Apply custom css to SharePoint Modern Pages using SPFx webpart

With the absence of content editor web part (CWEP) or script editor web part in SharePoint Modern experience, power users have the challenge to style the page as per their requirements.

The only approach is to create a custom SPFx component that can add the custom css onto the page. That’s it !! Easy right. But how to do it? In this blog we will look at the steps  for the same and is also a link (with steps) in case to easily build it.

This adds the overhead of managing a custom component but the simplicity of the component puts all the support on the external CSS and not the webpart itself, so easy to maintain. In other words, it means that the webpart just adds the custom CSS to the page, so the CSS does all the work.

Note: The custom CSS doesn’t solve all scenarios as would the earlier Script editor or CWEP but still could do the styling part and solve a lot of alignment issues. Also another note, applying custom inline JavaScript to the page has its challenges and don’t work. We will discuss the reason of not using custom scripts in another blog, but the advise for now is not to use custom scripts.

Deployment using Code from Repo

Git Repo link

For those who would like to get the code directly or start with, here is the link to the repo. The steps to use it are simple as below.

1. Clone the repo or download the solution

2. Open the folder in Visual Studio Code

3. Then, as with any cloned code, do the following,

gulp clean

npm install

gulp build

4. If the above doesn’t result any build errors, then go to step 7, else go to step 5

5. Fix any errors in the code

6. Test the code using gulp serve. Open the workbench and test the custom CSS using property pane. For details see below step x.

gulp serve

7. Deploy the assets using Gulp ship.

gulp --ship

8. Package the solution

gulp package-solution --ship

9. Go to Code folder and migrate to SharePoint/sources and find the sppkg file.

10. Deploy the sppkg file to App catalog of your site or tenant app catalog. For more details to how to enable site collection app catalog check here.

11. Add the app to the site

12. Add the web part to the page.

13. Edit the web part and provide the CSS class path from the property pane.

CSSExtenderWebPartProps

14. Apply the changes. The css should reflect on the site.

Building your own CSS implementor

If you are not interested to copy the code from the repo and write it yourself below are the steps. The code is not complex so way to create it.

1. Create a SPFx webpart using yeoman. Recommended to use version SPFx 1.4 or greater.

2. Add a property to read the CSS Path from.

3. Next open the .tsx file from the components folder. And add the SPComponentLoader from @microsoft/sp-loader class

4. Next use SPComponentLoader.Loadcss() method to apply the custom css onto the page. Sample code below

public render(): React.ReactElement {

if(this.props.pathtocssfile!=="")

{

SPComponentLoader.loadCss(this.props.pathtocssfile);

}

}

5. Gulp serve and test the webpart

And that’s it !!

Follow the steps from above repo section for the steps to deploy the web part to the application catalog.

Conclusion

In this blog we saw how to implement custom css on a page using some quick SPFx scripting.

Happy Coding !!