> ## Documentation Index
> Fetch the complete documentation index at: https://docs.m3ter.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Testing and Troubleshooting Workflows
The Workflow Builder offers several useful options designed to support and facilitate both troubleshooting published Workflows and testing Draft versions before publishing.
This topic explains how to work with these options:
* [Reviewing Workflow Runs](#reviewing-workflow-runs)
* [Enabling Traffic-Forwarding](#enabling-traffic-forwarding)
* [Replaying Workflow Runs](#replaying-workflow-runs)
## Reviewing Workflow Runs
Workflow runs are logged by date and time and listed in the m3ter Console. You can view the runs performed for a m3sh Workflow or open individual Workflow runs and drill in to review run log details:
* [Viewing Workflow Runs](#viewing-workflow-runs)
* [Reviewing Workflow Run Logs](#reviewing-workflow-run-logs)
### Viewing Workflow Runs
**To view m3sh Workflow runs:**
1. Select **m3sh**:
* The **Workflows** page opens.
2. Select the **Name** hotlink text of the Workflow you want to view runs for. The Workflow opens in **Draft** mode.
3. Scroll down to the to the **Latest workflow runs** panel:
* Workflow runs are designated and tracked using the UTC date/time when the run started. The **Latest workflow runs** panel lists the ten most recent runs in descending order of start date/time, and for each run listed you can:
* Read off the **Start time**, **Trigger**, and **Status**.
* You can select the **Start time** hotlink text to open the details page for an individual run - see the following [Reviewing Workflow Run Logs](#reviewing-workflow-run-logs) section.
* Filter the list by **Status**, for example to show only **ERROR** runs:
4. Select **View all**. The **Runs** page for the Workflow opens:
**Tip: Accessing Workflow runs?** Depending on the Workflow set up, there can be other ways to access and review Workflow runs:
* If a Workflow uses a Notification rule as its trigger, you'll be able to open runs from the **Notification rule details** page.
* If a Workflow is associated with another m3ter entity - such as a Bill or an Account - then you'll be able to access runs from the entity details page - such as **Bill details**. The metadata card for an entity will also show hotlink texts you can use to open runs.
### Reviewing Workflow Run Logs
You can quickly open an individual Workflow run and review detailed run logs on a step-by-step basis. This is useful when troubleshooting Workflow runs that have failed to complete and show an error.
**To review individual m3sh Workflow run logs:**
1. Select **m3sh**:
* The **Workflows** page opens.
2. Select the **Name** hotlink text of the Workflow you want to review run logs for. The Workflow opens in **Draft** mode.
3. Scroll down to the to the **Latest workflow runs** panel:
* If the Workflow run you want to review run logs for is listed, select the **Start time** hotlink text of the run. The **Workflow** **Runs** page opens.
* If the Workflow run you want to review run logs for is not listed, select **View all**. The **Runs** page opens listing all Workflow runs. Select the **Start time** hotlink text of the run you want to open and review. The **Workflow** **Runs** page opens:
* The **Start time** and **Status** of the run are shown.
* You can use the controls to zoom in/out or fit to view.
* In this example, we've opened a Workflow run that is showing as in **ERROR** and a **Message** is provided to help debugging.
4. If you want to inspect the log details for a specific step, select the details icon for the step. For example, for the Workflow **Start**:
* The log details for the selected step that was performed in the Workflow run are loaded into the right-hand side of the **Run log**.
* In this example, the JSON returned for the `billing.balanceamount.updated` Event that triggered the Workflow run is loaded.
5. Similarly, you can review the log details for a functional step performed in the Workflow run:
* In this case, the **HTTP REQUEST** performed by a **m3ter API** function is shown and you can expand the call to inspect the **Request** and **Response** JSON.
6. To identify and resolve the error with this example run, if we check through the remaining Workflow steps, we find that the final **Create AccountPlan** m3ter API function is showing an error flag and are told that no logs are available:
7. If we now open the **Function details** for this step, we see that it is configured to use `oldAccountPlan` for **Request Path**:
8. When we open the previous function the error is confirmed as a configuration mismatch, since this previous function has stored the Account to be created under `newAccountPlan` in the Workflow state:
* In an attempt to resolve the error, in the Draft version we can edit the **Create AccountPlan** function and update it to use `newAccountPlan` for **Request Path**.
* To test this fix and before publishing it to the Workflow, we can *enable traffic-forwarding* to the Draft version and check the next run - see the [following section](#enabling-traffic-forwarding) for details.
## Enabling Traffic-Forwarding
You can enable *traffic-forwarding* to the Draft version of a Workflow. This will temporarily switch traffic so that the Draft version of the Workflow will be triggered and run instead of the Published version allowing you to test any Draft updates. The traffic-forwarding option is very useful when you've deployed a Published Workflow to production and:
* You're in the process of updating a Draft version of the Workflow to add more functionality for a planned new version of the Workflow. As you do this, you can test your updates incrementally and before publishing.
* An error has occurred when the Workflow runs. After investigation, you've identified a possible cause for the run error and performed a fix in the Draft version. Before you publish the Draft, you can test the fix.
**To enable traffic-forwarding for m3sh Workflow runs:**
1. Select **m3sh**:
* The **Workflows** page opens.
2. Select the **Name** hotlink text of the Workflow you want to enable traffic-forwarding for. The Workflow opens in **Draft** mode and the default setting of **Traffic: Published version** is shown:
* In this example, we've opened a Workflow that showed a run error for the currently Published version. In the previous [Reviewing Workflow Run Logs](#reviewing-workflow-run-logs) section, this error was investigated and identified as a mistaken **Request Path** setting in the final m3ter API **Create AccountPlan** function. An attempted fix has been made to the final function in the Draft version:
* The **Request Path** update in the Draft has been saved but not yet pushed through to the Published version:
* We can now enable traffic-forwarding and test the attempted fix in the Draft version
3. On the drop-down menu select **Enable traffic-forwarding**:
* A confirmation dialog shows:
4. Select **Enable traffic-forwarding** to confirm the traffic switch. The Workflow's traffic flag updates:
* When the Workflow is next triggered, it will run for the Draft version.
5. You can wait until the relevant Event Notification or Incoming Webhook next triggers the Workflow and then check the **Latest workflows runs** to see if the Draft Workflow has completed successfully:
* For the current example, we can see that an Event Notification has triggered the latest run for the Draft version and the run has completed without error. When we open the run to check logs the error showing for the final function is now fixed:
6. Return to the Workflow Draft and **Publish draft**. When you do this, traffic will be automatically switched back to **Traffic: Published version** default.
**Important!** When you publish a Workflow Draft version, the Draft is permanently deleted. If you've been using the traffic-forwarding feature to perform test runs of a Workflow using the Draft version before publishing, this means any Draft runs will no longer be available.
## Replaying Workflow Runs
You can replay a Workflow run using the same Event Notification or Incoming Webhook trigger responsible for the original run. Replay runs are clearly identified and this capability is especially useful when testing new Workflow designs or troubleshooting failures in existing Workflows without having to re-trigger runs from external systems.
**To replay m3sh Workflow runs:**
1. Select **m3sh**:
* The **Workflows** page opens.
2. Select the **Name** hotlink text of the Workflow you want to view replay runs for. The Workflow opens in **Draft** mode.
3. To open the Workflow run you want to replay, on the **Latest workflow runs** panel either:
* Locate the run and open it.
* Select **View all** to open the **Runs** page for the Workflow, locate the run, and open it.
* In this example of an Event Notification Workflow, we've opened a run that is in error. By reviewing the run logs and the error message provided, we've identified an error with the **Request Path** defined for an **Create AccountPlan** function used for the final step of the Workflow.
5. In an attempt to fix this error, we can open the **Draft** and update the **Create AccountPlan** function to change the **Request path** setting and then **Publish draft**. The Published version of the Workflow now has what we believe to be the required fix:
6. We can now go back to the original Workflow run page and select **Replay run**. A confirmation dialog opens:
7. Select **Replay run** to confirm. The run is replayed using the original run's trigger payload and a message shows to confirm success.
8. If we return to the Workflow's **Latest workflows runs** panel, we can see the run which is clearly marked as a **REPLAYED** run:
9. If we now open the replayed run, we can see that our fix worked and the Workflow run completed without error:
* Note that a link is provided to **View original run** if you need to perform further comparison for checking and debugging.