Understanding Environments

Contents

keyboard_tab
Course Introduction
1
Introduction
PREVIEW1m 14s
Connecting Data with Connectors
Course Summary
8
Summary
1m 14s

The course is part of this learning path

Start course
Overview
Difficulty
Beginner
Duration
19m
Students
294
Ratings
5/5
starstarstarstarstar
Description

This course explores the core components of Microsoft's Power Platform, including the Microsoft Dataverse, common data model, compliance, connecting data to Power Platform, and the AI Builder.

Learning Objectives

  • Learn about the Microsoft Dataverse and the Common Data Model
  • Learn about Power Platform environments and data compliance
  • Understand the types of connectors you can use within Power Platform
  • Explore the AI Builder and various low- to no-code use cases for various AI Models

Intended Audience

This course is for anyone who wants to understand the core components within the Power Platform and who wants additional insight into how their data connects within it.

Prerequisites

To get the most out of this course you should already have a basic understanding of Power Platform. Before embarking on this course, we recommend that you take our course "Understanding the Business Value of Microsoft Power Platform" beforehand.

Transcript

Environments are a place to store and manage your organization's data and applications. You can create multiple different environments and each environment has its own set of data, apps and users that can access it. Environments are created using an Azure Active Directory tenant and its information can only be accessed and utilized by users from that tenant. Each individual environment can be attached to one Dataverse database, which affects roles in the environment, but we'll get to that in a moment. Let's use a real-world example to help visualize environments.

Each environment can be thought of as its own box. Each box has users, data, applications, and more which can be used to create apps, flows, connections, and more within that box. Environments work very much like this box analogy. The only clarification is that each environment is fully contained within itself. You can not take data or an app from environment A and use it environment B. If you wanted to do something like that, you would need to create an entirely standalone new environment C. An application created in environment A can only access data stored within A and cannot connect to environment B's data or apps. Because of this, organizations may create multiple environments each with its own data, users, and purposes.

An environment might be used for live production usage, while another environment could be purely for testing and development purposes. How you set up your environment is entirely up to you and your business needs. However, on a larger scale, environments are bound to their geographic locations. This means that whenever you create a Dataverse database for an environment, that database is located within a data center with the same geographic location as the environment and the same goes for anything you create within that environment. To give an example, a company like Microsoft that works worldwide might have an environment in Europe, Asia, the United States, and more. This helps organizations work within their local data compliance regulations.

Environments also have their own set of roles for users, which determine their privileges within that environment. As I alluded to a bit earlier, roles change depending on if the environment utilizes the Dataverse database or not. If the environment does not utilize the Dataverse, the only two roles possible are environment admins and environment makers. The environment maker is the default role given to users within the environment while the environment admin has all administrative privileges within that environment. However, once you connect the environment to a Dataverse database, the roles I just mentioned require additional permissions to gain the same privileges and the environment also gains a few more user roles.

These roles are the environment maker, the system administrator, the system customizer, the basic user, the service reader, the service writer, the delegate, the support users and the office collaborator. I know there's a lot, so I'm not gonna go into each of them individually, however, I can clarify the main differences between the environment with and without a Dataverse database. The most important thing to know is that to gain the same administrative privileges one would receive from the environment administrator role without a connected Dataverse, they would need the added system administrator role.

As far as the environment maker role is concerned, if you want the same privileges that you would receive within an environment without a connected Dataverse, then you would need the system customizer role as well to be able to create and update entities. If you want a more in-depth look at the specific roles within a Dataverse environment, I suggest reading Microsoft's documentation for configuring user security in an environment.

About the Author
Students
3075
Courses
15
Learning Paths
3

Lee has spent most of his professional career learning as much as he could about PC hardware and software while working as a PC technician with Microsoft. Once covid hit, he moved into a customer training role with the goal to get as many people prepared for remote work as possible using Microsoft 365. Being both Microsoft 365 certified and a self-proclaimed Microsoft Teams expert, Lee continues to expand his knowledge by working through the wide range of Microsoft certifications.