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 !!!

Key Updates from Microsoft Build 2022 – Azure AI, Azure and Apps

Azure AI updates

Azure Cognitive Service for Language

This now provides summarization for documents and conversations, a new capability that helps developers quickly surface key information in documents and contact center calls, such as the reason for the call and resolution. More info details here
Azure OpenAI Service helps customers accelerate innovation with large AI models; Microsoft expands availability – The AI Blog

Azure Machine Learning Responsible AI dashboard

Learning to help developers and data scientists more easily implement responsible AI. The dashboard brings together multiple capabilities such as data explorer, fairness, model interpretability, error analysis and counterfactual and causal inference analysis, which help developers debug their models and make more informed, data-driven decisions. More details here –
Responsible AI dashboard: A one-stop shop for operationalizing Responsible AI in practice – Microsoft Tech Community

Cognitive Services Updates

Azure Form Recognizer has new capabilities in preview. Customers can unlock new document processing scenarios, such as streamlining patient check-in and vaccine verification with insurance card and vaccine card prebuilt models. Additionally, layout capabilities for paragraphs, headers and titles enable more precise text extraction.

Azure Bot Service and Power Virtual Agents are integrated to empower professional and citizen developers to build bots collaboratively. This integration will go a step further: Power Virtual Agents will be incorporating additional Azure Bot Service Composer capabilities, such as a new authoring canvas, rich responses, event-driven and contextual triggers and new telephony channels, to further cater to professional developers. These are all available in preview.

Azure Updates

Azure Container Apps

Azure Container Apps, now generally available, enables customers to run microservices and containerized apps on a serverless platform. Azure Container Apps is built on the foundation of powerful open-source technology in the Kubernetes ecosystem.
Azure Container Apps General Availability (microsoft.com)

Azure Communication Services updates

The Azure Communication Services Mobile UI Library, now generally available, helps save time and reduce complexity for app developers by providing production-ready UI components for mobile apps. 
Azure Communication Services Email is now in preview which will help developers building communications-enabled apps using Azure Communication Services to add email notifications to their apps
Availability of Azure Communications Sample App Builder – https://aka.ms/acs-appbuilder
Microsoft Build 2022:  Azure Communication Services updates to build faster and reach further

Azure Spring Apps

Azure Spring Cloud is now Azure Spring Apps. Azure Spring Cloud is a fully-featured platform for all types of Spring applications, and to better reflect this the service is now Azure Spring Apps.
Azure Spring Apps Enterprise tier is now generally available! – Microsoft Tech Community

Azure Kubernetes Service

Updates for seamless developer and operator experiences, anywhere with Draft 2. Draft 2 is a reboot of the open-source project that makes it easier for developers to build apps that run on Kubernetes. With Draft 2, developers can create, containerize and deploy their apps to Kubernetes.
Azure Kubernetes Service (AKS) – Updates for seamless developer and operator experiences, anywhere – Microsoft Tech Community

Azure Service Bus Explorer

Service Bus Explorer capabilities are now generally available in the Azure portal. Developers can now use the portal to specify a Service Bus namespace and then send messages to a queue or topic in that namespace, as well as receive or peek at messages from a queue or a subscription.
Announcing Service Bus Explorer for Azure portal public preview – Microsoft Tech Community

Azure API Management and App Service Updates

Protect, Augment, and Build GraphQL APIs with Azure API Management – Microsoft Tech Community
What’s New in Azure App Service at Build 2022 (microsoft.com)

Azure Data Updates

Microsoft Intelligent Data Platform

The Microsoft Intelligent Data Platform is a new, integrated platform that unifies databases, analytics and governance, empowering organizations to invest more time creating value rather than integrating and managing a fragmented data estate.
Introducing the Microsoft Intelligent Data Platform | Azure Blog and Updates | Microsoft Azure

SQL Server 2022 public preview

SQL Server 2022 is the most Azure-enabled release of SQL Server yet, with continued innovation across performance, security, and availability. It is part of the Microsoft Intelligent Data Platform, which unifies operational databases, analytics, and data governance.  
Announcing SQL Server 2022 public preview: Azure-enabled with continued performance and security innovation – Microsoft SQL Server Blog

Database Updates

Announced at Microsoft Build: New features for scalable, cost-effective application development – Azure Cosmos DB Blog
Streamline development on Azure SQL Database (microsoft.com)
Announcing Azure Database for MySQL – Flexible Server for business-critical workloads – Microsoft Tech Community

Azure Synapse Analytics

Azure Synapse Analytics is a limitless analytics service that brings together data integration, enterprise data warehousing and big data analytics.
Microsoft Graph Data Connect makes it easy for Microsoft 365 customers to harness the power of their organizational data by moving it into Azure Synapse where they can uncover new actionable business insights that could improve customer satisfaction, increase productivity and optimize business processes.
Azure Synapse Link for SQL enables near real-time insights by eliminating barriers between operational data stores and Azure Synapse Analytics. 
Announcing the Public Preview of Azure Synapse Link for SQL – Microsoft Tech Community

Developer Tools

Microsoft Dev Box will give developers self-service access to high performance, cloud-based workstations that are preconfigured and ready-to-code for specific projects. Azure Deployment Environments will make it easy for developer teams to quickly spin up app infrastructure with project-based templates that establish consistency and best practices.
Introducing Microsoft Dev Box

GitHub OpenID Connect (OIDC) with Azure Active Directory (Azure AD) workload identity federation, now generally available, minimizes the need for storing and accessing secrets. The new capabilities alleviate the need for managing Azure service principal secrets and other long-lived cloud credentials in the GitHub Actions secret store.
GitHub Codespaces is a solution where your developers can securely interact with non-trusted code inside a sandbox environment. This cloud-powered development environment is available anywhere, on any device. 
DevSecOps practices with GitHub and Azure (microsoft.com)

.NET Multi-platform App UI (.NET MAUI), now generally available, is a new framework for building modern, multi-platform, natively compiled apps for iOS, Android, macOS and Windows using C# and XAML in a single codebase.
Introducing .NET MAUI – One Codebase, Many Platforms – .NET Blog (microsoft.com)

Developer Assisted AI tools as below,

  • GitHub Copilot usage data from the technical preview and updates on general availability. Information on the research project Copilot Explain, which translates code into natural language descriptions, helping novice developers or those working with an unfamiliar codebase.
  • OpenAI Codex, a model that translates natural language into code across more than a dozen programming languages.

How AI makes developers’ lives easier, and helps everybody learn to develop software – The AI Blog (microsoft.com)

Conclusion

In this blog we looked at some of the great updates for Azure AI, Azure, Apps, Data and Developer tools as announced in Build 2022. In the next blog, we will look at the some of the Microsoft 365 updates

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 !!!