Teams Real Simple with Pictures: Getting Hands on with Profile+

So Build is done. It's in the books. I just finished up my last session moderating which was one of those sessions at the back end of the conference. You know the ones. Less attendees, but every one of those attendees die-hards still asking awesome questions to get every last ounce of value out of the event. I remember the first time I was out in Vegas at Inspire. I was still there at the Mandalay doing sessions on the Friday morning when others were still in bed conferenced out or were checking in at the airport to go home. And you have to hand it to the speakers who still show so much passion at the end probably having just done the last few days on about 4 hours sleep a night. So signing out of Build, I wanted to complete a trio of blogs on the new Power Apps for Microsoft Teams which were announced at the conference. The first blog was on Perspectives. The second was on Boards. This one is on Profile+

Teams Real Simple with Pictures: Getting Hands on with Boards

Day two of Build. It's a good one. And I have the opportunity of following up yesterday's blog on Perspectives with one on Boards. This is the second of three blogs on the three new Power Apps Solutions introduced at Build, and which I think are really building (excuse the pun) on the success of others released over the past six months. I am talking about Bulletins, Milestones, Employee Ideas, Inspection and Issue Reporting. If you haven't used them yet, they are Power Apps within the Teams App store which you can install and which are deployed in Dataverse for Teams. The great thing about these apps is that you can go on and extend their functionality, you can widen their use in broad distribution scenarios, but what is also really cool is that they are straightforward and you can simply use them straight out of the box. They are designed for a specific purpose. So let's get to it for today

Teams Real Simple with Pictures: Getting Hands on with Perspectives

Today at Microsoft Build it was great to run a Table Talk with Vesku Nopanen, Reza Dorrani, Mar Llambi, Karoliina Kettukari and April Dunnum. Lots of people showed up. I think - and I say think - we answered most questions. The chat was moving so fast that Reza, Mar and I were leapfrogging each other trying to answer them in time. There's a lot of interest about Dataverse for Microsoft Teams - particularly the apps which can be installed in them and extended with by Fusion Teams - Teams which are mixes of citizen and professional developers. Now some of these apps you may already know and used, and some of them I have already written about: Bulletins and Employee Ideas. There's Milestones too and a few others. Today, at Microsoft Build, three more were announced. Profile Plus, Perspectives and Boards. Over the next few days I am going to write about all three and all three are available in preview. Today I am going to cover Perspectives.

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