Assuming that the Workflow is unchanged and that the Platform has not changed since the last successful Workflow run, consider that a Workflow is not a discrete entity but rather a potentially highly complex set of Activities that has the potential to touch upon nearly every aspect of the Platform.
While the Workflow may itself remain unchanged, any changes made to any entity which the Workflow interacts with has potential impact.
Below are a few potential causes to illustrate this:
- The volume of data with which one of the Workflow Activities is interacting has increased beyond documented Platform capacities. This may been the result of a gradual increase over time that has reached a critical point, or a recent and significant data injection
- A Report which the Workflow relies on is timing out. This may be an example of data growth as above, or that some aspect of the Report has changed since the last Workflow Run, or one of the Report calculations has been altered in a way that degrades performance.
- There was a change to the security rules that leads to Reports timing out, or blocking access to certain entities that was required for the Workflow to execute successfully. It may be happening across or users, or only a subset of users.
This is by no means an exhaustive list but serves as an example of the potential complexity behind the cause of a Workflow that had run successfully in the past, even for a long period of time, may suddenly stop with no clear reason.
If this should happen, a good place to start is selecting the failed Workflow Run record in the Workflow Runs report and select Examine - please refer to Examining Workflow Runs for more detail.
Below is a Sample Cast Study to demonstrate how an investigation of a failing Workflow could be undertaken, and primarily serves as a guideline as to how Tenant Administrators might perform such troubleshooting.
Sample Case Study
There was a Workflow called Set Gap which had been running without an issue when it suddenly started to fail. It had been verified that the Workflow has not changed since the last successful run.
The Tenant Administrator opens the Workflow Run report by navigating to Administration > Workflows > Workflow Runs and locates the record for the failed run, and selects Examine from the Context Menu.
Examine the failed Workflow Run
This opens the Examine Workflow Run page. The Tenant Administrator toggles on Steps Taken to see at which Workflow Activity the run had reached when it failed.
Steps Taken in the Examine Workflow Run page
The Tenant Administrator scrolls down to see what the last step was and sees that it reached Step 8 - Get Business. He/she then navigates to Administration > Workflows > Workflows, locates the Workflow Set Gap and opens it in the Workflow Editor by double clicking.
The problematic Workflow
The Tenant Administrator locates the last Workflow Activity registered in the Steps Taken tab of the Examine Workflow Runs page, above and inspects what this activity is doing.
Inspecting the problematic Activity
The Tenant Administrator sees that this Activity is running the Report Employees against the Object Employee with filters. He/she navigates to Administration > Resources > Reports to load the Report and apply the same filters - which it does successfully.
The Tenant Administrator navigates back to Administration > Workflows > Workflow Runs and locates the record for the failed Workflow Run and checks who the Triggering User was.
Identifying the Triggering User
Using Report Diagnostics, the Tenant Administrator attempts to run the Report as that user and this time the Report times out.
Run Timed as specified user via Report Diagnostics
At this point it has become clear that the Workflow itself does not have a problem, but this Report with which the Workflow is using is has an issue, specifically when being run as the user 'Joseph'.
The Tenant Administrator then runs Show Diagnostics and attempts to identify the root cause.
Refer to Report Diagnostics documentation for further information on how to interpret Diagnostics.