This post describes one possible scenario for SharePoint-Teams -integration, how to achieve that, and what kind of issues there might be.
Teams? What’s that?
At Blue Meteorite, we at the Valo team have been leveraging Teams since early 2017 as our main communications channel. For us, it complements Yammer, email and Skype for Business quite nicely, although to be fair, it’s not always 100% clear which channel would be optimal for a certain piece of communication… 🙂
The Redmond Magazine calls Teams Microsoft’s response to Slack, and for someone who has used both, the source of inspiration is rather obvious. Built for “high-velocity teams”, it’s yet another collaboration/communication tool, but in a way more flexible than either Skype for Business or Yammer. First and foremost I’d position it as a challenger to services like Slack – and hence at least partially a new addition to Microsoft’s ecosystem.
Teams extensions governance & deployment
Distributing a Teams tab (or other app) organization-wide in Teams is extremely bothersome, if not practically impossible right now. If you don’t want to make the app public, you’ll have to sideload it. This needs to be enabled on tenant-level (Office Admin Portal -> Services etc -> Teams -> Enable sideloading), after which you can (side)load new apps/bots/tabs/extensions on a per-team basis.
Publishing an app organization-wide doesn’t seem to be possible at the moment, but it’ll come. Probably. Right now one would have to go through Store, and that seems unnecessarily complicated.
Centralized Teams configuration is really limited otherwise, too, for example:
Teams Client Configurations
Currently, there are no supported options available to configure the client either through the tenant admin, PowerShell, Group Policy Objects or the registry.
Teams expiry / archival
Right now, lackluster, but there’s more coming. Christian Buckley has a good blog post about this.
Fine-grained permissions management
There’s almost nothing. You can have owners and members in a team, but no private channels. Those are coming, though – check this out: https://microsoftteams.uservoice.com/forums/555103-public/suggestions/16911079-support-for-private-channels?tracking_code=9a24ff631f051390cd2948af93dbbc02 !
Microsoft just announced guest access to Teams channels, and as it’s now possible to invite new guest users via GUI, there’s probably going to be an API for that, too – at some point. For the sake of repetition, here’s what Microsoft says about guest access:
Beginning today, anyone with an Azure Active Directory (Azure AD) account can be added as a guest in Teams. That means anyone with one of the more than 870 million user accounts—across Microsoft commercial cloud services and third-party Azure AD integrated apps—can be added as a guest in Teams. Later, we’ll add the ability for anyone with a Microsoft Account (MSA) to be added as a guest in Teams. If the guest doesn’t have an existing MSA, they will be directed to create a free account using their current corporate or consumer email address, such as Outlook.com or Gmail.com.
Despite these shortcomings (and others, jeez), we can already achieve a lot with Teams, and at least it’s a tool that Microsoft is improving at a pretty fast pace!
Basic idea of a tab in Teams
So, on to the actual development stuff!
Of the different extensibility options in Microsoft Teams, a tab is suitable for cases where notifications aren’t needed, and where primary focus is on displaying (contextual) information and enabling interactions and workflows, that would normally be done on an external service.
In order to show any meaningful content from SharePoint (or other Office 365 source), you’ll need to perform authentication. That turned out to be messier than I expected…
Resolving authentication madness
Theoretically speaking, authentication is super easy. You get the context (from the tab), use its information to prompt authentication against Azure AD using OAuth, and BOOM you’ve got the token you can use to fetch content from Graph API.
In reality, this was a bit more complex. Because of course it was!
For security reasons, Microsoft is stopping you from including any external pages in iframes, or making any weird hops in your authentication. You just need to have a site with 1 or more pages, one of which contains a button (or something) that calls Azure AD authentication in a pop-up, user is logged in automatically OR manually, and they are returned to the same or another page, which then proceeds to use the authentication (token) to fetch data from wherever.
In practice, the authentication pop-up is blocked, fails to open, loads forever or doesn’t actually close, and instead the redirection is done in the pop-up and that’s just plain ridiculous and absolutely unusable.
How to succeed in creating a tab that actually is able to connect somewhere
So, I guess that rant was the bad stuff. Here’s the good:
You have a fair chance of succeeding, if all of the following are true:
- You’re NOT using Teams Online client in IE or Edge. Authentication pop-ups seemed to struggle with calling success/failure functions and handling redirections when in IE or Edge.
- Your Azure AD app permissions are ok and implicit OAuth has been enabled
- You’re NOT authenticating against different tenant than where your Teams is signed into.
- You’d think it works (it’s an independent Azure AD authentication, so why wouldn’t it?), but at least for me, it didn’t.
- You’re NOT using over 6 months old code examples as the basis of your solution – they’ll all be outdated by now, especially if they are using beta-API.
What can you do in the code?
First of all, Teams seems rather unfinished. There’s a decent amount of documentation, but it’s incomplete and partially outdated. Still, Microsoft is doing pretty well offering support to developers and they update the documentation pretty often.
You can make the tab do most of the things that a website can do, just don’t include iframes or weird cross-domain stuff (that’s not in “validdomains” of the package configuration), or Teams will freak out.
One possible thing would be to build a progressive web app (PWA) for whatever needs you have, and that could be consumed by a Teams tab. Bear in mind, that even though interacting with Office 365 makes sense, you don’t have to do that – you can just create a standalone web app that has nothing to do with the Microsoft stack, and still consume that in a tab.
Probably the simplest way to show users relevant content in a tab is by using Microsoft Graph. After authentication, you’ve got the access token, and you can lift content for example from OneDrive, SharePoint or Outlook.
I might write another post about the actual code needed to perform the authentication and fetch some content.
All in all, what’s the status of Teams extensibility right now?
Right now we can’t automate deployment of anything, so we can kiss all the cool, automatically deployed stuff goodbye. One can only offer some apps that could be sideloaded to Teams teams manually – or apps through store.
Creating a notification app (connector) or a simple tab isn’t too complicated. But like said, all the installations at the moment are going to be manual. And as you’ll be using beta-versions of most Graph APIs anyway, you’ll need to treat whatever you develop being in beta for now.
A couple of example thingies.
IF YOU SPOTTED A MISTAKE, LET ME KNOW. I’m just making poorly educated guesses half of the time here anyway.
- Microsoft’s article about guest access
Latest posts by Antti K. Koskela (see all)
- Thanks for coming to my session at SPS New England 10/20 ! - October 20, 2018
- Speaking at SPS New England on 10/20! - October 17, 2018
- Ignite 2018 recap: What’s new for Azure Functions? - October 16, 2018
- Problematic behavior of web.AddSupportedUILanguage(int lcid) in SharePoint 2013 and 2016 - October 10, 2018