12.4 Troubleshooting Automations, Run History & Analytics

Troubleshooting Automations, Run History & Analytics

Designing and deploying automations is only half the responsibility of a Power Platform Functional Consultant. In production environments, automations encounter intermittent service outages, data schema mismatches, API rate limits, and concurrency conflicts. To ensure business continuity and meet enterprise service-level agreements (SLAs), consultants must master the diagnostic toolset across Power Automate Run History, Power Platform Admin Center (PPAC) Analytics, Dataverse System Jobs, and Plug-in Trace Logs.

---

1. Cloud Flow Run History & Action Inspection

Whenever an automated, instant, or scheduled cloud flow executes, Power Automate captures detailed execution metadata in the flow's Run History.

+-----------------------------------------------------------------------------------+
|                         CLOUD FLOW RUN HISTORY VIEWER                             |
|                                                                                   |
|  [RUN HISTORY RETENTION: EXACTLY 28 DAYS]                                         |
|                                                                                   |
|  Start Time          Duration   Status     Trigger Outputs                        |
|  2026-08-17 10:14    1.2s       Succeeded  { id: "acc-101", name: "Contoso" }     |
|  2026-08-17 10:12    0.8s       Failed     { id: "acc-102", name: "Fabrikam" }    |
|  2026-08-17 09:55    --         Running    { id: "acc-103", name: "Litware" }     |
|                                                                                   |
|  +-----------------------------------------------------------------------------+  |
|  | CLICKING A RUN OPENS THE STEP-BY-STEP DIAGNOSTIC VIEWER:                   |  |
|  |                                                                             |  |
|  | [✓] When a row is added (Dataverse Trigger) ..................... 120ms     |  |
|  | [✓] Get Customer Profile (Dataverse Action) ..................... 240ms     |  |
|  | [✕] Post Invoice to SAP (HTTP REST Action) ...................... 450ms     |  |
|  |     * Status Code: 400 Bad Request                                          |  |
|  |     * Inputs: { "TaxID": null, "Amount": 4500.00 }                          |  |
|  |     * Error Message: "TaxID is a required field for EU customers."         |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+

Key Run History Diagnostics

• 28-Day Retention Limit: Run history logs are retained for 28 days. After 28 days, execution history is purged automatically by the platform.
• Status Identifiers:
  • Succeeded: All executed actions completed successfully.
  • Failed: At least one action encountered an unhandled error, terminating the flow run.
  • Running: The flow is actively processing actions (or waiting on an Approval / Delay step).
  • Timed Out: An action or flow exceeded its maximum execution window (e.g., an approval waiting >30 days).
  • Cancelled: The flow run was aborted manually by a maker or administrator.
• Raw Inputs & Outputs Inspection: Clicking any individual action reveals the exact JSON payloads sent to and received from the underlying API. Makers can inspect HTTP status codes (e.g., 400 Bad Request, 401 Unauthorized, 404 Not Found, 429 Too Many Requests, 502 Bad Gateway) to diagnose integration faults.
• Apply to Each Iteration Debugging: When errors occur inside a loop, the run viewer displays navigation arrows allowing consultants to page directly to the specific iteration number that failed.

---

2. Resubmission & Flow Testing Strategies

When a cloud flow fails due to a temporary downstream service interruption or an expression bug, consultants have powerful tools to correct and reprocess transactions without impacting end users.

+-----------------------------------------------------------------------------+
|                        FLOW RESUBMISSION & TESTING                          |
|                                                                             |
|   [RESUBMIT FAILED RUN]                                                     |
|   - Takes the exact historical trigger payload from the failed run.         |
|   - Re-executes the flow without requiring the user to re-trigger the event.|
|                                                                             |
|   [EDIT AND RESUBMIT PATTERN]                                               |
|   1. Identify bug in failed run (e.g., faulty expression).                   |
|   2. Edit the Cloud Flow in the designer and Save updates.                  |
|   3. Return to Run History > Select Failed Run > Click 'Resubmit'.          |
|   4. The new flow version executes using the original failed data!          |
|                                                                             |
|   [TESTING: WITH RECENTLY USED TRIGGER]                                     |
|   - Allows makers to test flow logic during development by replaying        |
|     prior trigger payloads without creating dummy records in production.    |
+-----------------------------------------------------------------------------+

Resubmitting Failed Runs

• Original Payload Replay: Selecting Resubmit on a failed run immediately creates a brand-new run instance using the identical trigger body captured during the original event.
• Fix-and-Resubmit Workflow: If a flow failed due to a missing action or an expression error, the maker can edit the flow definition, save the changes, and then resubmit the failed run. The newly saved logic will process the original payload.

Testing Modes in Flow Designer

When testing a flow, makers choose between two modes:

1. Manually: The flow enters a listening state. The maker must perform the real-world trigger action (e.g., creating a row in Dataverse or uploading a SharePoint file) to start the test.
2. Automatically (With a recently used trigger): The designer displays a list of recent trigger payloads from previous runs. The maker selects a prior execution to instantly test the flow without creating test data or waiting for external events.

---

3. Power Platform Admin Center (PPAC) Analytics

While Run History provides tactical debugging for individual flows, the Power Platform Admin Center (PPAC) provides strategic, tenant-wide operational analytics.

+-----------------------------------------------------------------------------------+
|                         PPAC AUTOMATION ANALYTICS ENGINE                          |
|                                                                                   |
|  [DASHBOARDS]                                                                     |
|  - Usage: Total runs, active flows, daily/weekly execution trends                |
|  - Errors: Failure rates, error breakdown by connector type, top 10 failing flows |
|  - Maker Activity: Flow creation distribution, departmental adoption             |
|                                                                                   |
|  [CAPACITY & THROTTLING MONITORING]                                               |
|  - Power Platform Request Limits (API calls per 24-hour rolling window)           |
|  - Connector Throttling Alerts (Detecting 429 Too Many Requests)                  |
|                                                                                   |
|  [ORPHANED FLOW GOVERNANCE]                                                       |
|  - Identifies flows owned by disabled/departed Microsoft Entra users              |
|  - Allows administrators to assign new co-owners or service principals            |
+-----------------------------------------------------------------------------------+

Core PPAC Analytics Views

• Usage Dashboard: Displays aggregated execution counts, daily active flows, and run metrics across environments.
• Error Analytics: Highlights the Top 10 failing flows in the environment and categorizes errors by connector and error type, enabling administrators to identify problematic integrations proactively.
• Power Platform Request (API) Consumption: Tracks daily API call volumes against tenant licensing limits, identifying flows causing performance degradation or triggering connector throttling.

---

4. Dataverse System Jobs (asyncoperation) & Plug-in Trace Logs

For automations executing natively inside Dataverse—including Classic Background Workflows, Bulk Delete tasks, Rollup Column calculations, and Server-Side Plug-ins—monitoring is managed through specialized Dataverse system tables.

+-----------------------------------------------------------------------------+
|                        DATAVERSE SYSTEM MONITORING                          |
|                                                                             |
|   [SYSTEM JOBS (asyncoperation)]        [PLUG-IN TRACE LOG (plugintracelog)]|
|   - Tracks Background Workflows         - Captures Low-Code & C# Plug-in    |
|   - Tracks Bulk Deletions & Imports       execution exceptions              |
|   - Tracks Rollup / Calc recalculations - Tracing Settings:                 |
|   - States: Ready, In Progress,           * Off (Disabled)                  |
|     Paused, Succeeded, Failed,            * Exception (Logs errors only)    |
|     Canceling, Canceled                   * All (Logs all runs - verbose)   |
+-----------------------------------------------------------------------------+

System Job States and Status Reasons

The asyncoperation table maintains the lifecycle state of all asynchronous jobs:

• Ready: The job is queued and waiting for an available worker thread in the AsyncService pool.
• In Progress: The job is actively executing.
• Pausing / Paused: The job was temporarily paused (e.g., waiting for a scheduled timer or wait condition).
• Succeeded: The background job completed without error.
• Failed: The job encountered a fatal error after exhausting all retry attempts.
• Canceled / Canceling: The job was terminated by an administrator.

Plug-in Trace Log Configuration

To diagnose faults in Low-Code Plug-ins or C# custom plug-ins, administrators configure the Plug-in and custom workflow activity tracing setting in PPAC (Settings > Custom code and extensions > Plug-in trace log):

• Off: No logs are recorded (Default production setting to optimize storage).
• Exception: Logs are created only when a plug-in throws an unhandled exception or Error() call. (Recommended for production environments).
• All: Logs every single execution, including execution time, input parameters, and trace messages. (Used temporarily in development and testing environments for deep diagnostics; must not be left active indefinitely in high-volume production due to database storage consumption).