Power Platform | Bot Authoring role

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:

1. Create a new environment that you want users to create bots in (make sure Dataverse created)
2. Launch Power Virtual Agents and create a bot in the environment
3. Go to Power Platform admin portal to assign security roles
4. 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.

Microsoft 365 Admin Center – User assigned licenses and options for Office 365

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.

Microsoft Copilot Studio – showing a prompt to start a free trial

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.

Microsoft Copilot Studio – first time entering after a license being assigned

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.

Microsoft Copilot Studio – Environment selector

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,…

Power Platform | Provide governance at scale

At MS Ignite, Microsoft announced new capabilities for Managed Environments today. Many customers have recently enhanced their low-code strategy by adding responsible AI capabilities, but there are also many questions about how AI can work with Power Platform and Governance team. The goal is to simplify their daily tasks and reduce the effort, while maintaining the highest company security and compliance standards and using AI responsibly.

Admins can now use environment groups and specific rules to standardize essential settings and configurations for governance at a new level of scale. Makers can access a personal developer environment that complies with these rules. These environments can be seamlessly integrated with Pipelines for Power Platform, which simplifies the use of ALM tools. Additionally, the latest advisor capabilities offer admin teams useful insights gathered from different environments. This gives them more control over the development and deployment process, and also makes onboarding easier.

To outline the capabilities and drive business value discussions, I am sharing today this new visual that summarizes the current feature set as of November 2023 used in my briefing sessions.

Visual of Managed Environments capabilities breakdown

CIOs know that IT teams have ongoing and upfront costs for providing SaaS solutions that help their business teams and themselves perform daily tasks. These costs are not only related to premium licenses and immediate charges. Developing and maintaining their own professional services package for SaaS operation in fact can be expensive in terms of time, effort and money.

A conversation based on entitlement could alter the perception of the premium licenses mentioned above, as they all grant the right to use and activate Managed Environments. Some of the monthly per-user license fees are used to provide such maintenance tools that offer more visibility, more control and less effort.

The new features enable customers to simplify their governance at scale, access various settings and services, and reduce their IT labor costs. By using Power Platform’s AI-generated insights to automate daily routines, and by applying different rules to groups of environments to ensure security and compliance standards, customers can save time and avoid tedious tasks.

A breakdown visualization of Govern, Protect and Manage the Power Platform

Managed Environments is one of the many features and tools that help govern, protect and manage the Power Platform. However, some SaaS security teams may not be aware of the full range of capabilities available, because they are not all managed within the Power Platform Admin Center. Therefore, Power Platform admin teams should make use of the extensive toolset that comes with the premium- or subscription-based licenses to keep the SaaS offer in optimal condition. This is especially important for ensuring Cybersecurity, as some of the protection mechanisms are enabled and managed by Microsoft, while others require your own configuration and management according to your company’s operational preferences.

It´s about time to streamline your governance at scale. Until then,…

Power Platform | Pipelines – Design a security concept

You may have heard about my mini-series I did for reviewing Power Platform Pipelines. The easiest way to check this out is starting here, if you missed it. Ever since there´s been an episode on XrmToolCast with my MVP friends Scott and Daryl where we had a chat about the Application Lifecycle Management capabilities around this new Power Platform Power Apps in-app experience. Thanks for having me on your show. You prefer watching the video instead of just listening? Here you go. Today, I´d like to review the security roles that are brought with this solution and providing some food for thought on an architecture design which I recently reviewed from an enterprise customers planning to use Pipelines.

The Admin security role

Let´s start with a look at the role that you would assign to those typically in DevOps who would overlook the ALM process and should be able to setup, monitor and inspect the various deployment pipelines and -stages. You would assign them the Deployment Pipeline Administrator role.

Overview of privileges granted to users assigned the security role – using XrmToolBox Role Documenter

Remember these roles are coming with the solution itself, which means you will find them in every Host you´ve installed the Pipeline solution for. This is pretty important in terms of the current limitation that you need to have a Pipeline Host in every region you are having Development, Test/QA and Production type environments. In other words a Developer creating the artifacts in a US region based developer environment will not be able to deploy the solution to EMEA or ASIA based Test/QA or Production type environments.

As you can see from the screenshot above your users in DevOps not only would be allowed to administrate Pipelines, they are also allowed to use Pipelines created. The permission granted is Org-wide (green circle). This is important to understand when you´re considering the role assignment been done not on a per User level, instead using Azure Active Directory Security Groups and assign the role via the membership of this group.

To learn more about this concept, I recommend yours watching the recent The Low Code Revolution episode where Daniel and Prabhat are talking about this in more detail.

Enterprise Architecture

As I outlined earlier, I was tasked to review an enterprise architecture design for using Pipelines in an organization. To provide more context, think of multiple developers would work in shared developer environments. It was essential to challenge, if all those developers should be assigned the Deployment Pipeline Administrator role, due to specific security requirements. Furthermore, developers where basically located across the globe which in terms of using a single Pipelines Host would fail due to the fact of having multiple Test/QA and Production type environments being in different regions. The customer furthermore considere more sophisticated developers to be able to create their own pipelines in each region them developing solutions for. Them being capable of managing, monitoring and inspecting of what´s ongoing + supporting other Makers using Pipelines to deploy their solution artifacts as well. Obviously this becoming a challenge everyone being granted the above security role.

So what´s an option here?

The user security role

You may ask now, if the user security role might be the solution to be used in an enterprise architecture. So let´s find out by taking a closer look at it.

Detailed view of Deployment Pipeline User security role – using XrmToolBox Role Documenter

Reviewing the privileges granted with this security role, you can see, why a deployment pipeline created by an Admin would need to be shared with the User for them to see the pipeline becoming available in the Pipelines solution. The security role grants them user-specific read permissions for both the Deployment Pipeline and -Stage table to allow for exactly this scenario.

In an enterprise scenario you again would make usage of Azure Active Directory Security Groups to assign this role via membership of the security group, instead of going user-by-user level, sharing and granting privileges.

Enterprise architecture continued

In our enterprise architecture where multiple Makers should be equipped to deploy their created artifacts via solutions from Development to Test/QA and finally to Production type environment(s), you again need to consider the privileges granted with this end-user Deployment Pipeline User security role. While for the majority of Makers (think Business Technologists) this role and the sharing of Pipelines by Admins might work in practice, more sophisticated Makers might ask for a kind of interim role, which „sits“ between both provided out of the box security roles. Personally, I would love to see another role being added where more sophisticated Makers would be allowed to at least create, monitor and manage their own Pipelines without being granted the high security privileges on the overall company-wide Pipeline Host(s).

With the upcoming Pre- and Post-stage extension which would allow to implement approval and review scenarios prior to deployment stages, this role could also help with the Fusion Teams development concept. I´ve been creating software artifacts within both Dynamics 365 and Power Platform from the early beginning the solution concept being introduced. A rule of thumb always was to have a review done by another person as you tend to test the code / solution in the way you designed / developed it and this may not be the only way your users consider to use your solution. Another aspect was to collaborate and develop in teams and merging artifacts to compact solutions prior to them being deployed.

In our current architecture design review, we ended up going with a Pipelines Host in each region for managing Pipelines. We created a custom role as a copy of the user-role to allow for more sophisticated Makers becoming „Managers“ of their own Pipelines while DevOps Admins remain responsible for an overall quality / review aspect in each region. A concept that was inherited from the CoE implementation of this customer.

As always, let me know via the comments what your experiences are with using Pipelines in your company. Until then, happy easter holidays for those celebrating or taking a time off to relax and reload energy…

Power Platform | Zero Trust possible?

When talking to organizations about starting their digital transformation journey with Microsoft´s Power Platform, Security is one of the topics that comes up. Security has multiple dimensions and top asks at workshops are like:

• Using Power Platform, don´t we open the doors to „shadow IT“?
• Seeing Citizen Developers using all those connectors, don´t we allow for an unmonitored, unmanageable amount of apps and flows handling business data in an uncontrolled manner?
• Allowing everyone to create and use interfaces (connectors), don´t they become risk-managers?

In a complex hybrid work model, this topic has become a challenge for many IT departments over the course of the last months. Microsoft is following the principles of Zero Trust. This model offers guiding principles, an overview of end-to-end framework and many more. To help yours stepping into this quickly, here´s a short visual that outlines the principles that I am using in conversation.

Microsoft Zero Trust Model

What many of my workshop attendees recently request is where Power Platform „fits“ in this. Taking a look to the left on above visual it starts with Identities and Devices. Considering that Power Platform tools such as Power Automate, Power Virtual Agents, Power BI or Power Apps can be used from multiple devices such as Desktop PCs, Tablets or mobile phones, an identity is always needed. Meaning a verification is ongoing, least privileges access should be applied and breach assumed when it comes to connectivity. So what about the right side of above visual?

Principles of Zero Trust applied

A maker interested in creating a process flow with Power Automate, using Power Automate Desktop, Power Virtual Agents or Power Apps always needs to authenticate and authorize using their identity. When talking about endpoint communication to APIs, encryption at REST is what the SaaS platform manages „behind the scenes“. Communication to custom APIs can further be secured using Azure API Management. Accessing Data, such as Dataverse, Role-based access control (RBAC) can be assigned in granular control using security roles. Power Apps being deployed are managed insight environments and app access controlled via sharing principles. Furthermore, access to apps can be granularly controlled via Azure conditional access policies. Apps not meeting compliancy standards can be quarantined. Talking about the infrastructure of tenants and environments access via connectors can be managed and secured using DLP policies. And finally using the on-premises Gateway, access to network can be further controlled.

Microsoft´s Power Platform therefore can be assessed following Microsoft´s Zero Trust model. Why?

Governance capabilities of Power Platform

Because Azure is the heartbeat of the Power Platform. Several compliance, security and governance offers are based on the fundamentals of Azure services. Above visual outlines principles, I would talk about during a Governance workshop. Principles applied, the questions at top of today´s article could be answered with setting up the Governance model of using your SaaS platform.

If you´re interested to learn more about the security side, please follow this guidance. Until then, …