Teams Nation reaches 1000 registrants, and will be returning April 6th 2022

The excitement for Teams Nation is building. Today, we discovered that we had surpassed 1000 registrants, which is absolutely amazing considering that just a few weeks ago we thought that we may not have been able to run Teams Nation at all. Now that the dates for Microsoft Build have been officially confirmed (25th - 27th May) we can disclose that we discovered these dates via a leak online and had to make an immediate call on whether to stick with the date of 26th May, whether to reschedule or whether to cancel it outright. Since we had committed to doing another event last October - the first since we changed the name from TeamsFest to Teams Nation we really didn't want to can it since we had been working on it since the new year. We also decided that it would be unfair to make attendees choose between Teams Nation and Build as we thought many who would register for our event would ultimately like to attend both. So we ended up bringing Teams Nation forward by two weeks to Wednesday 12th May. Our choice on this date is mainly due to when all of us were available, as well as avoiding conflicts or being too close to any other events that we were aware of in the calendar

Teams Real Simple with Pictures: Using the TAC to manage users backgrounds in Teams Meetings

A real short one this week - for two reasons. The first is that I am on annual leave - and whilst annual leave may conjure up the romantic idea of taking a break, this is when I usually crack on with the long list of things which I need take care of at home. This Easter weekend has included completing a 6 x 8 concreate base for a shed, and putting up a large trampoline in the back yard for my son. Secondly, I was all up for writing an in depth blog for Viva Connections - and I started doing that until I realised that the SharePoint app bar hasn't surfaced in my demo tenant yet. I decided I didn't want to push something out that I wouldn't be ultimately happy with. So in the meantime I was searching for something to write about when I saw that the ability to control meeting backgrounds has now come to the TAC. For some time this has only been available in PowerShell - and whilst this blog will literally be up there with the shortest I have ever written, the functionality is really important to consider for all organisations. Why? You see when custom backgrounds were first released there were a lot of people on social racing to advocate how these could be back doored on windows machines. And whilst I agree they were great for identity and personalisation, and great for marketing and buy-in in regards to adoption, I also agree they can be problematic for IT admins. How can they be policed? How could you stop someone in your organisation uploading something offensive as a background? Whilst I hope you haven't seen anything offensive I personally have. I've seen someone outside my organisation using a hospital ward as a background because they thought it was funny to do so during lockdown. I've seen another - again outside my organisation - using politicised images which aren't appropriate nor professional for any type of meeting. Where have they got those images from? Are they commons or are they copyrighted? So we need to make a call, especially as Microsoft Teams does not screen backgrounds which are uploaded by users. Surfacing these in the TAC is good in that it brings attention to these controls, but also helps admins which, let's face it, don't like PowerShell or don't read Docs all too often. Every IT admin now has the ability to easily control backgrounds based on the tools they like to use

Teams Real Simple with Pictures: Setting Table Permissions for Dataverse for Teams Apps such as Bulletins or Employee Ideas

Last month I wrote a bit about the new Power Apps Templates in Teams - Bulletins and Employee Ideas, and last week I discussed Applying DLP policies to the environments these apps are housed in. Now It feels pretty natural to continue this conversation about data and discuss Table Permissions within the apps themselves. This is because it's these permissions which determine how users inside and outside the team - and guests - can work with the apps and the data that they contain. Firstly, it's important from a usability perspective that we can granulate access. Think of the following scenario - one team member needs full access over one app in the environment because they are managing it whereas that same user may only need read access over another because they don't need to touch any data within it or add any data to it. You may also want team members to be able to modify data with a specific part of the app - for example links in Bulletins, and not in others. This is all possible with table permissions. Secondly, it's also important from a security and compliance perspective. We want the users we need using the app in the way we specifically need them to use it. Circling back to the DLP conversation last week whilst we want to trust that others will handle the apps and the data within them in the right way, having carte blanche in terms of permissions, or even having permissions for certain users, or guests, at all opens things up to all sorts of risks including insider threats. Like DLP, this is certainly something we want to think about when we deploy, or when we are sharing it outside the Team

Teams Real Simple with Pictures: Using Data Loss Prevention (DLP) to stop data leakage from Dataverse for Teams Apps such as Bulletins or Employee Ideas

Last month, I wrote a bit about the new Power Apps Templates in Teams - Bulletins and Employee Ideas. I really liked them. They are really useful for bringing in new functionality for Teams and filling some gaps, they can be used by both users inside the Team where they are deployed or outside of the Teams via the broad distribution functionality. They can be extended by developers looking to build on the functionality which already exists. However, in thinking about how these apps can be extended we must also put our security and compliance hats on and think about how the ability to extend them can be controlled - particularly in terms of connectors and data leakage. You see, when we start using these apps we will begin adding data - company data. In the case of bulletins we add things like company news, URL's and even contact details. In the case of employee ideas we add ideas about how the company may improve and these ideas could - for example - be based on company data or expose where the company is lacking. Whilst we like to believe that everyone who has access to modify these apps have the best of intentions, it is too big a risk to simply assume that data will never be exposed - accidentally or maliciously via connectors to places where it shouldn't be seen to audiences who should not see it. A good example is Twitter. Our data makes it onto Twitter it could seriously damage our brand and we could be facing some legal consequences

Teams Real Simple with Pictures: Using List Rules and Exchange to keep the Team up to date on changes

It feels good to be back on a somewhat even keel. Winter has been absolutely crazy - and after the Microsoft Teams Winter Tour and Ignite I had to take a short break to play what I call the containment game. You know the one. Batting everything out whilst simultaneously closing everything down. It's stopping that accumulation of work from getting out of control. I am happy to say that's now done. I won. It's back to business as usual. So what should we talk about first? There is a lot of things given that Ignite is now over - and if I were others maybe I would go for the latest and greatest, yet having wanted to discuss it since it's recent release and having had no bandwidth to do so I have settled on List Rules and how we can notify the Team of changes to the list. Something straightforward and doesn't take long to write home about. So Rules. Rules are defined by Microsoft as having the purpose of 'automate [ing] tasks such as sending someone a notification when data changes in the list'. In other words, they are very likely replacements for Alerts which have been around a long time and are legacy functionality stretching back to classic SPO and SPO Lists. Now, this blog won't cover every possible scenario for a rule. There's no point - it's super simple and as you go through this blog you'll see how easy it is to implement rules. What I am more interested in is notifying the team of changes rather than individuals: either in Teams or via email. What's that? This can be done by Power Automate and we could create a flow and do it that way. Absolutely. Yet this would suggest whoever is implementing it knew how to do that and had the time and inclination to do that. For me, a lot of what I hear is people want to just do things there, on the List. So Rules for simplicity, Power Automate for anything more