The other day, I received a request about „What happened to the Bot Author role?“. Do you recall that role from the old Power Virtual Agent days? If not, here’s a brief explanation. Previously, a Power Virtual Agent license enabled global admins to designate certain users who could use Power Virtual Agents in your tenant. System administrators for each environment could restrict who could create bots in that environment. This was done by following these steps:
- Create a new environment that you want users to create bots in (make sure Dataverse created)
- Launch Power Virtual Agents and create a bot in the environment
- Go to Power Platform admin portal to assign security roles
- Assign ‚bot author‘ role to users that you would allow creating bot in that environment
Bots and Power Virtual Agents are things of the past. Nowadays, we use Microsoft Copilot Studio to customize and build our own copilots or enhance the one for Microsoft 365, right? Therefore, no longer we need to assign users to „Bot Author“ role. Neither, we need to assign them the following license part shown in visual below, if you got Office 365 E5 licenses purchased for your tenant.
I keep saying this because I ran a test with the user Sanjay, who is shown in the image above, to access Microsoft Copilot Studio.
This user expected to get access to Microsoft Copilot Studio and begin creating their own copilots, but they received a message to sign up for a free trial instead. In my test environment, I did not restrict users from signing up for free trials. However, if one of your admins has applied this restriction to your tenant, you may see a different message here.
It seems obvious that with the change to Microsoft Copilot Studio, you now need to assign the user a Microsoft Copilot Studio license instead now. Once this has been assigned to above user Sanjay in my case, this user successfully enters the Copilot Studio experience.
As shown in the image above, the user is directed to their default environment and prompted to verify their country/region information, which is obtained from their Microsoft Entra information. After confirmation, if this user is trying to switch the environment, this is what´s shown.
This user only has access to the Default environment, and no other „supported environments“ are displayed for this user. This is because the user has the Environment Maker role for the Default environment, which is unavoidable. However, the user does not have this role for any other environments. You may wonder why this could be a problem?
What if you want to prevent your users in the Default environment from creating new copilots, especially those that use generative AI and other features such as Plugin actions and connectors, you can do the following:
- If your environment is eligible for an opt-in to Generative AI features, you could opt-out for moving data across regions – though this would cause all other Power Platform Generative AI to stop working as well
- Setup a data policy for the default environment that blocks Copilot Studio Connectors
Instead of disabling the Generative AI features for the entire Default environment, I suggest choosing the second option. You may also need to adjust some of the data policies later when you customize Copilot for Microsoft 365.
How about setting up a copilot developer experience where developers can collaborate on the design and creation process of copilots? When I followed this link, one thing caught my attention: Users in the environment need the Environment maker security role to share a bot with others.
Let´s explore this in my next episode and see why would consider least privilege a best principle, even though we should trust developers for being skilled to understand about their opportunities given. Until then,…
The Power Platform Talks 
Ein Gedanke zu “Power Platform | Bot Authoring role”