Let’s go over and review these changes.

Let’s start and take a look at Security Roles. When you click on the Security Roles, you will be navigated to a screen containing a list of all the security roles within your organization, with the ability to filter by business unit, same as within the legacy/classic interface.

From here we have a few options, on the Command bar, we have the option to start creating a new role (which will take us to the classic interface), or just navigate to the classic interface.

If we select a particular role, we have some other options which are Copy, Edit or Delete. The Copy and Delete options are available from within the admin center, while the Edit will redirect us to the selected role from within the classic interface.

If we click on the actual Security Role name, this will redirect us to another page which will show us the users and teams that are part of this security role. In here you can add additional users to the security role or even teams, as well as remove existing ones. Clicking on the Add people button will open up a search panel where you can enter the name or email of a user and team, and select to add them to the Security Role.

Next, let’s take a look at teams. When you click on the Teams link in the Settings page in Admin center you will be redirected to the Team page. There is quite a bit of functionality that has been added to the teams. The image below shows you the initial view of the teams page.

The first option of course is the ability to add new teams. This is the same as you would have in the classic interface. By clicking on the Create team button, we get a panel where we need to enter the basic team information, which includes the Team Name and Description, Owner, Business Unit and Team Type as shown in the image below. There are 4 Team types that we can select from, which are Owner, Access, AAD Security Group and AAD Office Group.

You can see the link below to learn more about the different types of teams.

https://docs.microsoft.com/en-us/power-platform/admin/manage-teams

Once you have entered the basic team information, click on the Next button to select the members of the team. You can select multiple team members as shown in the image below:

Finally, before the team creation can be completed, select the security roles that will correspond to the team. The image below shows how this is done. You can select multiple security roles for the creation of the team.

In addition to creating a new team, when you select an existing team from the list of teams that we showed in the images above, you have the same options.

From here, you can Edit the team, which will allow you to change the team name, description and administrator. The business unit and the team type cannot be modified once the team has been created. You can choose Manage Team members to either add new team members or remove existing members from the team, and you can select the Manage security role option to Change the security roles that are assigned to this team.

Finally, you also have the option to delete the selected team.

The users section is still missing some of the functionality that we expect, but there are a few available options such as the creation of new user accounts, and setting security roles for users.

Let’s start with the creation of a new user account. To create a new user account, we navigate to the User page, and click on the Add User button. We also have the option to Manage the users in Dynamics 365 which will navigate to the classic interface.

When we click on the Add user button, we get the Add User pane, where we can search for a user by Name or Email. There are some minimal requirements that must be met before a user can be added, which are that the User has to be enabled in Azure Active Directory, have an active license and be a member of the environment’s security group. The image below shows the add new user pane.

If you do not meet on of those requirements, a message will appear specifying that the user has not met all the requirements to be added.

Finally, selecting an individual user and clicking on Manage Security roles will open a pane, where we have the ability to change the security configuration of the user, by adding or removing security roles.

For those interesting in viewing the previous post about Application Users, you can read more about that post in the link below.

Power Platform Admin Center – Application Users

It seems like little by little Microsoft is adding the required features that will allow us to achieve parity, especially with the announcement of deprecation of the classic interface sometime next year, and these features not available in UCI. Stay tuned for future updates.

The post Admin Center Changes for Users, Teams and Roles appeared first on Aric Levin's Digital Transformation Blog.

https://www.ariclevin.com/Azure/Post/configuring-oauth-cds

In recent weeks, I had to do that same for an additional user, but while going through the logic of implementing this, I notices some changes.

After the creation of the User account and the registration of the App in AD, when I went to create the account in my Dataverse environment. The username, full name (first and last names) and the email addresses were locked. The only setting that I was able to enter was the Client Id.

I even tried using God Mode so that I can enter my own User Name (for the AD account) that I specified, but when I saved the new Application User, the User Name would store whatever name was entered in the App Registration record.

This change was implemented a few months back, as Microsoft was trying to simplify the creation of App Users, so that the user can be created only be entering the Client Id. After the user account has been created we are able to modify the email address, first and last name, but the name (domain name) and the last name cannot be changed. The last name seems to be configured to what is stored in AAD as the App Registration name. Might need to play around with this a little, but if you have access to AAD, you should created this in the right way

I asked around a little bit, and it seems like a few days ago there has been a change in Microsoft Docs on how applications user should be created. The link is provided below:

https://docs.microsoft.com/en-us/power-platform/admin/manage-application-users

The new changes are that now Application Users can be created right for the Power Platform Admin Center. As a prerequisite we have to register the App in Azure Active Directory, but once the app is registered, we can add in directly by following the steps below.

Navigate to Power Platform Admin Center, select the environment, click settings, and under Users + permissions select Applications Users as shown in the image below

In the Application Users settings you will see a list of all the App Users that are currently configured for your dataverse environment. Click on the Command bar New app user button as shown below:

This will pop up a panel where you can start creating the new App User account. Under neither the App label, click on the App an app link:

This will pop up an additional panel which will show all of the apps that are registered in Azure Active Directory. Select the Microsoft Dynamics CRM (Dataverse) app registration that you previously configured, and click on the Add button

Once the app registration is added, we will need to select the Business Unit and to add the security roles. Click on the pencil icon next to Security role, which will pop up an additional panel showing the list of available security roles. Select one or more roles that need to be assigned to this user, as shown below:

The final page is shown below. Click on the create button to create the app user in your Dataverse instance, and it can be used after that.

This is a great step moving forward, but I still wish the User account details could be set on the creation of the App User to an actual AAD user.

The post New Dataverse functionality in creation of App Users appeared first on Aric Levin's Digital Transformation Blog.

This seems to be straight forward. The security is handled within our Dataverse environment, and users that do not have Read privilege would just not see the data, and I could control the look and feel within the Canvas app so that the result looks good to either user.

The screenshots below show the sample of how this should look like to users with the privilege and without.

Full Privileged User:

Limited Privilege User (with No Access to Project Members):

This looks good, but unfortunately this is not the end of the post. Actually, what ended up happening is that when I opened up the form using the less privileged account, I would see the following error:

The error makes sense, you don’t have privilege to see these records. I know this, but why are you displaying the error message.

So further analysis determined that this is the way that I load up the records into my Canvas App. I can load the records using the Data Source directly, in my case Projects and Project Members, or we can load the records into a local collection, and then manipulate the data if needed and display the data to the user as ProjectsCollection and ProjectMembersCollection. The source code below, shows the option of using a Collection.

Since we needed to manipulate the data, the second option made more sense, but now this error. To resolve this issue we first enabled Formula-level error management in the Settings area of the app.

Next we need to add code to handle the error message, so that we display something a little cleaner or maybe not at all.

We modified the code to include the IfError function and show a notification that the user does not have privileges to see the data.

We were also able to hide the completely from the user by setting the length of display to 1 millisecond.

So, the verdict is if you are using Collections that need to retrieve data from a data source, and your users might not have privileges to them, make sure that you add error handling code to that, because you Canvas app will not handle this automatically.

Adding a shoutout to Hardit Bhatia on his blog article on custom errors in Power Apps:
How to create custom errors in Power Apps! | Hardit Bhatia: The Power Addict

The post Handling Missing Dataverse Privileges in Canvas App appeared first on Aric Levin's Digital Transformation Blog.

Microsoft Dynamics provides the ability to create Stub Users. Stub users are user records that are created in Dynamics CRM. These records are designed for users that do not exist in CRM, but can be referenced during an import process. The user accounts cannot be logged into the system, and modifications to the user records are not possible either.

Stub users can only be created using the Create or Create Requests methods of the SDK (or using an import tool such as SSIS with Kingswaysoft).

Stub users are different from interactive users and disabled users. The following table shows the difference between the users types:

Stub users are different from regular disabled users in the sense the disabled users can consume a license, and disabled users can still be a part of Office 365 or Active Directory.
When migrating users, the users should be originally created in the target environment (whether Online or On-Premise), and only then the migration should occur.

Another import thing to note, is that when stub users are created, they are automatically assigned the SalesPerson security role, and that security role cannot be altered. If you need to provide these users other permissions, you will need to modify the SalesPerson security role to have those permissions, and revoke them after your migration has been completed, as stub user records cannot be modified in any way after they are created.

The post Stub Users Reviewed appeared first on Aric Levin's Digital Transformation Blog.

To disable bulk edit for a particular security role for all entities, we simply modify the Bulk Edit privilege under Miscellaneous Privilege on the Business Management Team of the security role.

When we want to disable access to Bulk Edit on a particular entity there are a couple of choices.

The first choice is allow the user to access the Bulk Edit form, but when the form is loaded to disable all controls. This can be quite easily accomplished with JavaScript. We would open the form, check for the Form Type, and if the form Type = 6 (BULK_EDIT), we would call a function to loop through the Controls Collection of the Form, and disable all controls. The following code is an example of how to disable or hide all fields when loading the Bulk Edit Form:

function onLoad()
{
    var formType = Xrm.Page.ui.getFormType();
    if (formType == FORM_TYPE_BULKEDIT) 
   {
      disableAllFields();
      // or
      hideAllFields();
   }
}

The second alternative is to modify the Bulk Edit button, so that it only shows based on a particular security or privilege. We can easily do this using Ribbon Workbench. All that is necessary is to add to the Bulk Edit command Display or Enable rules, so that the button will only show up when the user that is planning to do Bulk Edit has the appropriate privileges. The following screenshots demonstrates this:

All that is necessary is to add either a JavaScript command, Display Rules or Enable Rules to the Command above, so that it filters the access to the Bulk Edit button.

Note that this process will have to be done on every entity individually (either option 1 or option 2) that you would like to customize the Bulk Edit permissions.

The post Partially disallowing Bulk Edit from Users appeared first on Aric Levin's Digital Transformation Blog.