This is part of a blog series explaining a new open source solution (located here) for provisioning Microsoft Teams. The solution is based on Azure Functions which communicate with Microsoft Flow (or really anything) using Azure queues. This allows a Flow, PowerApps, or Logic Apps developer to use whatever logic they wish and, when a Team is to be created, queue a message to an Azure Function which will do the work.
This is Part 2 of the series:
Today I’m happy to share a new open source solution (located here) I’ve been working on for provisioning Microsoft Teams. The solution is based on Azure Functions which communicate with Microsoft Flow (or really anything) using Azure queues. This allows a Flow, PowerApps, or Logic Apps developer to use whatever logic they wish and, when a Team is to be created, queue a message to an Azure Function which will do the work.
This is Part 1 of a five-part series:
As you probably are aware, SharePoint site scripts are used to set up content and settings in SharePoint sites. They’re applied using site designs, which allow the same script to be reused with different names and permissions. Site designs can be applied when a site is created, when it’s added to a hub site, or on demand via PowerShell or the SharePoint UI.
This post was part of the “30 Days Microsoft Graph” blog series, now cross-posted to my personal blog. I was thrilled to have the opportunity to contribute to this excellent blog series. Many thanks to Brian Jackett, who organized this excellent blog series, and to Srinivas Varukala, who kindly edited my articles. In addition, thanks to others from the Graph and Azure AD teams who helped to test and QA the articles.
In Part 1 you learned how to register apps for both Azure AD v1 and v2 that can be used from the browser to enable Graph API calls. Today, we’ll use those registrations in some simple applications.
This post was part of the “30 Days Microsoft Graph” blog series, now cross-posted to my personal blog. I was thrilled to have the opportunity to contribute to this excellent blog series. Many thanks to Brian Jackett, who organized 30 Days Microsoft Graph, and to Srinivas Varukala, who kindly edited my articles. In addition, thanks to others from the Graph and Azure AD teams who helped to test and QA the articles.
In this article and the next, you’ll learn how to call Microsoft Graph APIs directly from a web browser in a Single Page Application much the same way that the Day 15 article showed how to call Graph from a .Net Core Console Application. This article will walk you through updating your app registrations (for v1 and v2) so they’ll work from the browser; in Part 2 we’ll dig into the code.
Modern SharePoint is catching on, and sites are looking better than ever right out of the box. With mobile-ready pages and easier editing, customers and partners are starting to ask for it. And as SharePoint 2019 brings the modern experience on premises, the demand is likely to grow even more.
Yet even as sites look better than ever “out of the box”, there are constraints on how they can be customized. Partners and customers who want to completely change the look sometimes run into these boundaries and get frustrated.
This article is the sequel to Swooping into SharePoint Site Designs, in which I related my experience working behind the scenes on the world’s first SharePoint reality show! This time I’ll explain the code so you can build similar solutions if you so desire.
The sample shows how to build a site design and script for a simple department site, as created in the SharePoint Swoop video. A team of experts worked to redesign an Intranet site in just three days. This site design was developed behind the scenes to provide a template for all the company’s department sites.
A few months ago a group of SharePoint MVPs gathered to film a new kind of reality TV show and remake a company’s Intranet. You may have seen it – SharePoint Swoop!
This is a story from behind the scenes,in which I got to make their work reusable with SharePoint Site Designs and Scripts. It was quite a thrill to be involved, even though I wasn’t there in person! I’ll start with the story, then dig into the details of Site Designs and Scripts.
Traditionally, our collaboration tools have been divided into silos based on the mode of communication. In the Microsoft space, we’ve used Outlook and Exchange for persistent messaging, Skype for Business for real-time communication, and SharePoint to provide a place to share documents and other information.
These tools work together to provide for our communications needs, whether they’re real-time, message based, or documents and other content. They work well together, but they’re still separate programs we have to run, and constantly flip between. As we do, the information is organized differently in each tool: most of us view email by date, Skype by person, and SharePoint by project or team. That’s a lot of context switching. Of course we’re all used to this, and probably don’t even notice how much of our attention goes into it.
A lot of people have asked for “private channels” in Microsoft teams. Microsoft has stated publicly that they’re working on it; there’s even a page in the documentation all ready for when it comes along!
In the meantime, a question came up about using SharePoint permissions to restrict the level of access to channel files. Recall that every Team has a SharePoint site, and the files in the Files tab land in a document library on that site. Each Teams channel gets a folder in that site. (For more details see this article by Matt Soseman.)
So is it possible to make a “semi-private” channel by simply modifying the folder permissions in SharePoint? The idea is that while the conversation might be open, the files are only available to a subset of team members.
Bob German's Vantage Point 