2110557

Author: tapanm-MSFT

powerapps-docs/maker/monitor-advanced.md

@@ -16,13 +16,13 @@ search.app:
 
 # Advanced monitoring concepts
 
-In this article, you'll learn about downloading and uploading trace files in Monitor, events supported by Monitor, and scenarios that Monitor doesn't support.<!--note from editor: Suggested.-->
+In this article, you'll learn about downloading and uploading trace files in Monitor, events supported by Monitor, and scenarios that Monitor doesn't support.
 
 ## Download and upload trace files
 
-You can download the events listed in [Supported events](#supported-events) for offline analysis.<!--note from editor: Is this what you meant by "events that are shown in the table"?-->
+You can download the events listed in [Supported events](#supported-events) for offline analysis.
 Events can be downloaded in .json or .csv format, and you can share them with
-others. The .csv files can only be downloaded, not uploaded, but if you download<!--note from editor: Edit okay? Or is "export" different somehow?--> the events
+others. The .csv files can only be downloaded, not uploaded, but if you download the events
 in .json format, you can upload them later into Monitor for analysis. You can
 also attach a trace file to support service requests, which can help speed up getting the solution to your problem.
 
@@ -49,7 +49,7 @@ Monitor doesn't support the scenarios in the following table.
 |Monitor connected to apps running on a mobile device (native players).     |  Canvas    |
 |Monitor connected to a canvas app embedded in a model-driven app or custom page.     |  Canvas       |
 |Monitor connected to a SharePoint custom form app.     | Canvas        |
-|Monitor connected to a Microsoft Teams embedded app.<!--note from editor: Should this be "a Power Apps app in Microsoft Teams."? --> As an alternative, you can play the app in a web player for diagnostics purposes.     | Canvas        |
+|Monitor connected to a Microsoft Teams embedded app. As an alternative, you can play the app in a web player for diagnostics purposes.     | Canvas        |
 |Monitor isn't supported on Internet Explorer version 11.     |  Canvas and model-driven       |
 
 ### See also

powerapps-docs/maker/monitor-canvasapps.md

@@ -15,7 +15,7 @@ search.app:
 ---
 
 # Debugging canvas apps with Monitor
-<!--note from editor: Please check my edit to the title in metadata; it shouldn't be the same as the H1. Also, please note that the sister topic to this one, monitor-modelapps.md, should have an H1 of "Debugging model apps with Monitor," to be parallel. (The Writing Style Guide prefers the way you have it here, with the H1 as a noun and the H2s as verbs. I realize that you don't own that topic, though.)-->
+
 Monitor is available by default for all canvas apps. Using Monitor, you can trace events as they occur in a canvas app during the authoring experience in Power Apps Studio, or you can use Monitor to debug the published version of a canvas app. More information: [Monitor overview](monitor-overview.md)
 
 ## Get started with Monitor in canvas apps
@@ -72,7 +72,7 @@ Monitor also displays a notification that the monitoring session that's currentl
 
 ### Advanced setting: Debug published app
 
-If you want to view the source expressions in Monitor for the published app, you need to turn on the<!--note from editor: Unless you plan to come back and remove "new" at some point, I suggest not saying this is new because it won't always be.--> setting to publish the expressions with the app. This setting is similar to generating a debug file in traditional development. Publishing source expressions with your app is optional. Even when this setting is off, you'll be able to see the events happening in your app, but you won't be able to map these events to specific expressions or formulas.
+If you want to view the source expressions in Monitor for the published app, you need to turn on the setting to publish the expressions with the app. This setting is similar to generating a debug file in traditional development. Publishing source expressions with your app is optional. Even when this setting is off, you'll be able to see the events happening in your app, but you won't be able to map these events to specific expressions or formulas.
 
 To enable this setting, go to **File** > **Settings** > **Advanced settings**, and then turn on **Debug published app**.
 
@@ -90,11 +90,11 @@ display the table of events as they're occurring, along with specific details.
 In this example, you'll use the Northwind Sample Data app included with
 the [Northwind sample solution](https://docs.microsoft.com/powerapps/maker/canvas-apps/northwind-install).
 
-The *Northwind sample solution* is a canvas app that loads sample data into Microsoft Dataverse<!--note from editor: Edit okay?-->. You can also create a new app or use an existing app instead.<!--note from editor: Generally, you want to reserve italics for defining a term (as you are here) and for a few other specific cases (parameters, variables, book titles), but not error messages or file names.-->
+The *Northwind sample solution* is a canvas app that loads sample data into Microsoft Dataverse. You can also create a new app or use an existing app instead.
 
 ### Background
 
-Consider the scenario where an app has been deployed, and the initial version of the app experiences performance degradation. The app also intermittently generates errors with no clear pattern. Loading data in the app succeeds most of the time, but fails sometimes.<!--note from editor: Edits in this paragraph suggested, but if you don't like, note that "succeeds mostly" implies that it doesn't quite succeed all the way.-->
+Consider the scenario where an app has been deployed, and the initial version of the app experiences performance degradation. The app also intermittently generates errors with no clear pattern. Loading data in the app succeeds most of the time, but fails sometimes.
 
 When you check Monitor, you see data operations as expected. However, you also see several responses that have HTTP status code 429, indicating that there have been too many requests in a specific timeframe.
 
@@ -106,17 +106,17 @@ When you select such an event, you see the error as "Rate limit exceeded. Try a
 
 The problem needs further analysis to understand why requests are getting
 throttled. In Monitor, you see that for each **createRow** call, there are
-several **getRows** requests from the **ProgressCount.Text** property, each to a different entity. These entities aren't the entities the app is creating rows for. The **ProgressCount.Text** formula is seen in Monitor, as shown in the following image.<!--note from editor: If the reader can't see the image, will they understand what's going on here? It seems to me that you've explained the behavior fully, but you'd be the better judge of that. If the formula needs to be fully duplicated, you can use the :::image type="complex"::: extension.-->
+several **getRows** requests from the **ProgressCount.Text** property, each to a different entity. These entities aren't the entities the app is creating rows for. The **ProgressCount.Text** formula is seen in Monitor, as shown in the following image.
 
 ![Error 429 - Formula](media/monitor/error-429-formula.png "Error 429 - Formula")
 
 For each record added, the formula is evaluated again and **CountRows** is
 called on several entities. This behavior results in **getRows** in the log,
-because **CountRows** isn't delegated for Dataverse<!--note from editor: Edit okay?-->. For each single
+because **CountRows** isn't delegated for Dataverse. For each single
 request to add a record, you're potentially making 12 additional requests to
 count the rows in each entity.
 
-These extra requests intermittently cause errors because the Dataverse<!--note from editor: Edit okay?--> platform is throttling the requests to the service. This also explains the overall performance problem.
+These extra requests intermittently cause errors because the Dataverse platform is throttling the requests to the service. This also explains the overall performance problem.
 
 ## Next steps
 

powerapps-docs/maker/monitor-collaborative-debugging.md

@@ -16,18 +16,18 @@ search.app:
 
 # Collaborative troubleshooting using Monitor
 
-Monitor offers two features to enable collaborative troubleshooting and debugging of problems in Power Apps:<!--note from editor: Via style guide, we "don't use the possessive form of Microsoft trademarks and product, service, or feature names". Also, I suggest using bullets here; I think they make it a bit easier to read.-->
+Monitor offers two features to enable collaborative troubleshooting and debugging of problems in Power Apps:
 
 - **Invite** enables makers to share a monitoring session by inviting other members within the same organization to the same Monitor session. For example, a maker troubleshooting a performance problem with Power Apps can invite a member from the technical support team to concurrently view all the events flowing through the same troubleshooting Monitor session.
-- **Connect user** enables makers and support teams to share a link with users to open a published app and connect it to a Monitor session so that support teams can watch the sequence of events generated by the user's interaction.<!--note from editor: Edit assumes this will be one user at a time, which I think is the case?-->
+- **Connect user** enables makers and support teams to share a link with users to open a published app and connect it to a Monitor session so that support teams can watch the sequence of events generated by the user's interaction.
 
 ## Invite user
 
 Makers can share a real-time Monitor session with others, such as support technicians, to help investigate problems. When you invite other users to your Monitor session, you can quickly collaborate and debug an app together, without the need to share your screen. When you invite others to participate in a session, they see the exact same app events in their own browser without having to open the app or reproduce the specific scenario that you're debugging. You and other participants can browse, view, and inspect the app events independently, without stepping on each other or handing control back and forth to identify the problem.
 
 ![Invite user process flow](media/monitor/invite-user-flow.png "Invite user process flow")
 
-When using the **Invite** feature for a published app:<!--note from editor: Does this work only for published apps? If so, should the H2 be ## Invite user (published apps only)? Or should there be a note at the top of the page that says these features only work in published apps?-->
+When using the **Invite** feature for a published app:
 
 1. User A plays the published app from [Power Apps](https://make.powerapps.com).
 1. User A invites User B to a Monitor session.
@@ -47,9 +47,9 @@ including any data.
     ![Invite on the Monitor command bar](media/monitor/invite.png "Invite on the Monitor command bar")
 
 1. Enter the Azure Active Directory user name or alias of the user whom you want
-    to invite to the Monitor session.<!--note from editor: I'm a bit confused here. Should this be plural in the step and in the alt text? Or singular in both (see line 63) -->
+    to invite to the Monitor session.
 
-    ![Invite users](media/monitor/invite-user-search.png "Invite users")
+    ![Invite user](media/monitor/invite-user-search.png "Invite user")
 
 1. Select the user for whom you want to generate a link to the current Monitor session.
 
@@ -60,7 +60,8 @@ including any data.
 
     ![Invite user - copy link](media/monitor/invite-user-link-copy.png "Invite user - copy link")
 
-Repeat steps 2 through 4 for each user you want to invite.<!--note from editor: Edit okay? As noted above, it's a bit murky whether you create a big list of people and then invite them one by one, or do you do all the steps serially for each user.-->
+Repeat steps 2 through 4 for each user you want to invite.
+
 The users who have received the link can use it to open the Monitor and connect to your Monitor
 session.
 

powerapps-docs/maker/monitor-overview.md

@@ -20,11 +20,11 @@ Monitor is a tool that offers makers the ability to view a stream of events from
 
 ## Benefits
 
-Monitor can help you diagnose and troubleshoot problems faster, and build more reliable apps. It provides a deep view of your app by logging all the key activities that occur in the app as it runs<!--note from editor: Suggested, to cut down on the repeated words.-->. Monitor also provides a better understanding of how the events and formulas contained in your app work, so you can improve performance and identify any errors or problems.
+Monitor can help you diagnose and troubleshoot problems faster, and build more reliable apps. It provides a deep view of your app by logging all the key activities that occur in the app as it runs. Monitor also provides a better understanding of how the events and formulas contained in your app work, so you can improve performance and identify any errors or problems.
 
 ## Debugging an app
 
-The key to debugging a problem is to have a better understanding of what your app does, and how it does it. Sometimes it's difficult to isolate a problem by just looking at the app formulas, or even by reviewing runtime errors. Watching the events as they occur in your app can help you understand the order of events and how your app is performing<!--note from editor: Suggested.-->, to spot errors and diagnose problems faster.
+The key to debugging a problem is to have a better understanding of what your app does, and how it does it. Sometimes it's difficult to isolate a problem by just looking at the app formulas, or even by reviewing runtime errors. Watching the events as they occur in your app can help you understand the order of events and how your app is performing, to spot errors and diagnose problems faster.
 
 Some examples of problems and queries that you can uncover when using Monitor are:
 
@@ -57,7 +57,7 @@ You can review various properties for each event inside Monitor. Depending on th
 | Column name       | Description                                                                                                                                                                                                                                       |
 |-------------------|-----------------------------------------------------|
 | **Id**            | The sequence number for the events.        |
-| **Time**          | The time the event occurred.                         |<!--note from editor: Suggested.-->
+| **Time**          | The time the event occurred.                         |
 | **Category**      | The type of event, such as *Network*.          |
 | **Operation**     | The resulting internal operation name of the request inside the app. For example, *createRow* is the operation name from the **Patch** function.          |
 | **Result**        | The text description of the status code. For example, a 429 status will appear as an *"Error"* in the result column. Row colors also help to identify any errors and warnings quickly.          |