In my last post we looked at the return on investment for Copilot for Microsoft 365, specifically in terms of time savings required for the $30/£24.70 per user per month licensing investment to make sense. In this post I want to turn attention to extending Copilot and getting started in the world of Copilot plugins. Copilot for Microsoft 365 can become even more powerful when integrated with other company systems - I created the slide below recently for a deck I was working on, and the four areas provide ideas on where the value might be and potential scenarios:
However, at the current time (February 2024) getting started with plugin development is a bit gnarly - there's lots of documentation to read and there are some interesting practicalities to consider. I’ve spent some time on this, and the sections below give a quick summary of initial findings which may be helpful for anyone else going down this path.
Tenants and licensing
Much of the initial complexity falls into this bucket. Things to know include:
-
Copilot plugin development needs production Copilot licenses, there’s no way around this. This may mean developing in your production tenant (if you are a licensed user) or buying extra Copilot licenses for other tenants
- Microsoft 365 Developer tenants cannot be used for plugin development
- If you’re on the Microsoft 365 Developer TAP (we are at Advania), these tenants can be used but you still need to buy Copilot licenses in that tenant
- In addition to the core Copilot license, the user also needs to be assigned a "Microsoft Copilot for Microsoft 365 developer license"
- Copilot for Microsoft 365 licenses effectively grant “Copilot Studio use rights” – importantly, this allows you to create and run M365 Copilot plugins only, not to run standalone Copilots (see note in the blue box below)
- Since plugin development is still in preview, production tenants need to be enabled for it via a special helpdesk ticket - there's special wording to use, indicating this is somewhat hand-cranked in the backend for now (see the Copilot extensibility prerequisites article linked at the end for the exact words to use)
Developing standalone Copilots (not plugins)
Coming the other way round from the plugin focus of this article, the other primary use of Copilot Studio is to develop standalone Copilots using a low-code approach. Examples could be a HR chatbot providing answers on policies and internal benefits and hosted in Teams or a SharePoint intranet page, or a customer service chatbot on an external website providing answers from a knowledge base of uploaded documents. In these cases, you don't need a Copilot for Microsoft 365 license but you will instead be paying the $200/£165 per month run cost, which gets you 25k messages across all such Copilots (with additional capacity charged extra). There's a bit of nuance in what constitutes a message - a typical interaction counts as one message but invoking gen AI counts as two - but in short you are calculating based on expected usage.
The image at the bottom of this article more directly compares the two flavours.
Building Copilot plugins using the Power Platform (low-code)
The prospect of using low-code for plugin development is very appealing. In this space, note the following:
- Power Platform connectors can be turned into Copilot plugins by converting them to be a “Connector AI plugin” – whether custom or pre-built connectors (e.g. ServiceNow, Zendesk etc.)
- However, today connectors need to be certified – meaning custom connectors cannot easily be used for plugins, since certification is a complex process for major ISVs (i.e. not internal teams or partners simply trying to create solutions for a single organisation)
- Additionally, only read-only actions are supported for now
- Other Power Platform approaches are possible – using Power Automate Flows, the new AI prompts capability etc. in Copilot plugins. However, again this does not seem to be possible at the time of writing unfortunately
Building Copilot plugins using Teams message extensions (pro-code)
The alternative architecture for Copilot for Microsoft 365 plugins is based on Teams development, specifically Teams message extensions. This makes sense, and before the dawn of GPT we've used this approach at Advania UK to build other conversational bots in Teams. Some details to be aware of here:
- The advantage of Teams message extensions is that plugins with more advanced UI can be used (e.g. adaptive cards in AI responses)
- Conceivably, the solution you build as Copilot plugin could also be a regular Teams message extension in Teams chat and be surfaced in Outlook - enabling you to provide your experience in different ways within Microsoft 365
- Teams message extensions are the right approach if you're working at scale (with large volumes of data or user load)
- Permissions - if you are developing your plugin using Teams message extensions, you’ll need the ability to side-load apps into the tenant
So that summarises some of the initial considerations in getting started with plugin development. It's also worth noting that Microsoft are pushing to create an entire ecosystem around plugins with marketplace approaches, meaning plugins can be sourced from internal developers, partners, specialist vendors and so on.
Also remember, Copilot extensibility is not just about plugins
All of the options and considerations above relate to plugin development, but this sits alongside the alternate path of bringing data into Copilot for Microsoft 365 using Graph Connectors. In that approach, the data you integrate is indexed (stored in the semantic index which sits behind Copilot) rather than simply being available via a read/write call-out of some kind. Graph Connectors bring other advantages such as making the data available in Microsoft 365 search, Viva Topics, Context IQ and even being used for content recommendations in Microsoft 365, but if you're working with data at scale you'll to purchase additional Graph Connectors index quota (you get 500 items for free per E5 or Copilot license). Microsoft's article
Choose your extensibility path expands on these considerations.
Zooming out from plugin development in a different way, it's worth considering Copilot Studio as a whole since it's not just about Copilot for M365 plugins.
Copilot Studio - varying audiences, varying outputs
Copilot Studio can be slightly confusing in the Microsoft AI space because it's used to create different solutions and experiences - essentially including Copilot for Microsoft 365 plugins and standalone Copilots built with low-code. Many people recognise it as "what used to be Power Virtual Agents", but between licensing variations and what can be created there's a bit more to it than that. I posted the following on LinkedIn which summarises the two major usages of Copilot Studio:
That hopefully gives a sense of things from a Copilot Studio lens. Some of this is made clear from this table in the Power Platform licensing guide - see the image below, and note specifically that the output formats and available channels are different between the two paths, and that Copilot plugins using Power Platform approaches can use Standard, Premium and Custom connectors:
Summary
Extending Copilot for Microsoft 365 with plugins can be a great way to derive additional value by integrating systems, and opens the door to the possiblilty of Copilot becoming a universal interface for all of the apps and platforms an employee works with. The next few years could see significant changes to the employee experience in this regard, at least for organisations making the investment in Copilot for Microsoft 365. Other forms of Copilot can also be created - standalone Copilots (as Microsoft refer to them) are often focused on a particular business domain or use case, and can reach a broader audience because they surface in different places and don't rely on Copilot for Microsoft 365 licenses. Both experiences are created by makers/developers in Copilot Studio, but there are licensing and reach differences - and today, some things aren't quite in place (early 2024) because we're still in a preview phase for plugin development. No doubt the path will get smoothed out as we go through 2024.
References