Power BI – ECELLORS CRM Blog

Key considerations working with the default environment in Power Platform

Hi Folks,

Today in this blog post, lets understand what’s the idea behind creating default environment and what are some best practices managing the default environment. Firstly, let’s understand why Default environment was brought in place.

Why Microsoft Created the Default Environment

1. Frictionless Adoption (The “Land” Strategy) The Default environment meant zero barrier to entry — any licensed user could open Power Apps or Power Automate and start building immediately, with no admin provisioning required. This was critical for competing with other low-code competitors.

2. Consumer-Grade Experience Expectation Early Power Apps was positioned almost like an Office app — something an individual could pick up like Excel. The Default environment mirrored that philosophy: personal, always-there, no setup.

3. Seeding the Platform in Organizations Microsoft’s adoption model has always been land and expand. Let citizen developers build things in the Default environment, create business value, get noticed by IT, then graduate to managed environments. The Default environment was the landing strip.

4. CoE Didn’t Exist Yet When the Default environment was conceived, the governance tooling (CoE Starter Kit, DLP policies, environment strategies) didn’t exist. The assumption was simpler: small platform, small footprint, manageable.

Now that we understood the back ground behind bringing the default environment. Let’s understand few more concepts on how to Manage and govern the default Power Platform environment…

Every employee in an organization that uses the Power Platform has access to the default environment. As a Power Platform admin, you should consider and implement ways to manage the default environment. Your Center of Excellence (CoE) teams can gather information using the PowerShell cmdlets, and Power Platform admin connectors to understand what’s happening in your organization’s environments.

This article also provides some best practices for using the data you gather from these sources to manage your default environment.

Enable managed environments

Maintain robust security and governance by making use of managed environment features in the default environment. Managed environment features provide advanced capabilities, such as monitoring, compliance, and security controls that are important for protecting your data. By enabling this feature, you can configure sharing limits, gain more usage insights, limiting user access to Microsoft Dataverse from only allowed IP locations, and use the actions page to get personalized recommendations to optimize the environment. Evaluate the current managed environments features and stay up to date with the product roadmap to maintain a secure, compliant, and well-governed default environment.

Track connectors

Connectors are Power Platform services that integrate apps and flows with other services. Power Platform administrators can use data policies to control which integrations are permitted in each environment.

Some connectors that drive core Power Platform functionality can’t be blocked. You need to know if these core connectors are being used so that you can provide policy guidance to your makers. For example, you might want to track the apps and flows in the default environment that use the Exchange connector and direct the makers to move to a different environment that allows outbound emails.

The CoE Starter Kit contains schema and flows to report the details of all connectors used by each app or flow in all environments. The data reported in the CoE dashboard is refreshed every 24 hours. You can also search for related flows and apps directly from the Dataverse environment where the CoE Starter Kit is installed. Learn more about tracking connectors with the CoE Power BI dashboard.

Discover unused and owner-less resources

As Power Platform adoption in your organization grows, you’re likely to have owner-less and unused resources in your default environment. When a maker leaves an organization, the maker’s apps and flows are in effect owner-less. Apps and flows that are used for a while and then are no longer needed can clutter the default environment.

To maintain environment hygiene, establish processes and procedures to clean up orphaned and unused flows and apps. These processes are especially important for the default environment, where all users are potential makers.

Use the actions page to view recommendations for apps without valid owners and apps that haven’t been used in the last 60 days. You can take action for each recommendation in the recommendation pane, or you can use the Power Platform for Admin V2 connector to automate tasks.

Our recommendation is to use the actions page. For more custom processes, evaluate the CoE Starter Kit to set up clean-up for orphaned objects and set up inactivity processes. You can use these processes as-is or modify them to suit the needs of your organization.

Discover highly used apps and flows

The default environment is designed for personal productivity, but makers can create apps and flows that become widely adopted or business-critical. This outcome is positive, but it requires management.

Apps that don’t follow a proper application lifecycle management are prone to business continuity risks. Moving high-value apps from the default environment to a Managed Environment lets you use premium security and governance capabilities.

Use the actions page to view recommendations for high-value apps in the default environment. Contact makers and develop a plan to migrate these apps out of the default environment into their own Managed Environment.

Again, our recommendation is to use the actions page. For more custom processes, use the Power BI dashboard in the CoE Starter Kit to identify widely shared apps and flows.

Discover highly shared apps

When 10 or more employees use a personal productivity app or flow, the Power Platform CoE helps you evaluate whether to move it to its own or a shared environment. The following table describes the parameters to consider. Learn more about developing an environment strategy.

Parameters	Defining criteria	Environment
Number of users	1–10 users	Default
	7–30 users	Shared
	>30 users	Dedicated
Nature of data	Highly confidential	Dedicated
	Confidential	Shared
	Not confidential	Default
Monetary or reputational impact	Yes	Shared or Dedicated
	No	Default
Requires ALM	Yes	Shared or Dedicated
	No	Default

Proactively set sharing limits to control how broadly users can share canvas apps, flows, and agents to avoid over-sharing of resources.

For a reactive approach, use the compliance process in the CoE Starter Kit to track app sharing and usage. Use it as-is or modify it to suit the needs of your organization. Learn more about the app auditing process. This process occurs only after sharing is complete.

Move applications from the default environment

Use solutions to package and deploy your applications, flows, and tables from one environment to another.

Fusion teams can use the following process to package the solution components, deploy it to a target environment, and delete it from the default environment:

Create a solution and add the app and all its dependent apps, flows, and tables.
Export the solution from the default environment and import it in a different environment.
Make sure that all users who had access to the app in the default environment have the right security roles in the target environment. Consider creating and using a dedicated security group to manage them.
Migrate all configuration and app data to the new environment.
Test and validate the app.
Notify users of the new application.
Remove access to the application for all users in the default environment. However, keep access for a few admins and makers.
Eventually, delete the solution and its contents from the default environment. Make sure that you don’t delete any shared assets. For example, if another app or flow uses a table, don’t delete the table.

Quarantine apps

Power Platform admins can quarantine canvas apps. In the default environment, you might want to quarantine an app when:

You want to disable it temporarily while it’s reviewed.
It’s been shared with many users and must be disabled.
It’s being upgraded or moved to a different environment.

Makers can edit a quarantined app, but users can’t play it. Remove the quarantine to restore access for shared users. Only admins can change an app’s quarantine state.

Three PowerShell cmdlets manage app quarantines:

Quarantine: Set-AppAsQuarantined -EnvironmentName <EnvironmentName> -AppName <AppName>
Unquarantine: Set-AppAsUnquarantined -EnvironmentName <EnvironmentName> -AppName <AppName>
Get quarantine state: Get-AppQuarantineState -EnvironmentName <EnvironmentName> -AppName <AppName>

Back up and restore the default environment

Like every other environment type (sandbox, production, developer), the default environment is archived automatically. However, you can request a restore for the default environment. If you need to restore a backup, contact Microsoft Support. They can restore your environment data to a support environment. Once that restore is complete, you can view and export data as needed. Keep in mind that restoring the default environment might also restore unused or orphaned apps and flows removed during cleanup.

Environment routing is available which allows to streamline your governance strategy for Default Environments.

Hope you have learned something about the default environment.

Cheers,

PMDY

Maximizing Your Power Platform Solution’s Reach: Essential Performance Considerations for Optimal Efficiency

Hi Folks,

This blog post is all about performance considerations for your Power Platform CE Projects and how you can plan to optimize application performance for your Power Apps. So I just want to take you through them…

Are you tired of creating solutions for longer durations and while at the end of the project or during UAT you end up facing performance issues for the solutions you have developed, one of the most important non-functional requirements for a project’s success is Performance. Satisfying performance requirements for your users can be a challenge. Poor performance may cause failures in user adoption of the system and lead to project failure, so you might need to be careful for every decision you take while you design your solutions in the below stages.

Let’s talk about them one by one..

1. Network Latency and bandwidth

A main cause of poor performance of Dynamics 365 apps is the latency of the network over which the clients connect to the organization.

Bandwidth is the width or capacity of a specific communications channel.
Latency is the time required for a signal to travel from one point on a network to another and is a fixed cost between two points. And usually many of these “signals” travel for a single request.

Lower latencies (measured in milliseconds) generally provide better levels of performance. Even if the latency of a network connection is low, bandwidth can become a performance degradation factor if there are many resources sharing the network connection, for example, to download large files or send and receive email.

Dynamics 365 apps are designed to work best over networks that have the following elements:

Bandwidth greater than 50 KBps (400 kbps)
Latency under 150 ms

These values are recommendations and don’t guarantee satisfactory performance. The recommended values are based on systems using out-of-the box forms that aren’t customized.

If you significantly customize the out-of-box forms, it is recommend that you test the form response to understand bandwidth needs.

You can use the diagnostics tool to determine the latency and bandwidth:

On your computer or device, start a web browser, and sign in to an organization.
Enter the following URL, https://myorg.crm.dynamics.com/tools/diagnostics/diag.aspx, where crm.dynamics.com is the URL of your organization.
Click Run.

Also, to mitigate higher natural latency for global rollouts, customers should leverage Dynamics 365 Apps successfully by having smart design for their applications.

2.Smart Design for your application

Form design

Keep the number of fields to a minimum. The more fields you have in a form, the more data that needs to be transferred over the internet or intranet to view each record. Think about the interaction the user will have with the form and the amount of data that must be displayed within it.
Avoid including unnecessary JavaScript web resource libraries. The more scripts you add to the form, the more time it will take to download them. Usually, scripts are cached in your browser after they are loaded the first time, but the performance the first time a form is viewed often creates a significant impression.
Avoid loading all scripts in the Onload event. If you have code that only supports OnChange events for fields or the OnSave event, make sure to set the script library with the event handler for those events instead of the OnLoad event. This way loading those libraries can be deferred and increase performance when the form loads.
Use tab events to defer loading web resources. Any code that is required to support web resources or IFRAMEs within collapsed tabs can use event handlers for the TabStateChange event and reduce code that might otherwise have to occur in the OnLoad event.
Set default visibility options. Avoid using form scripts in the OnLoad event that hide form elements. Instead set the default visibility options for form elements that might be hidden to not be visible by default when the form loads. Then, use scripts in the OnLoad event to show those form elements you want to display. If the form elements are never made visible, they should be removed from the form rather than hidden.
Watch out for synchronous web requests as they can cause severe performance issues. Consider moving to asynchronous for some of these web requests. Also, choose WebApi over of creating Xml HTTP Requests (XHR) on your own.
Avoid opening a new tab or window and do open the window in the main form dialog.
For Command Bar, keep the number of controls to a minimum. Within the command bar or the ribbon for the form, evaluate what controls are necessary and hide any that you don’t need. Every control that is displayed increases resources that need to be downloaded to the browser. Use asynchronous network requests in Custom Rules When using custom rules that make network requests in Unified Interface, use asynchronous rule evaluation.

Learn more Design forms for performance in model-driven apps – Power Apps | Microsoft Learn

Latest version of SDK and APIs

The latest version of SDK, Form API and WebAPI endpoints should be used to support latest product features, roadmap alignment and security.

APIs calls and custom FetchXML call velocity

Only the columns required for information or action should be included in API calls:

Retrieving all columns (*) creates significant overhead on the database engine when distributed across significant user load. Optimization of call velocity is key to avoid “chatty” forms that unnecessarily make repeated calls for the same information in a single interaction.
You should avoid retrieving all columns in a query result because of the impact on a subsequent update of records. In an update, this will set all field values, even if they are unchanged, and often triggers cascaded updates to child records. Leverage the most efficient connection mechanism (WebAPI vs SDK) and reference this doc site for guidance on the appropriate approach.

Consider reviewing periodically the Best practices and guidance when coding for Microsoft Dataverse – Power Apps | Microsoft Learn and ColumnSet.AllColumns Property (Microsoft.Xrm.Sdk.Query) | Microsoft Learn.

Error handling across all code-based events

You should continue to use the ITracingService.Trace to write to the Plug-in Trace Log table when needed. If your plug-in code uses the ILogger interface and the organization does not have Application Insights integration enabled, nothing will be written. So, it is important to continue to use the ITracingService Trace method in your plug-ins. Plug-in trace logs continue to be an important way to capture data while developing and debugging plug-ins, but they were never intended to provide telemetry data.

For organizations using Application Insights, you should use ILogger because it will allow for telemetry about what happens within a plug-in to be integrated with the larger scope of data captured with the Application Insights integration. The Application Insights integration will tell you when a plug-in executes, how long it takes to run and whether it makes any external http requests. Learn more about tracing in plugins Logging and tracing (Microsoft Dataverse) – Power Apps | Microsoft Learn.

Use Solution Checker to analyze solution components

Best practice is to run Solution Checker for all application code and include it as mandatory step while you design solutions or check when you complete developing your custom logic.

Quick Find

For an optimal search experience for your users consider the next:

All columns you expect to return results in a quick find search need to be included in the view or your results will not load as expected.
It is recommended to not use option sets in quick find columns. Try using the view filtering for these.
Minimize the number of fields used and avoid using composite fields as searchable columns. E.g., use first and last name as searchable vs full name.
Avoid using multiple lines of text fields as search or find columns.
Evaluate Dataverse search vs using leading wildcard search

3. Training

This step should be done during user training or during UAT. To ensure optimal performance of Dynamics 365, ensure that users are properly leveraging browser caching. Without caching, users can experience cold loads which have lower performance than partially (or fully) warm loads.

Train users to not clear the browser cache manually.
Check if there is any limit on disk cache size
In the browser, Clearing cached images and files setting and ClearCachedImagesAndFilesOnExit policy should be disabled
Check if devices have enough space allocated for browser cache.

Make sure to train users to:

Use application inline refresh over browser refresh (should not use F5)
Use application inline back button instead browser’s back button.
Avoid InPrivate/Incognito modes in browser which causes cold loads.
Make users aware that running applications which consumes lot of bandwidth (like video streaming) may affect performance.
Do not install browser extensions unless they are necessary (this might be also blocked via policy)
Do use ‘Record Set’ to navigate records quickly without switching from form back to the list.

4. Testing

For business processes where performance is critical or processes having complex customizations with very high volumes, it is strongly recommended to plan for performance testing. Consider reviewing the below technical talk series describing important performance considerations, as well as sharing practical examples of how to set up and execute performance testing, and analyze and mitigate performance issues. Reference: Performance Testing in Microsoft Dynamics 365 TechTalk Series – Microsoft Dynamics Blog

5. Monitoring

You should define a monitoring strategy and might consider using any of the below tools based on your convenience.

Monitor Dynamic 365 connectivity from remote locations continuously using network monitoring tools like Azure Network Performance Monitor or 3rd party tools. These tools help identify any network related problems proactively and drastically reduce troubleshooting time of any potential issue.
Application Insights, a feature of Azure Monitor, is widely used within the enterprise landscape for monitoring and diagnostics. Data that has already been collected from a specific tenant or environment is pushed to your own Application Insights environment. The data is stored in Azure Monitor logs by Application Insights, and visualized in Performance and Failures panels under Investigate on the left pane. The data is exported to your Application Insights environment in the standard schema defined by Application Insights. The support, developer, and admin personas can use this feature to triage and resolve Telemetry events for Microsoft Dataverse – Power Platform | Microsoft Learn
Dataverse and PowerApps analytics in the Power Platform Admin Centre. Through the Plug-in dashboard in the Power Platform Admin Center you can view metrics such as average execution time, failures, most active plug-ins, and more.
Dynamics 365 apps include a basic diagnostic tool that analyzes the client-to-organization connectivity and produces a report.
Monitor is a tool that offers makers the ability to view a stream of events from a user’s session to diagnose and troubleshoot problems. Works both for model driven apps and canvas apps.

I hope this blog post had helped you learn or know something new…thank you for reading…

Cheers,

PMDY

Building a Cloud-Native Power Apps ALM Pipeline with GitLab, Google Cloud Build and PAC CLI: Streamlining Solution Lifecycle Automation

A unique combination to achieve deployment automation of Power Platform Solutions

Hi Folks,

This post is about ALM in Power Platform integrating with a different ecosystem than usual, i.e. using Google Cloud, sounds interesting..? This approach is mainly intended for folks using Google Cloud or GitLab as part of their implementation.

Integrating Google Cloud Build with Power Platform for ALM (Application Lifecycle Management) using GitLab is feasible and beneficial. This integration combines GitLab as a unified DevOps platform with Google Cloud Build for executing CI/CD pipelines, enabling automated build, test, export, and deployment of Power Platform solutions efficiently. This was the core idea for my session on Friday 28 November, at New Zealand Business Applications Summit 2025.

Detailed Steps for this implementation

Create an access token in GitLab for API Access and Read Access

Click on Add new token, you can select at the minimum the below scopes while you were working with CI-CD using GitLab

Create a host connection for the repository in GitLab

Specify the personal access token created in the previous step

Link your repository

The created host connections in the previous step will be shown under Connec ctions drop down

Create Trigger in Google Cloud Build

Click on Create trigger above, provide a name, select a nearest region

Event:

For now, I am choosing Manual invocation for illustration

Specify where the name of the Repository where your YAML in GitLab resides

You can optionally specify the substitution variables which are nothing but parameters you can pass to your pipeline from Google Cloud Build Configuration

You can optionally give this for any approval and choose the service account tagged to your google account in the drop down.

Click on Save.

Next proceed to GitLab YAML

You can find the full code below

	steps:
	– id: "export_managed"
	name: "mcr.microsoft.com/dotnet/sdk:9.0"
	entrypoint: "bash"
	args:
	– "-c"
	– \|
	echo "=== 🏁 Starting Export Process ==="
	# ✅ Define solution name from substitution variable
	SOLUTION_NAME="${_SOLUTION_NAME}"
	# ✅ Install PAC CLI
	mkdir -p "${_HOME}/.dotnet/tools"
	dotnet tool install –global Microsoft.PowerApps.CLI.Tool –version 1.48.2 \|\| true
	# Add dotnet global tools dir to the shell PATH for this step/session (preserve existing PATH)
	export PATH="$_PATH:${_HOME}/.dotnet/tools"
	echo "=== 🔐 Authenticating to Power Platform Environment ==="
	pac auth create –name "manual" –url "https://ecellorsdev.crm8.dynamics.com" –tenant "XXXXX-XXXX-XXXXX-XXXXXX-XXXXX" –applicationId "XXXXXXXXXXXXXX" –clientSecret "XXXXXXXXXXXXXXXX"
	pac auth list

	echo "=== 📦 Exporting Solution: ${_SOLUTION_NAME} ==="
	pac solution export \
	–name "${_SOLUTION_NAME}" \
	–path "/tmp/${_SOLUTION_NAME}.zip" \
	–managed true \
	–environment "${_SOURCE_ENV_URL}"

	echo "=== ✅ Solution exported to /tmp/${_SOLUTION_NAME}.zip ==="
	echo "=== 🔐 Authenticating to Target Environment ==="
	pac auth create \
	–name "target" \
	–url "https://org94bd5a39.crm.dynamics.com" \
	–tenant "XXXXXXXXXXXXXXXXXXXXXXXX" \
	–applicationId "XXXX-XXXXX-XXXXX-XXXXXX" \
	–clientSecret "xxxxxxxxxxxxxxxxxxxx"
	echo "=== 📥 Importing Solution to Target Environment ==="
	pac solution import \
	–path "/tmp/${_SOLUTION_NAME}.zip" \
	–environment "${_TARGET_ENV_URL}" \
	–activate-plugins \
	–publish-changes
	echo "=== 🎉 Solution imported successfully! ==="

	options:
	logging: CLOUD_LOGGING_ONLY

	substitutions:
	_SOLUTION_NAME: "PluginsForALM_GitLab"
	_SOURCE_ENV_URL: "https://org.crm.dynamics.com"
	_TARGET_ENV_URL: "https://org.crm.dynamics.com"
	_TENANT_ID: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
	_CLIENT_ID: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
	_CLIENT_SECRET: "xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
	_SOLUTIONS_DIR: "/workspace/Plugins/08112025"

view raw GitLabDemo.yaml hosted with ❤ by GitHub

Solution from Source Environment

Now lets run the trigger which will export the solution from the source environment and import to the target environment….we have manual trigger, automatic trigger whenever there is an commit to the repo in GitLab etc., you may pick whatever suits your needs best.

Solution imported to the target environment using Google Cloud Build

The below table illustrates key differences between Google Cloud Build and Azure Devops….

Aspect	Google Cloud Build	Azure DevOps Build Pipelines
Pricing Model	Pay-as-you-go with per-second billing	Per-minute billing with tiered pricing
Cost Optimization	Sustained use discounts, preemptible VMs	Reserved capacity and enterprise agreements
Build Environment	Serverless, container-native, managed by Google Cloud	Requires self-hosted or paid hosted agents
Free Tier	Available with build minutes and credits	Available but more limited
Operational Overhead	Low, no need to manage build agents	Higher, managing agents or paying for hosted agents
Ideal For	Variable, short, or containerized workloads	Large Microsoft-centric organizations
Integration Cost Impact	Tightly integrated with Google Cloud serverless infrastructure	Integrated with Microsoft ecosystem but may incur additional licensing costs

Conclusion:

PAC CLI is a powerful command-line tool that automates authentication, environment, and solution management within Power Platform ALM, enabling consistent and repeatable deployment workflows. It integrates smoothly with DevOps tools like GitLab and Google Cloud Build, helping teams scale ALM practices efficiently while maintaining control and visibility over Power Platform environments. Just note, my intention was showcase the power of PAC CLI with wider ecosystem, not only with Microsoft.

Cheers,

PMDY

Showing multiselect option set from Model Driven Apps in Power BI

Hi Folks,

Well, this post will show you how you can work with multi option sets from Dynamics 365 in Power BI. First of all, you need some basic understanding of Power BI Desktop to follow. However, I made it clear for people with little background to follow and relate to. I scanned through the internet, but I couldn’t find a similar post, hence I am blogging this if it might help someone. I have faced this issue and here is the solution, you don’t need to use XrmToolBox nor Postman nor complex Power Query as many out in internet would suggest.

So, follow with me along, if you were trying show the values in Multi OptionSet from Model Driven Apps in Power BI as below, then this post is absolutely for you.

Practically if we retrieve the value of Multi OptionSet field as shown in the above image. You get something like below in comma separated values.

Now based on use case and the requirement, we need to transform our data, i.e. Split the values into rows or columns using a delimiter, in this case, we use comma as delimiter. Here I am splitting into multiple rows as I need to show the contacts for different option values selected in the record.

Select on the respective field and choose Split Column option available in the ribbon.

Next, you will be presented with Split Column Delimiter Dialog box, you may select the options as below and click on Ok.

Next in the Split Column by Delimiter, choose as below.

Once clicked on Ok, now the Multi OptionSet was changed to Single OptionSet and showing the values in different rows.

We can use Dataverse REST API to get the OptionSet values as below in Power BI, click on Get Data –> Web, enter the below in the URL to get the MultiSelect OptionSet Values –> Load. You can refer here some reference.

			
https://ecellorshost.crm5.dynamics.com/api/data/v9.2/stringmaps?$filter=attributename%20eq%20%27powerbi_multioptionset%27

Once data is loaded, it should look as below..

So, now click on Close and Apply the transformation to be saved in the model, later create the data model relationships by going to the model view as below between the multiselect OptionSet field in the contact table and string map table.

Once the relationship is established, we can proceed with plotting the visuals in visuals of your choice. For simplicity, used.

Hope this helps someone looking out for such requirement which at least could save couple of seconds.

Cheers,

PMDY

Power Platform Solution Blue Print Review – Quick Recap

The Solution blueprint review is covers all required topics. The workshop can also be conducted remotely. When the workshop is done remotely, it is typical to divide the review into several sessions over several days.

The following sections cover the top-level topics of the Solution blueprint review and provide a sampling of the types of questions that are covered in each section.

Program strategy

Program strategy covers the process and structures that will guide the implementation. It also reviews the approach that will be used to capture, validate, and manage requirements, and the plan and schedule for creation and adoption of the solution.