Plan your upgrade

Updating or upgrading to Dynamics 365 Customer Engagement (on-premises), version 9.1 depends on the version of Dynamics 365 Customer Engagement (on-premises) you have.  We have lots of useful content on how best to plan and manage your upgrade to version 9.1 available here.
 

Why move to Unified Interface?

Unified Interface is our presentation client we use across all of our Applications in Dynamics 365 Customer Engagement, and fully responsive from Desktop to Mobile to App for Outlook. By transitioning to the Unified Interface, you will be able to benefit by

• Optimizing your existing application investment
• Accessing a new and exciting modern responsive UI
• Enhancing end-user productivity in working with data in your business application
• Increased performance, with up to 63% improvements in common actions as compared to the legacy web client.

With support for Internet Explorer 11 ending soon, it’s also a great time to consider moving to modern browsers and get the performance benefits that these bring with the Unified Interface.
 

What features are in the Unified Interface?

There are a host of new UI usability enhancements within the Enterprise Sales and Customer Service applications that can help reduce friction and make features easier to use. These improvements, including the ability to deliver focused Apps for your end-users, as well as the many new features and benefits UI has over classic web client, will help you drive significant value for your businesses and happier end-users.

How do I transition to Unified Interface?

We’ve a lot of great content to help you to start planning and making the move to Unified Interface. Support materials including videos, articles, and documentation to help you plan and manage your transition are available below.

• Unified Interface FAQ
• Approaching a user experience and Unified Interface transition
• Transition Planning Checklist
• Getting Started Unified Interface Playbook

The post Dynamics 365 Customer Engagement (on-premises) SP1 version 9.1 is now available appeared first on Microsoft Power Platform Blog.

What’s New for Unified Interface in on-premise

Unified Interface uses responsive web design principles to provide an optimal viewing and interaction experience for any screen size, device, or orientation. It brings all the rich experiences to any client that you are using. Whether you are using a browser, tablet, or phone, you will be able to consume similar experiences. With this release, features and improvements that were previously only available online will now also be available on-premise, such as:

• Enterprise Sales usability enhancements
• Improved data management with record sharing, bulk edit and merge capabilities
• Timeline usability enhancements
• Agent productivity enhancements for knowledge capabilities
• Case routing rules
• Advanced Find
• Hierarchy view
• Improved navigation experiences
• Main form dialog editing experience for queue items
• Hybrid experiences like Sharing
• Personal views

What’s Next

The Microsoft Dynamics 365 for Customer Engagement Version 9.1, On-premises update will be available in the download center in Q2 2021. In March, we will publish the dates on when they will become available so you can plan your upgrades.

Upgrades from Microsoft Dynamics 365 version 8.2 or Microsoft Dynamics 365 version 9.0 to version 9.1 will be supported in order for customers to take advantage of the latest version of Unified Interface.  This is also a great time to upgrade your end users to a modern browser if they are still using legacy browsers.

The post Next on-premise update brings the latest version of Unified Interface appeared first on Microsoft Power Platform Blog.

To start debugging the published app, select an app from the app list in Power Apps and then select Monitor from the menu. In the Monitor, select Play published app. This will launch the published app in a new browser tab and connect it to your Monitor debug session. The Monitor starts capturing and displaying the events immediately from your app, including any warnings or errors that have occurred. Note, depending on when your app was last published, you may need to re-publish the app to connect it to the monitor.

You can also open Monitor from the Power Apps studio, just like you do today, and then select “Play published app” from the top menu in Monitor. If you open the published app using this method, you’ll have your app connected to the same Monitor session twice. The app being edited in Power Apps Studio and the published app in the web player. Events from both the Power Apps Studio and the published app will be shown in the Monitor if you interact with the app using both options at the same time.

Debug Published app setting

If you want to view the source expressions in the monitor for the published app, you need to turn on a new setting to publish the expressions with the app. This is like generating a debug file in traditional development. Some of you may not want to publish your source expressions with your app, and that’s OK. If you don’t turn this on, you will still be able to see the events happening in your app but you won’t be able to map these to specific expressions or formulas.

What else is new?

We’ve added new events and warnings in the Monitor, visual indicators for issues, and also new default fields in the events grid to help you understand the results of the various operations happening in your app.

Result and Result Info

201? 403? 429? Hmmm? Previously, to understand the status of network operations displayed in the event log, you needed to know what the various status codes meant. We are now translating these statuses into the Result and Result Info fields. For example, a 429 will show an “Error” result and “Too many requests” in the result info. Row colors also help to identify any errors and warnings quickly. We’ve started populating these fields for network requests, but we will be extending the Result Info to show other high level event information such as custom Trace messages and warning details soon.

Filter, LookUp, First, CountIf, CountRows

If a function can be delegated to a data source but it wasn’t, you will see a warning event in the Monitor. For example,  below we are using the LookUp function on a delegable data source. Lookup can be delegated, but it is using a selection formula that can’t be delegated. Because of this, only the first portion (default 500 rows) of the data source will be retrieved and then the function applied. This may cause unexpected results in the app as the LookUp is working against an incomplete data set, and your app may display incorrect results. It will also impact performance, as the data needs to be first downloaded to the client and processed locally vs the query being run on the server. These warning will help remind you of the delegation limits and possibly the need to switch to delegable alternatives.

Navigation and Screen Load events

As you play your published app, Navigation and ScreenLoad events can help you further understand your app performance and what screens are taking the longest time to load.  Depending on how your app is designed, you may also see an InefficientControlReferences performance warning.

Let’s dive into the InefficientControlReferences warning a bit more. To help improve performance, screens are only initialized and loaded in memory as they are needed. However, if you have formulas that reference controls on other screens, this can force the app to load these screens immediately (if they are not already loaded in memory), rather than waiting until the user navigates to that screen. This can cause performance issues by slowing down your screen navigation and you should try and remove these references. Using variables or collections to store the values you are referencing on dependent controls, or passing the values using screen parameters are ways you can work around this issue.

Viewing the details of the InefficientControlReferences event will tell you the cross-screen control dependencies that have caused the additional screen(s) to load. In the example, the employeeManager control on the Dashboard Screen references the managerName control on the employeeManagerScreen. There is also another control referencing the employeeDetailsScreen.

These cross-screen control references caused both the employeeManagerScreen and the employeeDetailsScreen to load when the “Dashboard Screen” was first navigated to and performance would have been impacted.

What’s next?

• Providing additional event details in the Result Info for Trace, delegation warnings and collection operations.
• Supporting Model-driven apps with performance telemetry events for page loads, form saves, command execution, network and script timings.
• Debug an end-user app session and view the events and any issues happening for that specific end-user as they are playing the app.

If you have any feedback, we’d love to hear it. You can provide it below, or on our community forum post.

The post Use Monitor to debug your published app appeared first on Microsoft Power Platform Blog.

“Click the button in the top right, no, not that button, the other one. OK, now select the second row and the + icon on the right…let me take control!” – yes, we’ve all experienced this at some time, trying to walk a teammate through the exact steps to reproduce an issue. We typically end up doing screen shares and passing control back-and-forth until the issue is reproduced and the right data is captured. It would be easier to reproduce the issue yourself and for everyone to view the same event logs in real-time together, and this is where the new Invite feature in monitor can help.

With the Invite feature, you can ask your teammates to participate in your Monitor debug session. They do not have to open the app or reproduce the specific scenario you are debugging. You can reproduce the issue in the app and then your teammates will see the exact same app events in their own monitor browser window in real-time. You can then collaboratively work together, inspecting different sections of the log without stepping on each other, and cut-down the time to find the problem.

To invite your teammates, or anyone in your organization, start a monitor session from the Canvas studio advanced tools panel. Select Invite in the in the Monitor and enter the name or alias of the user(s) who you want to collaborate with. Copy and send the link to your teammate. When your teammate opens the link, it will connect them directly to your monitor session, and they will see the events and data generated from your app in real-time in their own browser window.

Note, the link is unique to the invited user and it cannot be shared with others. The link is valid for 60 minutes.

What else is new?

We’ve recently added other improvements to the Monitor such as extending the events shown to include custom traces and debug statements as well as user actions taken in your app. We’ve also color-coded expressions to make it easier to map your events in the formula panel. The download/upload feature allows you to archive or share the event logs with your teammates. This can also help support teams review your issues faster so consider providing a log file if you are raising a support ticket.

Upload/Download event logs

You can download the event logs that are shown in the table for offline analysis and troubleshooting issues later. The downloaded trace file can be exported as a .json or excel file and shared with others so they can help you solve your problem. Excel files are download only, but if you export the events in json format, these can be uploaded back into the monitor to help analyze the details offline. If you are escalating a problem, you can also attach the json log file to your support service request, and this could help expedite the solution to your problem.

Add custom debug statements

Using the Trace function, you can now write your own messages and debug statements at various points in your app and have them displayed in the monitor log. You can write messages and output variable values or a record in the trace expression.

For example, say you are interested in the value of a variable called NumKudosToShow. You could Trace this value to the monitor using the below expression in your app.

// Trace values to monitor 
Trace(“Debug: value of NumKudosToShow is ” & NumKudosToShow);

Alternatively, you could Trace multiple values at once using the below expression.

Trace(“Debug values: Screen – ” & screenName, TraceSeverity.Information, {dashboardKudosCount: CountRows(dashboardKudos), NumKudosToShowValue:NumKudosToShow});

The output of the trace can be viewed in the Details tab in the properties panel.

User Actions

Even if an action on your app does not result in a network call, you will be able to understand what operations are taken such as clicking a button on a screen, or typing text into an input box.

Expression mapping

In a large formula, it was difficult to identify the expression which mapped to the event you were viewing. It took a bit of scrolling up and down or using the search and find option to get it. We’ve now made this a lot easier to find by highlighting the specific expression in the formula which caused the related event. In the example below, the expression related to a getRows operation is highlighted in the formula, allowing us to quickly identify the formula for the event.

What’s next?

We have some more exciting new features planned and we will be rolling these out soon – debugging the published app, debugging a specific end users app session, new screen load performance events and delegation warnings as well as tracing for Model driven apps. We’d love to hear your feedback on the new invite feature and improvements. Let us know how you are using the monitor and what additional information would you want to see that would help you debug and improve your apps? Please provide your feedback below, or directly in the tool which links to our community forum post.

The post Collaborate and debug an app together in real-time with Monitor appeared first on Microsoft Power Platform Blog.

Automating tests in a release pipeline can help teams catch issues fast and prevent any bugs or quality issues leaking into production environments and impacting end-users. From today, you can now use the PowerAppsTestAutomation project published on Github to help you set up your pipelines and run your automated tests.

With UI automation tests, you need to login to your application unattended, meaning the system needs to open a browser and authenticate as a user for that application. The PowerAppsTestAutomation project abstracts you from the complexities of writing this code yourself, and it helps you automate the operations of logging into your application, opening a browser on the build agent, executing a set of test cases or test suites, and providing the status of the test execution in the DevOps pipeline.

You can refer to this documentation for more details on how to set up your pipeline and configure the steps to automatically run your app tests.

After running the pipeline to execute your app tests, you can view and get alerted to any issues that may have broken the functionality in your app, and use this data to potentially stop your release and prevent these issues impacting end-users.

What’s next?

This initial release is the first step towards helping you build testing into your release processes. We want to make configuring the pipeline easier and we will soon publish documentation on how to set it up using a YAML pipeline template.

Let us know what you think by sharing your feedback below or on our community feedback discussion thread!

The post Automate your Canvas tests in your DevOps pipeline appeared first on Microsoft Power Platform Blog.

Getting started

Before you can send telemetry for an app, you will need to create an Azure Application Insights resource to store the events. To create an App Insights resource, you can follow the documentation here. After you create your App Insights resource, you are going to need the instrumentation key so copy or take a note of this value.

Connect your app to Application Insights

Open your app and the select the App object. In the App object panel, update the Instrumentation key property to your Azure App Insights instrumentation key. After you update the instrumentation key, save and publish your app.

Great! That’s all you need to start gathering telemetry for the app! Play the published app and navigate to various screens.  Screen navigation events will get automatically logged to App Insights along with usage information on where the app is getting accessed from and on which devices and browsers. Let’s view the events and see the insights you have generated from adding the instrumentation key to your app.

Viewing events in App Insights

Open the App Insights resource you created and select Users in the left navigation menu. In this view, you can see how many people have used the app (these are not unique users, but I’ll have more about that later), the number of sessions for the app and the number of events logged. Details about where the users are located and the browsers and operating systems they use are also displayed. Drilling into one of the user sessions, you can explore detailed information such as the session length, the screens visited and also low-level transaction details.

In the Events view, you get a summary of all the screens viewed across all app sessions. You can use this information to analyse and understand screen usage or feature adoption in your app and make data-driven based decisions on your next features. For example, you may want to stop future investments on specific screens due to low usage and prioritize other features in the app.

User Flows is another great visual which shows how users navigate around your app. You can use this view to analyze the most used navigation paths. Can you reduce clicks and optimize the paths to the most popular features for your end-users? 

I’ve just given you a small sample of the capabilities in App Insights. App performance, Funnels and Cohorts and plenty more out-of-box features of App Insights can be further explored here.

Custom Logging

Using the new Trace function, you can also write custom traces directly to App Insights and start to analyze information specific to your scenario. Use Trace to provide more granular usage information for controls on screens, which specific users are accessing your app or even what errors are occurring. Tracing can also help diagnose various issues as you can send a trail of information as your users navigate through your app and perform various actions.

The Trace function accepts a custom message, a severity level and a custom record containing data which will be logged as custom dimensions for the event to App Insights. As well as the custom dimensions you define for each Trace event, the platform will also add a set of default dimensions to every event raised – these are the ms-appSessionId, ms-appName and the ms-appId and they can be used to help you determine the app and session the event correlates to.

So, what can I log? Well, anything really. For example, you might want to record every time a user selects a button in your app, or every time a new feature is used, or the email address of the users accessing your app.
Note: If you are logging any personnel data, you will need to consider any data compliance obligations, such as GDPR, that you may also need to implement. 
Below is an example of a Trace expression I can add to the App OnStart event to gather user login information. 

Maybe you want to know how many errors happen in your app or how many times a record failed to write to your data source.  I can use the Errors function to check for a Patch error when writing a record and then log an event if any patch errors happened.

From App Insights, I can then create an alert to automatically notify me if errors get logged, or if there was a sudden increase in errors experienced in the app.

Now, after publishing and playing the app again, you will see new events generated in App Insights. These events will be displayed in the session details or you can directly query them from the Logs.

Querying Application Insights Logs

If you want to go deeper and leverage the full power of the data you are collecting, you will likely need to write log queries to analyze the App Insights data tables.  Log queries are extremely powerful and you can use them to join multiple tables, aggregate large amounts of data and perform complex operations. You can learn more about Log queries here. 

Using the Trace expressions I wrote above,  I’d like to know which specific users experienced an error when saving my data, and at what time those errors occurred. To get this, open the Logs in the Monitoring section in the left menu, and in the window write the query below .

From the results, I can see 3 users received an error when saving data. In total, there have been 12 errors, and one user (yes, that’s me!) received 5 errors within a 30 min time frame.  Using one of the sessions Id’s displayed, I could dive further into the various Trace and screen navigation events that happened for a session which had an error.

The post Log telemetry for your Apps using Azure Application Insights appeared first on Microsoft Power Platform Blog.

But what is a test case? It’s simply a list of steps, which are expressions that can simulate interaction with the app and validate that the app is in an expected state after those interactions. Those expressions use the same functions that can be used in apps, with the addition of new functions that were added for testing purposes. For example, in your test you can fetch a record from a data source to validate whether the interaction with the app had the expected result. When a test finishes you also have the option to persist the test results, such as whether the test passed or failed, how long the test took and any additional information generated by the test, to a data table, SharePoint or via a flow for example.

To help with creating the test steps or expressions that are needed to interact with the app, you can open an existing app in “recording mode”. As you interact with the app the test studio will generate the expressions that are used to perform that action. This gives you a great way to start creating tests and get acquainted with the syntax for the new test functions.

This first version is focused on Canvas app tests and it currently supports the most popular controls used in apps. But this is just an initial step. We’ll be adding support for more controls soon, as well as new features to help you schedule your automated tests into your processes. This feature is still experimental, so we recommend you use it to write tests for non-production apps and provide us any feedback.

Testing your app

So, let’s dive into testing in Power Apps. But before we can test something, we need an app. For this post, I’ll work with one created from the “Start from your data” wizard, based on a SharePoint list.

Opening Test Studio

At this point, we can only add tests to apps that have been saved to Power Apps, so since this iteration of the app is ready, let’s save it. You will also need to enable the Formula-level-Error management feature for the app as some test errors require this feature to work properly. 

And now it’s time for some testing. Just like the Monitor tool, you can find the entry point to the Test Studio in the new Advanced tools tray:

If you select the Open tests option, it will open a new browser tab with the Test Studio, connected to the existing authoring session:

Creating a new test case

Let’s start creating a test right away. The easiest way to do this is to click the ‘Record’ button on the menu and to start interacting with the app. You will see your actions being recorded in the left pane. Select ‘Done’ when you have finished recording.

Editing your test case

Once you click ‘Done’, you’ll see that the expressions used to recreate the actions you took in your the app are added as steps for the selected test case. We can now edit the existing steps, including updating the expressions, adding / deleting steps, and reordering them. Let’s update the third step (where we set the title of the new entry) to

SetProperty('DataCardValue4'.Text, "Test entry")

Let’s also add a new step at the end of the test to validate that a new entry was created in the SharePoint list. We can use a new test expression called an Assert to test this. Add the new test step with the following description:

Validate that there is one test entry

and with the expression below. This will assert that we can find the entry with the given title in the data source:

Assert(!IsBlank(LookUp(TodoList, Title = "Test entry")), "The entry should have been inserted")

The test steps should now resemble the image below:

Running the test case

Now click ‘Publish’ on the ribbon of the Test Studio. For now, we can only run tests once the app has been published. The tests are part of the app and we need to publish the app for the steps to be available for the “test runner”. Once the app is published, you can now click the ‘Play’ button, and you’ll see the test being executed.

Detecting problems in the app

Now that we have a test case, let’s see how it can detect problems in the app. Going back to the original tab where the app is being edited, preview the app then delete the entry that we added (with the title ‘Test entry’). Update the OnSelect property of the IconNewItem1 in the first screen to comment out the navigation to the edit screen:

NewForm(EditForm1); // Navigate(EditScreen1, ScreenTransition.None)

Save and publish the app. You may need to wait about a minute or so before the publishing is done in the back end. Go back to the tab with the Test Studio, select the test case again, and click Play one more time:

As we can see, the test failed when it tried to interact with the text input control that holds the title of the new item. If someone had inadvertently introduced that “bug” in the app, running the test would have caught it right away. We can then fix the app to avoid giving the users a bad experience.

Running the tests outside the Test Studio

If you select the ellipsis for a test case or test suite in the tree view, or select the ‘Copy play link’ in the top-right corner of the screen, you can copy a URL that can be pasted in a browser window. This will open the app in the browser and run that selected test or test suite. This allows for several scenarios, such as having different people executing the test (and, as the test runs with their own credentials, catch issues that the app maker may not be able to),  or even provide a “walk-through” of the app by simulating the interaction of the app controls. It can also be used to schedule or automate the running of your tests from a release pipeline or using Power Automate UI flows.

Storing test results

When the test is run outside the Test Studio, you don’t get to see the green/red marks indicating whether the test passed or failed. To access the test outcome, you can use one of the behaviors that you can see from the test settings:

The formula that you enter for the OnTestCaseComplete action will be executed whenever a test is finished (successfully or not) in the app. In the formula you can, for example, store the result of the test into a data source, or start a flow that you have in your app with it.

Within the OnTestCaseComplete expression you have access to a new variable, scoped to that rule only, called ‘TestCaseResult’, which is an object with the following properties:

• StartTime: the moment the test started
• EndTime: the moment the test finished
• TestCaseId: the identifier for the test case; this is a value that uniquely identifies the case, so even if you have multiple cases with the same name, they can still be reason separately
• TestCaseName: the name that you can set for the test case in the Test Studio
• TestCaseDescription: the description for the test case in the Test Studio
• TestSuiteId: the identifier for the test suite that contains the test case
• TestSuiteName: the name that you can set for the test suite in the Test Studio
• TestSuiteDescription: the description for the test suite in the Test Studio
• Success: a value that tells you whether the test passed (true) or failed (false)
• TestFailureMessage: if the test failed, a message that indicates which step failed and why
• Traces: a table of values with additional information about the test (all calls to Assert and Trace generate entries in this table)

If we have a data source with corresponding properties, we could have this expression in the OnTestCaseComplete to save the results for the test:

Patch(
TestResults,
Defaults(TestResults),
{
StartTime: TestCaseResult.StartTime,
EndTime: TestCaseResult.EndTime,
Result: If(TestCaseResult.Success, "PASS", "FAIL"),
SuiteId: TestCaseResult.TestSuiteId,
SuiteName: TestCaseResult.TestSuiteName,
SuiteDesc: TestCaseResult.TestSuiteDescription,
TestId: TestCaseResult.TestCaseId,
TestName: TestCaseResult.TestCaseName,
TestDesc: TestCaseResult.TestCaseDescription,
FailReason: TestCaseResult.TestFailureMessage
})

Or if you want to send the entire object to be analyzed by a flow, you can use the JSON function to wrap the object and send to the flow:

MyTestResultsFlow.Run(JSON(TestCaseResult))

Organizing test cases in suites

One test case represents one certain scenario where the user is interacting with the app. An app may have many tests, and to better manage them it may make sense to group the test cases into related areas. Those are called test suites, a grouping of test cases that “belong together”. Just like you can play a single test case (either directly in the Test Studio or in a separate browser tab/window after copying the play link), you can play an entire test suite which is equivalent to playing all test cases of that suite in order. Once the first case of the suite is done (and the logic defined on the OnTestCaseComplete action is executed), the second test case is executed (and again the OnTestCaseComplete logic once it’s finished), then the third, and so on.

It’s important to reinforce the behavior explained in the previous paragraph. The first test in a suite will always start as if the app had been just opened. Once that test finishes, the next test will start from that point in the app. One advantage to this mode is that you can use it to break down a large test case into multiple ones within a single suite. However, if a test case expects the app to be in its initial state when it starts, it may fail if the previous test in its suite modified it. For example, leaving the app in a screen other than the first one. In many cases you can use the OnTestCaseComplete action to reset the app state if that’s what your suite needs.

Like when a test case finishes, when you’re running an entire suite, Power Apps will execute the formula defined in the OnTestCaseComplete behavior of the test object. That behavior has access to a new variable, called ‘TestSuiteResult’, which is an object with the following properties:

• StartTime: the moment the test suite started
• EndTime: the moment the test suite finished
• TestSuiteId: the identifier for the test suite
• TestSuiteName: the name that you can set for the test suite in the Test Studio
• TestSuiteDescription: the description for the test suite in the Test Studio
• TestsPassed: the number of tests that run successfully in the suite
• TestsFailed: the number of tests that had failures in the suite

Going deeper

Now that we’ve taken a quick tour through the Test Studio, let’s dive a little deeper into some of the new test functions that can be used within test cases. Here’s a summary of them (for more details, go to the function reference)

• SetProperty:  used to simulate interaction with most of the input controls.
• Assert: used to verify that a certain condition is true in the test and cause the test to fail if not. The first parameter to the function can be any logical (true/false) expression that you can write with the Power Apps language, and it can also take an optional second parameter that describes what the assertion is about.
• Trace: used to add additional information to the TestCaseResult record that can be accessed in an expression within the OnTestCaseComplete behavior.  Trace is a table with a row for each of the Assert and Trace functions that were called within the test. The records of the rows have two properties: Timestamp (date/time value) and Message (text value).
• Select: this function has been in the product for a while, but it could only be used to simulate the select action of a control within the same screen. In test cases this restriction has been lifted, so a step in a test case (which doesn’t belong to any screen) can use this function to simulate the selection of a control on any screen – although during the test execution if the control is not in the current screen the action will fail, as a user could not do that in the app. The function has also been enhanced so that we can also select controls inside galleries, with additional (optional) arguments to that function to determine the row of the gallery to be selected, and the control inside the gallery. Currently only 1 level of nesting is supported, galleries inside of other galleries are not for this new functionality.

Test runner details

If you took a look at the URL generated by the ‘Copy play link’ option in the Test Studio that we mentioned before, you’ll see that it’s very similar to the URL that you get when you play the app from the Power Apps Maker Portal (make.powerapps.com). It has an extra query string parameter that triggers the test runner logic. It means that the test cases are great at testing the app exactly because they’re running with the same app that is used by users. You can, for example, add additional query string parameters to that URL and access them via the Param function.

This also has another very important point to be aware of . Since the tests run as if a user was interacting with the app, it can also create / update / delete records from your data sources, so be careful in your tests not to take actions that could, for example, remove records that it shouldn’t from your data source. One option is to have a specific column in your data source that flags items as test-only, a prefix in the name / title of the records, or something that can be used to identify test objects which can be ignored when the app is being used by “regular” users.

We want to hear from you

I already mentioned it before but it’s worth saying it again, but this is the first version of this feature and we want to let you start exploring and using it now. We’d love to hear your feedback, so we can prioritize the next set of improvements, any features that are missing, or any of the current behaviors that may not be ideal.

What kinds of tests are you writing? Is there anything that is too hard to understand, and that we could make easier?  There is a ‘Provide feedback’ link in the Test Studio which leads to our community forum for sharing your ideas.  We really want to hear your feedback!
 

There is some work that we already know that we need to complete which we have already started such as:

• Full control coverage for recording and playback capabilities. This includes both native and those based on the Power Apps Component Framework (PCF), and controls within components
• Better support for automation, such as running tests in Azure DevOps on a daily / scheduled cadence. Stay tuned as we’ll have further posts on options to schedule and automatically run your tests soon.

Let us know what you think as you start building tests for your apps!

The post Introducing Test Studio to build end-to-end tests and maintain your app quality appeared first on Microsoft Power Platform Blog.

This enhancement is currently available if you are using the Power Apps checker PowerShell module, Azure DevOps task, or direct web API interactions.  If you validate your solutions from the PowerApps maker portal using Solution checker, the enhancement has begun rolling out across the regions and it will be available over the next few weeks.

Let us know what you think or provide any feedback through the PowerApps Forum. 

The post Power Apps checker now includes Flow checker results for Flows in solutions appeared first on Microsoft Power Platform Blog.

For Canvas apps you can view a list potential issues as you are building your apps using the App checker.  The App checker lists any formula errors, accessibility warnings and now also performance optimization tips.  From today we are happy to announce that for Canvas apps packaged in a solution, you can also see a list of potential issues directly using PowerApps checker in any of its forms, Solution checker in the PowerApps maker portal, PowerShell module, Azure DevOps task, or direct web API interactions. To view a summarized list of issues, you will need to republish any existing apps with the most recent version of the Studio before the results are available.

We’ll be including more solution components in the PowerApps checker results in the  future, so let us know what you think or provide any feedback through the PowerApps Forum.

The post PowerApps checker now includes App checker results for Canvas apps in solutions appeared first on Microsoft Power Platform Blog.

In addition to checking for formula and accessibility issues, the App checker will also check for potential optimizations to improve the run-time performance of your app. The app checker will list each optimization identified and selecting the item in the list will provide additional information about the optimization and how to fix it.

Inefficient delay loading

To improve performance, the screens of an app are loaded into memory only as they are needed. This optimization can be impacted if there are dependencies between app screens. For example, if a screen references a property of a control from another screen, then both screens need to be loaded before the screen is displayed. A large dependency chain can be created and result in many screens loaded if screen 2, references screen 3, which references screen 4, and so on.

For this reason, try and avoid dependencies between screens. The recent PowerApps Optimization Techniques blog post discussed options to improve app start-up time and you can see here how the use of global variables can help avoid cross-screen dependencies.

Text input controls with large dependencies can impact performance

If you have multiple formulas or rules that reference the value of a Text input control, set the DelayOutput property of that control to true. The Text property of that control will be updated only after keystrokes entered in quick succession have ceased. For example, if you have a gallery control whose items are filtered on the values entered in the text control, then the gallery will be filtered as soon as anything is typed. This will cause the gallery to reload every time. With DelayOutput = true, there is a delay before the changes are detected. The formulas or rules won’t run as many times, and app performance will likely improve. If there are 20 or more references to the value of a Text input control, and the text input control has DelayOutput set to False, a warning will be shown in the App checker.

Limit the number of controls on a screen

The more controls you add to a screen, the more time PowerApps needs to render the page on the browser or device. There are a lot of varying factors, such as the type of control, however, at this time we are providing general feedback when we observe that there are more than 300 controls on a screen. This should not be a hard and fast rule, but it was important to indicate that this could be a possible reason if you experience slow loading times. We are continuously working on optimizations to the platform so this threshold may increase over time or this rule may be removed altogether.

The post App checker now includes performance optimization tips appeared first on Microsoft Power Platform Blog.