Did you know that you can use Power Automate for free? Yes.. It’s available for free for personal accounts like Hotmail, Gmail, etc… To get started with it, visit one of these two links:
At the top of the page there is a try free link, when you click on it, you will see a textbox where you can type your email. Type your Gmail or Hotmail account there
Once you write your personal email and click “Start free” the page will prompt you to use a work or school account or continue with this personal email. Click Continue.
The next page will ask you to sign in with a Microsoft account or create a new one. If it’s your first time using your Gmail account to use a Microsoft service, you will want to click on “Create one”.
Now why are we creating a new account and how are we creating a new account with our Gmail email? In order to work with Power Automate, Skype or Xbox for example, you needed to use something called “Live ID” which is now named as Microsoft Account. You can use your Gmail account to create this Microsoft Account. Screenshots below show you the wizard that takes you through the process of creating this Microsoft account with your Gmail account. Note that later you will keep signing in with your Gmail account so this is just a one time process.
After the creation of the Microsoft account, you will be redirected to flow.microsoft.com and you can get started:
If you go to outlook.com and sign in with your Gmail, you’ll notice that you can actually sign in:
Now what can we use in Power Automate with our Gmail account? You can use all actions that are open for consumer accounts, for example the outlook connection, Twitter connection or Gmail connection and so on. You won’t be able to use things like SharePoint or Office 365 Outlook connection. Note that if you use the O365 Outlook connection for example to send an email, you won’t get an error however the action won’t run.
We’re used to importing React into our web parts using this syntax:
import * as React from "react";
But did you know we can also do it using this syntax:
import React from "react";
How’s that possible? Let us talk about the difference first.
import something from “library-name”; is used to import the default export from that library. A “default export” is that thing that is marked as “default” when exporting code from a module. For example, you might see in a module file an export that looks like this:
export default MyClass;
Now when importing it, you can do it with import myclass from ‘MyClassModule’;Basically, the import something from “lib-name”; is a short hand for this:
import {default as something} from "lib-name";
As long as there is a default export, you can use import something from ‘lib-name’;
Now how about the other syntax (import * as something from “lib-name”)?
This is written when the library does not have a default export, but rather exports multiple objects together; for example, you might have the export looking like this:
export { something1, something2, something3}
See? No default export there.. so you you will need to import all (*) from that module. Which is the case with React.. If you go to React’s source code on Github: react/index.js at main · facebook/react · GitHub you will notice that they do not have export default in their file. But.. why can we do it in SPFx web parts?
The reason is, starting with TypeScript 2.7, there is a property in the tsconfig file that allows the compiler to analyze the exported package and treat the whole package as a default export, so you do not have to write the longer syntax (export * as), this property is called allowSyntheticDefaultImports, and as long as it is set to true, it will allow you to do that!
Holding events is a crucial task for any environment to keep employees up to date with everything taking place in the firm, however what do we do when we have too many departments, each having its own set of events? In this case an events centre to consolidate events is a good way to think about it, and this is what we did at BDO Canada!
Many companies like BDO have many departments, from Taxes, BDO Law, Industries, Digital office .. to IT, Marketing and Human Resources.. just to name a few! Each department has its own events going on and each department is its own hub site with more associated sites connected to it.
Our plan was to create yet one more site, name it Events Centre as part of the Intranet Home hub site that will show events across ONLY hub sites. For example, we have an Industries hub site, “under” that industry site we have associated sites such as Agriculture, Cannabis, etc..
You can use an Events web part on the Industries site to show events across the hub itself, this is a setting that’s available on the Events web part to show events across all sites in the hub:
Now what we want to appear on the events centre is a rollout of all “Intranet” events. To do that we created a content type specific for “Intranet Events”. To have that, we’ll need to create a content type inheriting from the basic Event content type and add it to each Events list and make it the default content type. On top of that, we want to have our own categories, because the categories that exist by default in the Events list don’t match our needs. So to achieve this, we used PnP Provisioning Templates in combination with PnP PowerShell.
PnP Templates will provision everything to the department sites once they are created such as any required site columns, content types, modifications to lists/libraries such as adding content types to these libraries, adding the custom event content type to the events list and making it the default, adding page templates, pages and so on.
The PnP PowerShell will do extra work such as changing the category column values (plus other extra stuff we needed it to do). Now we have a consistent structure for all departments created and all of them have the same content type. Back to our Events centre, we can place an Events web part for each category filtered by that categories name.
In fact we can use the category right without having to create a custom content type, but if you want to make your events scalable for later (for example, get all “Intranet” events in Search) then having your own events content type is very handy.
The end result of this would look like:
One catch is when you filter a category that contains a character such as “-“, you’ll need to replace the – with a space. For example, “Firm-wide” category will be filtered as “Firm wide”.
Notice that the categories don’t represent departments. They are shared across all departments in the environment. With the help of PnP Provisioning templates and PnP PowerShell Scripts we are able to keep this consistency across all departments.
Hope this would inspire you on the possibilities of things you can achieve with such a simple web part like the Events web part.
Feel free to reach out if you need to implement a similar functionality in your environment or if you have any questions, It’d be my pleasure to discuss it with you!
As discussed in the previous post, we can enable developers (and users) to upload custom apps to Microsoft Teams. However, sometimes (and most often) you don’t want to enable everyone to upload custom apps everywhere. This is where Teams enables you to have granular control on who can do what.
First step is to ask this question:
Did I block custom apps at all in my environment?
The very first option that you will need to be aware of is the “Allow interaction with custom apps”. This setting is found by going to the Teams Admin Center > Teams Apps > Manage Apps > Org-wide app settings:
Once this setting is enabled in your tenant, you can now move forward and control who can upload custom apps. If this setting is off, then you won’t have a way to upload custom apps to your tenant, so if you need to upload apps, you’ll need to make sure this setting is on. (Note, in cases when you want to stop uploading apps altogether to the tenant, you can always use this option to shutdown this capability)
Now with this option enabled, in order for a user to be able to upload a custom app, you’ll need to ask this question:
Is the user assigned a custom policy that allows him/her to upload an app?
The user will need to be assigned an app policy that has uploading custom apps enabled.
This can be done by going to Teams Admin Center > Teams Apps > Setup Policies. By default, developer tenants will have this policy enabled by default, but if you want to sideload apps in other tenants, you’ll need to have at least one policy where “Upload custom apps” is enabled.
Once you have the policy set to upload custom apps, go back to the policies list, select the policy, and add the user you want to grant this access to for this policy:
After you add the user to the policy. The user will be able to upload custom apps depending on the answer of the upcoming question:
Will the user need to upload personal apps only or teams apps?
If the user needs to upload personal apps only, then it’s all good so far and the user can do so. However if the user needs to upload custom apps to a Team and that user isn’t an owner, then the Team owner should enable the option for members to upload custom apps. This can be done on the Team settings itself:
For a better understanding for those who prefer visual sequence, you can consult the following diagram:
I hope this helps someone out there! Enjoy Teams App development!
We hear the term “Sideloading” when it comes to Microsoft Teams, we even used to hear that when talking about SharePoint apps. So what does it mean to sideload an app in Teams and who can do it?
The “normal” way of uploading an app to the tenant in Teams is to upload it to the organization app store without sideloading (we’ll talk about sideloading in a minute). In the organization store, it will be available to the all tenant users to install. You can view all tenant apps when you click on Apps in the left-hand rail in Teams client, you will find your custom apps available for the current tenant under a section named: Built for [Tenant Name]
To upload an app to the organization store, you can do it from the same page, by clicking on “Upload a custom app” then click “Upload for [Tenant Name]”
You can also do the same from the Teams admin center by clicking on Teams apps > Manage apps > Upload:
Now.. what if we’re developing an application and we want to test it in the scope of a team or a personal scope? We don’t want to upload it to the whole tenant rather just to a specific team. That’s what sideloading does, it allows us to upload an application to a team or personally without showing it to the whole tenant.
This setting is controlled in Teams Admin Center, if you go to Teams Admin Center > Teams apps > Setup policies. You can create a new policy and ensure to enable the setting “Upload custom apps”. Upload custom apps is just the equivalent of “Sideloading”. After you create the policy, assign it to yourself (or any person that you would want to upload custom apps):
In developer tenants, you will notice that this option is already enabled through the “Global (Org-wide default)” policy:
After you enable the policy to upload custom apps and make sure it’s assigned to you, when you go to the Apps section in the Teams client, and click on Upload an app, you will notice the option to “Upload for me or my teams”:
Note that enabling sideloading might take sometime for the new option to show up in Teams. (up to 24 hours).
Also remember, you can control who can sideload apps in teams by assigning users to the new policy you created in Teams admin center. In the next post, we’ll go over policies and settings that enable us to have more granular control on who can upload apps to our tenant. See you in the next post!
If you work with multiple tenants and for each tenant you login with a different account, you might want to have a smooth way to use Teams across all of these tenants. One way to do it is by adding the Team as an App. In this post am using the new Edge browser (Which will be the default browser on Windows in April). But the same thing can be done with Chrome as well.
Let’s say you use Teams client with your main account, in my case @bdo.com but at the same time I’d like to login to Teams on my personal dev tenant @technifier.com. To do so, I can go to teams.microsoft.com and login with my @technifier.com account. Once I have Teams open there, click on the options menu and click on Install this site as an app:
Now it will install this browser instance as an actual application on your computer. You can now give it a name, in my case Technifier Team
You will notice that it opened in your taskbar as an actual application, now you can just right click it and pin it to taskbar.
There you go. You can even search for the application in Windows and it will appear as a regular application:
Note, if you’re not getting notifications when someone sends you a message on that Teams instance, make sure you’re allowing notifications from Teams in your browser. To verify that, go to the browser options list, and click settings:
Search for notifications, and make sure notifications are allowed for teams.microsoft.com:
Now when someone sends you a message, you’ll get a Windows notification:
When dealing with external users in Microsoft Teams, you would find yourself having to add users to your Teams, and when this functionality is enabled across your organization, you would want to have a way to review this access in order to have more control on who can access resources in your environment, in this case, it’s Microsoft Teams.
The way we can do it is by utilizing Azure Access Reviews which is available in Azure AD Premium P2. By using Access Reviews, we can create a policy to remind Teams Owners or basically anyone in the tenant to be responsible for reviewing the guest access on these teams. We can choose to review all teams guest access in the environment, or select specific teams. We can schedule the access review to be done on regular basis and having decisions made upon review completion. For example, if a guest is denied access to one Team, then remove the guest completely from the tenant or just remove the guest from that specific Team.
Let’s dig into how this actually works. I’ll first invite a Gmail user to my Team as a guest user:
Users will get an email notifying them that they were added to the team:
Note that even as a Gmail user, you can be added to multiple tenants, and sign in with your Gmail account, you will be able to see the tenants just like any normal Teams user who’s using his/her Microsoft 365 accounts:
Now, we’d like to review this Employee Onboarding Team, since, let’s assume it contains lots of guest users. Remember we can set the review access to be done across many teams that have guest users, but in our scenario we’ll do it just one for one to demonstrate how it works. Head over to Microsoft Azure AD, click on Identity Governance, then click on Access Reviews:
Now we’ll need to create a new Access Review, so we’ll click on New access review and choose Teams + Groups. It will ask us if we want to create the access review for guests across all Teams or just select specific Teams, in our case we’ll select a specific team and set the scope to Guest users only.
In the reviewers selection, we can decide if the group/team owner should be the one doing the review, or select a specific person, or even let users review their own access. In preview, it allows current user’s manager to review their access, which depends on the manager’s property in the user’s profile.
Next comes the scheduling, and how it works is that you define the recurrence, to either happen one time or on a Weekly/Monthly/Quarterly/Semi-annually or Annual basis. So in my case I’ll define Weekly and set the duration to 3 days. 3 days means that the reviewer will have 3 days to review the status, after that there’s a job that will run and make a decision upon the current reviewers selection. I’ll get to this point later in this post but let’s continue with defining the schedule. You can choose the start date and the end date of this schedule, and then hit Next.
The next page tells you if you want to apply a decision to the resource (being user’s access to that resource), so make it enabled. There’s also an option on what to do if the reviewer doesn’t respond, which allows you in this case to choose on whether to keep the user’s access to the resource (the team) or deny it. The next option defines what happens when the access is denied which is really cool. You can define if the user’s permissions is removed from that team but still gets access to your tenant as a guest or being removed from the tenant completely.
Other options on the page are self-explanatory, however one thing that is worth mentioning is the decision helper, which will provide you with recommendations when you actually start the review process and will advise you on whether to approve or reject the access. Now you can give your access review a name and hit Create, and we’ll have our access review ready.
Now when the date of the review arrives, you as a reviewer will receive an email asking you to start the review process:
When you click on Start review you will be redirected to Access reviews page where it will list all the reviews that you need to complete. In my case I’ll deny the access for this user even though the recommendation by Azure is to approve it (remember that you can enable recommendations when you configure the access review):
Now here’s the catch. Even though you clicked on deny and you expect the user to be removed from the team, it won’t be removed.. why? This actually confused me at the start, but the actual decision is applied when the review period ends. So if you set the period schedule to weekly and the period duration to 3 days, it will wait for 3 days until it acts upon your decision even though you made the decision on the first day. So you actually have sometime during the period to change your mind and approve the user’s access again. When the period ends, you will get an email telling you that the review ended and your decision will be applied to the resource (the team):
Now that the review decision has been applied, head over to Microsoft Teams, and you’ll see that the guest user is gone! Such a nice way to do reviews across many teams which is really beneficial for large organizations with many guest users all over the place!
In this blog post, we will learn how to apply naming conventions to our teams. As large organizations have special needs on what teams’ names would be in order to easily manage them, it’s essential for teams admins and even anyone who is working professionally with Microsoft 365 to know how it’s done.
The ability to apply naming convention to Microsoft Teams is done by applying a naming policy on groups in Azure. Once the policy is applied on the groups then any newly created team will be constrained by these rules. Any existing Microsoft Teams won’t be affected by these rules. Also note that in order to make this work, you will need to have Azure AD Premium P1 license (or EDU license).
Let’s have a fun scenario and say that in our organization, we would love that all newly created teams to be named as: Accountants-[Team Name] or Teams Developers-[Team Name]. Meaning that they should be prefixed by the person’s title + s-. How can this be done? This can be done by having a combination of an attribute prefix combined with a string prefix. So the combination of both would give us something such as [Job Title]s-[Team Name]. Note that I added an s to the job title as another prefix to achieve the s in Developers or Accountants.
In order to apply this policy, go to Microsoft Azure (portal.azure.com), and navigate to Azure Active Directory > Groups > Naming Policy
On the first tab, you can specify words that you want to be prevented from being part of your Team’s name. You can download the csv file, populate it with the required words, and reupload it again. Note that it’s not case sensitive, so if you add the word tips, TIPS will also be prevented from appearing in the team’s name, however tipss will be allowed.
Now click on the next tab that says Group naming policy, and here you can see we have 2 types, we have prefix and suffix, and under each one we can specify the policy to be based on free text (String) or based on user’s attribute. The attributes supported are shown in the dropdown list:
Note that not all user’s properties are supported and only 6 of them are at the time of this writing. Now to achieve our goal, we’ll have the first prefix as Attribute = Title, and the second prefix as s- so our newly created team would look like: Accountants-TeamName
Note that the prefixes and suffixes are applied in the order they’re listed here, by appending the latter to the previous prefix. Now save the changes and try to create a team. If you get an error like the one showed below that says: “The team prefix or suffix is incorrect, please try again”:
Don’t worry, as it takes some time for the changes to be applied. In my case it took around 10-15 minutes. Also note that if you’re testing with a global admin account then you won’t be affected by these policies and you can create teams with whatever names you want.
So with a regular user who’s title is Retail Manager, when creating a team, it will look like this for a team named Client Support:
The catch here is that this naming policy is done on the Azure groups themselves, which means if we try to create groups from another service, let’s say in Outlook, we’ll have the same constraints applied there as well:
