Since the public preview announcement, we made several enhancements and added many new capabilities. Solution checker now runs faster and has more coverage across solution components. Today, we’re thrilled to announce the general availability of solution checker enforcement in Managed Environments!

Here are some of the changes since public preview:

Automatic checker run during export

We made it easy to scan your solutions for issues while exporting by providing an option to automatically run solution checker before exporting it.

Automatic checker run during import

During public preview, you were required to pre-validate the solution using solution checker before importing it. Without this mandatory step, solution checker enforcement could fail the import process. Now, we will run the solution checker automatically when the solution was not validated before importing so that your import process can proceed seamlessly.

Rule exclusions

Admins can now exclude rules from blocking or warning during import if certain violations will take time to address, but you still want to enforce the remaining ruleset. This will allow you to skip certain rules to avoid any of your legacy code from blocking new changes from getting deployed. Although this gives you the flexibility to proceed with deployments, we recommend that you address issues identified by solution checker at the earliest to avoid potential harm to your resources.

New solution checker rules

Since public preview we’ve added more than 20 new rules to the Solution checker. These include several security and performance rules for apps and components. As an example, the new connector checker can validate connectors used in your solution.

More ways to save results

You can now pass --saveResults or --sav to pac solution check to get your results automatically stored in your connected Dataverse environment. These result links will be available in the maker portal and admin emails so you can quickly drill down into the details. More information in the docs.

Warn mode by default

As part of public preview, we set the default solution checker enforcement mode to Warn when enabling Managed Environments. In the near future, environments enabled before March 2023 will be transitioned to Warn mode automatically. Communication emails and messaging will be sent to admins in advance with the transition date.

Looking forward

We are committed to providing Power Platform users with the tools and resources they need to build and deploy high-quality solutions, as well as the governance to efficiently perform application lifecycle management. Solution checker enforcement is just one of the many ways we are working to achieve this goal.

We encourage all Power Platform administrators to take advantage of this powerful new feature and provide feedback to help us continue to improve and refine the tool.

Please share your feedback/suggestions in this thread and see our documentation for more information.

The post Solution checker enforcement in Managed Environments is generally available appeared first on Microsoft Power Platform Blog.

There are two modes you can choose for solution checker enforcement:

In Block mode, solutions can only be imported if they were checked with solution checker and they contain no critical violations. Solutions containing non-critical violations won’t be blocked.
Admins of the environment (and the recipients of the Managed Environment weekly digest emails) will receive an email with a summary of the solution quality and whether the solution was blocked or not.

In Warn mode, solutions can be imported even if they weren’t checked with solution checker or if they contain critical violations.
Admins of the environment (and the recipients of the Managed Environment weekly digest emails) will receive an email with a summary of the solution quality. You have the option to opt-out of these emails.

Please note that in either mode, the solution checker is not run during the solution import. Solution checker enforcement will only verify whether the solution was validated using the solution checker in the past 90 days, and if it did, whether there are any critical violations.

How it works

To enable solution checker enforcement:

1. Sign-in to the Power Platform admin center.
2. In the navigation pane, select Environments, and then select a managed environment.
3. On the command bar, select Edit Managed Environments, and then select the appropriate setting under Solution checker.

What happens next?

After enabling, all custom solution imports will warn or block unless a valid solution checker result within the last 90 days is found. A valid solution checker run uses the Solution Checker ruleset with no exclusions or overrides and contains no Critical severity violations. You can run solution checker through maker portal or PAC solution check to generate results. Examples are shown below with Warn and Block mode with and without results.

Solution checker enforcement also sends an email to the environment administrators when a check fails or completes with warnings. This feature helps keep administrators up-to-date on the status of the checks, ensuring that any issues are addressed in a timely manner.

Looking forward

We are committed to providing Power Platform users with the tools and resources they need to build and deploy high-quality solutions, as well as the governance to efficiently perform application lifecycle management. Solution checker enforcement is just one of the many ways we are working to achieve this goal.

We encourage all Power Platform administrators to take advantage of this powerful new feature and provide feedback to help us continue to improve and refine the tool.

Please share your feedback/suggestions in this thread and see our documentation for more information.

The post Solution checker enforcement in Managed Environments appeared first on Microsoft Power Platform Blog.

Until now, users have had little transparency into the flow of model-driven apps unless they are comfortable wading through the complexity of browser developers tools or Fiddler.  It was hard to find events and logs that could help diagnose performance and functional issues.

We’re excited to announce that the Monitor tool is now available for model-driven apps!  The Monitor tool (currently supported on canvas apps) provides a way to view a stream of events from a user’s session in order to diagnose an issue.  As of this blog post, we support the following events on the latest build:

• KPI for page loads, command executions, and other major events
• Network request details
• Warnings for synchronous XHR’s
• Custom script errors (e.g. onload, ribbon rule evaluation)
• Form execution event details (e.g. onload, onchange)
• Form visibility reasons for controls and related menu items
• Power BI control failure and performance events

Note: depending on your CDS/Dynamics version, you may see a subset of these events as they roll out to your org.  Monitor for model-driven apps is currently only supported for browser sessions on online organizations.

Let’s take a look at Monitor in action!

There are two ways to enter a Monitor session for model apps.

1. Use the Monitor command from the apps page in Power Apps (see recent blog post for details).  Select any model-driven app and use the command from the top bar or the context menu to launch Monitor.  Then hit “Play model-driven app” from the Monitor page to launch your app.
2. Add “&monitor=true” to the end of the URL in the browser to show the Monitor button in the global command bar.  Clicking this button will launch a Monitor session in a new tab.  Note: as of this post, you need to “Play model-driven app” from the Monitor to connect a new session.  In the future, we’ll automatically connect Monitor to the existing session.

Once the app is launched from Monitor, you’ll see a Join dialog letting you know that any data from the app will be sent to the Monitor owner.

After hitting “Join”, events will start flowing to Monitor.  Let’s take a look at what events are being sent.

Events

Page navigations, command executions, form saves, and other major actions will send KPI and network events to Monitor.   Many events and fields are sent and supporting documentation will be published soon, but let’s take a look at some key ones below:

FullLoad signifies the complete load of a page navigation, such as an edit form load.  This waits for certain network requests to complete and all rendering to finish, so the form may indeed be usable before FullLoad completes.

The FullLoad event captures many statistics about the page load.  You can see the task edit form loaded in 506 ms, and clicking on the row reveals a wealth of information in the property pane.  As mentioned above, we will add more documentation on each field, but you can immediately see details on customScriptTime (time spend execute custom JavaScript), loadType (0 = first time loading page type, 1 = first time loading entity, 2  = first time loading record, 3 = exact record has been visited), and FormId (form identifier for further diagnosis).  Expanding Attribution gives a breakdown of custom JS execution time by type, publisher, solution, version, web resource, and method.  This can quickly help identify bottlenecks in form load time.

The Network events reveal details about each request made from the app:

You can see well-known network statistics like requestStart, responseStart, and decodedBodySize (see MDN documentation), as well as custom properties like whether the request was cached and sent as a fetch or XMLHttpRequest.

Solving issues and slow performance

Let’s look at a few scenarios where Monitor can shed light and solve script errors, unexpected behavior, and slowdowns.

Custom script errors

Sometimes, a bug in the custom JS will cause a script error or functionality issue when loading a page.  While this usually produces a call stack in the dialog, it’s hard to always know where it’s coming from or decode the error.  Monitor will receive an event from the app with more details on the error so you can debug more quickly and easily.

Let’s say a user is experiencing a script error dialog on account form load.  We can use Monitor to get more details on the event.  Once the scenario is reproduced, you can see the script error produces an error event highlighted in red.  Clicking on this row gives us not only the call stack but the publisher name, solution name/version, web resource name, and type (onload, onchange, RuleEvaluation, CustomControl, etc.).  Looks like a typo in the script, and we have a publisher to contact for a fix!

Slow performance

Browser developer tools can help profile slow page loads, but there is a lot of data to filter though and it’s not clear what is important to look at.  Monitor aims to solve that by showing relevant events that contribute to page load performance.

Let’s say a user is experiencing slow account form loads, and the browser is constantly freezing up.  In this case, once we reproduce, we can immediately see a performance warning telling us that a synchronous XMLHttpRequest was sent during the load which degraded performance.

See previous blog post for how to alleviate synchronous XHR performance issues.

For every page load, we send all KPI for the loading sequence as well as network request details as mentioned earlier.

Form control and related menu display

Look for a deeper blog post on this soon, but to give a sneak preview, Monitor will show events regarding tab and control visible/enabled state on the edit form.

If a user is wondering why a field isn’t showing up on an edit form, Monitor can easily help demystify.  In this scenario, the Last Campaign Date is not showing up on the account form.  There are series of uci_formchecker_* events produced on an edit form load (use the Category column filter if needed).  Once reproduced in a Monitor session, we can see the following event with Category uci_formchecker_controlstate_events.

Drilling into the details, we can scroll to Last Campaign Date and clearly see that The control is disabled in the form XML.  The action item is to Contact the form or entity owner to change it.

Feedback

We’re adding more events to model-driven apps every week to help diagnose common issues.  As always, please feel free to provide any feedback in the comments below or in our community post.  We’d like to know what’s useful to best support troubleshooting and transparency.

The post Monitor now supports model-driven apps appeared first on Microsoft Power Platform Blog.

In the XHR case, browsers still support an older model where data is fetched synchronously.  However, this model causes severe performance issues for end users, especially when the network is slow or there are multiple calls that need to be made.  Essentially, the browser freezes up and the end user is frustrated that they cannot click, scroll, or interact with the page.  See our guidance and MDN’s article for more details on the effect (as well as examples).  Transitioning to asynchronous web requests can shave seconds off end users’ form load times depending on the customizations.

Traditionally, the legacy web client has required certain extensions like ribbon rules to return synchronously, meaning developers were forced to use synchronous requests when requesting data from remote sources.  In Unified Interface, we’ve taken steps to ensure asynchronous communication is supported.  For example:

• Asynchronous ribbon rule evaluation is supported in Unified Interface.
• Async OnLoad and OnSave is supported in Unified Interface.
• Many customers needed to check privileges using Xrm.Utility.getGlobalContext().userSettings.securityRoles, looping through the collection to request role names from Dataverse.  We’ve added the roles property to userSettings to avoid the need to request role names.
• We’re working on asynchronous evaluation for grid item icons.

Today, running the solution checker will alert you of any detected synchronous requests with the web-use-async rule.

Examples

Let’s see an example in action.  As mentioned earlier, synchronous requests are typically used in ribbon rules since the legacy web client only supported this strategy.

// NOTE: Don't do this!
function EnableRule() {
    const request = new XMLHttpRequest();

    // Pass false for the async argument to force synchronous request
    request.open('GET', '/bar/foo', false);
    request.send(null);
    return request.status === 200 && request.responseText === "true";
}

The rule logic asks the server for some data, parses it, and returns a boolean value as its rule evaluation result.  Again, this freezes the browser for the end user until the request returns from the server.

Let’s see how we can convert this rule from synchronous to asynchronous.  By wrapping the request handlers in a Promise and resolving or rejecting when the request is finished, the rule will not block the browser from performing more work.  Of course, in practice, you will probably use helpers to wrap these types of requests so the Promise code does not need to be duplicated.

function EnableRule() {
    const request = new XMLHttpRequest();
    request.open('GET', '/bar/foo');
    return new Promise(function(resolve, reject) {
        request.onload = function (e) {
            if (request.readyState === 4) {
                if (request.status === 200) {
                    resolve(request.responseText === "true");
                } else {
                    reject(request.statusText);
                }
            }
        };
        request.onerror = function (e) {
            reject(request.statusText);
        };
        request.send(null);
    });
}

Using promises and asynchronous patterns, the user is now free to interact with the page while the request is out getting data.  No more freezing of the user interface while the page is loading!

Here’s another example of using the new roles property of userSettings to avoid synchronous requests.

// NOTE: Don't do this!
function userHasRole(roleName) {
    const roleIds = Xrm.Utility.getGlobalContext().userSettings.securityRoles;
    let hasRole = false;
    roleIds.forEach(function(roleId) {
        const request = new XMLHttpRequest();

        // Pass false for the async argument to force synchronous request
        request.open('GET', '/api/data/v9.0/roles(' + roleId + ')', false);
        request.send(null);
        if (request.status === 200) {
            const result = JSON.parse(request.responseText);
            if (result.name === roleName) {
                hasRole = true;
            }
        }
    });

    return hasRole;
}

Using the new roles feature provided by Unified Interface, no network requests need to be made at all:

function userHasRole(roleName) {
    const matchingRoles = Xrm.Utility.getGlobalContext().userSettings.roles.get(function(role) {
        return role.name === roleName;
    });
    return matchingRoles.length > 0;
}

Here’s a profile of the network requests before and after the above change (assuming the user has 10 roles).

Before (~2.3 seconds):

After (~1.2 seconds):

You can see over 1 second (~50%) shaved off the form load, and the content is rendered much faster without the synchronous requests!

We’ve also created a video tutorial to walk through this and more examples of using asynchronous requests.

We hope you will take advantage of these new capabilities in Unified Interface to delight your end users by providing a more responsive experience.  If you find yourself needing to use synchronous requests in any situation, please let us know so we can enhance the product to accommodate.

The post Turbocharge your model-driven apps by transitioning away from synchronous requests appeared first on Microsoft Power Platform Blog.

For each button on a given ribbon, the tool will show its calculated visibility status, the evaluation result of each enable/display rule attached to the button, and the command to be executed when clicked.  In addition, we have built the ability to see solution layers contributing to the final set of rules and buttons.

If you’re experiencing issues with command button visiblity or execution (or just curious about ribbon behavior), try out our step-by-step troubleshooting guide.

Let’s see the tool in action!  To enable Command Checker, pass ribbondebug=true as a URL parameter (ex: https://myorg.crm.dynamics.com/main.aspx?appid=c26d1c44-e7c0-4c72-9d6d-0e82768cb5bd&ribbondebug=true).  You’ll see two new UI features light up.  The first is a new button in the top right of the header which lets you inspect the global command bar

Next, each command bar contains a new “Command checker” button.  Note that this shows up at the end of the ribbon, so you may have to click the overflow flyout.

Let’s explore the experience upon clicking the button.  For this example, we’ll use the account edit form.  The tool is overlaid on top of the page as seen below.

On the left, the context and entity name are displayed above a tree of tabs, groups, flyouts, and buttons.  On the right, the details of the currently selected button are shown.  The tree is collapsible at any tab, group, and flyout level for a cleaner experience when desired.  The tree contents reflect the current state of the inspected ribbon (of course, this is dependent on each solution layer installed).

Buttons and flyouts in italicized grey are hidden, and those in black text are visible.  Note a flyout will be hidden when all its children are hidden.  Likewise, all children will be hidden when a flyout evaluates to hidden.

Let’s drill down into one of the buttons to see why it’s hidden.  We’ll use the Mark Complete button as an example.  Clicking on this button shows the following breakdown.

You can see the name of the button and other properties from the ribbon XML displayed on the right.  Clicking on Command properties on the right pane header will show details on execution and rule evaluation.

You can quickly see that the Mscrm.PrimaryIsActivity display rule evaluated to false in this page load, and in model-apps ribbons, the button is hidden if any rule evaluates to false.  Drilling down into the evaluation, you can see which rule was used to determine visibility.

The rule was an EntityPropertyRule which checks the IsActivity property of the PrimaryEntity (this being the entity used on the form).  Since the account entity has an IsActivity property of false, the rule itself evaluates to false, and the button is hidden.  This level of detail exists for all types of rules, namely the JavaScriptRule, which shows the exact function name and JS file used to determine visibility (example below).

This breakdown is intended to demystify the hiding and showing of buttons in any context, be it an edit form, subgrid, home page grid, or the global command bar.  The tool will also show the method to be executed upon click, including function name and JS file.

Let’s next look at the solution layer drilldown.  Within Command checker, you can view the solution layering, including diffing ability, for button, command, and rule definitions.  We’ll use the Save button on the opportunity form as an example.  In this example, Contoso has imported a rule to always show to the Save button, regardless of auto-save status.  Let’s click on the button, navigate to Command properties, open the Mscrm.IsAutoSaveDisable rule and click View rule definition solution layers.

You can see all solutions which contribute to this command definition with publisher, order, and entity context displayed.  One common mystery of button visibility is when many solution layers add and remove rules, so it’s hard to determine which are in the final set.  Let’s compare the custom and base solutions to see how a rule was modified.  We’ll select the two records.  Then we’ll hit Compare.

In this view, you can select any two solutions for button, command, or rule definition comparison.  Here, we are comparing the top solution (ContosoCustomization) with the base solution (System).  You can see that the top solution (on the right) has overridden the base rule definition and instead uses the alwaysEnabled function to return true, meaning the Mscrm.IsAutoSaveDisable rule will always evaluate to true.  This should help clarify how solution layering has impact on the final rule set.

Feedback

We hope you’ll take some time to try out this new diagnostics feature, whether investigating a user-facing issue or simply exploring the buttons and rules present in the system.

Please help us improve the tool by providing feedback in our Power Apps community post.

What’s next

We’re excited for you to try out Command Checker, and we’re already working on improvements to make it more useful:

• Allow Command Checker usage through a new privilege rather than URL parameter
• Support for the HideCustomAction element
• Visualize commands hidden server-side before they reach the client
• Support for buttons hidden for reasons other than rule evaluation
• Adding detection for common ribbon mistakes and show them as errors and warnings
• Show lock icons for system solutions that are not modifiable

The post Introducing Command Checker for model-app ribbons appeared first on Microsoft Power Platform Blog.