In the previous blog, we have gone through an overview of where PowerApps could be used and also some ideas on APIs that can be connected to it: https://bit.ly/2GPjghA
In this blog, we are going to go in some detail on the connection of PowerApps to Office 365 – and some examples of how this integration could be beneficial in application development through PowerApps.
Office 365 and PowerApps
One way though which PowerApps can be accessed, is through an Office 365 subscription. Once logged in you will see PowerApps available under one of the apps with this platform.
Yet the relationship between Office 365 and PowerApps does not stop there. When building an application in PowerApps – which is going to be accessed in an Office 365 platform – there are various commands that may be used to add features to the developed application.
Once the connection has been added, two elements and a screen in PowerApps should be enough to provide the option to choose one profile from Office 365 directory.
A ComboBox could be added from the Controls, and in this case we added a Label (which although it does not affect the functionality itself, gives a description). A ComboBox is like a normal Dropdown (which is classified as a separate control in PowerApps) but which amongst other slight differences, allow the selection of more than one item from the item list of the dropdown. It is worth saying that the allow multiple selection option can still be switched off. But I still prefer using this over a Dropdown because it allows the search option (which again can be enabled or disabled). This will apply an interactive filter to narrow down the list in the dropdown items.
“User:” has been typed in the Text of Label1 and placed the ComboBox just beneath it on the screen. What the user inputs as a search text when using the application within the ComboBox can be called within the application using the SearchText function. In the Items of ComboBox1, which will determine what the user is to be presented with when the dropdown is clicked on, the connector is called through the Office365Users command. The SearchUser operation is then added, and as a searchTerm (which can be used as part of the SearchUser operation to filter the list), the ComboBox’s SearchText is to be used. The complete and proper syntax can be seen in the next screenshot.
It is also important to specify which Office 365 fields are going to be used in the list and for the search – in this example it was the DisplayName.
That is basically enough to present the PowerApps user a dropdown to filter and select a profile from. When running the application, the PowerApps user will start typing the display name that s/he intends to find, and the list is narrowed down.
The user can then select the appropriate display name.
What is also useful, is the ability to add other Labels, in order to get more information from the selected Office 365 profile.
And this can be done with a simple syntax like the following:
This way every time the selected profile is changed, the value of Label2, will change automatically depending on the selected value.
Instead of MailNickname, there will be a whole list of attributes that can be extracted from Office 365 profile like City, Country, Id, Mail, contact numbers etc.
Likewise, like the SearchUser() operation, there are many other operations that can be used in conjunction with Office365Users connector command.
One other notable operation is Office365Users.UserProfileV2() which enables retrieval of data by passing the Profile Id or User Principal Name in order to get a whole list of information including skills, past projects, responsibilities, schools, interests and such fields that are available in Office 365 user profile:
This is an example of the command that can be used for this:
ProfileId in the above, is a label that is using a command to get the Id – which we will explain in the next section.
Handling user logins and presenting different screens to different users within the same application is also easy.
In order to, identify a user that has been logged in and display her/his details, another 3 elements within a screen should also be enough.
One of the elements could be an image, added through the Media tab. And the User() function could be used to get back the image of the user (as updated in her/his profile).
Two Labels can then be added and placed under the image, one displaying the name and the other the email with this syntax for each label (in Text property):
Once the PowerApps user logs in, the details will show up on this screen. And similarly, the email could be obtained and used to filter out/ give access to certain controls or screens within the application.
It is also worth noting that other functions like Office365Users.MyProfileV2() can be used to get a whole list of other details for the logged user – if the user has logged in through the Office 365 account.
Getting back to the ProfileId label mentioned in the end of the previous section, the following command is being used to get the Id:
It is important to keep in mind that even if there are various ways of retrieving such information, ensuring the use of a command that guarantees the retrieval of a record using a unique key is imperative. For instance, this command also returns an Id:
However, there can be more than one user in an active directory with the same full name. In this command we are getting the first profile and returning its Id – which is not always guaranteeing us the proper profile Id, especially if another user exists with the same name as the logged in user
This explains how easy it will be to develop and create such a capability in PowerApps solution. As pinpointed already, Office 365 and PowerApps offer other features that can be maximized through this connection and integration. And in a similar manner PowerApps can produce other positive results when connected and integrated with other relevant data sources and utilized as a user interface through application development!