Identifying WFTimer Records in the Schedule [sys_trigger] table with no Workflow ContextDescriptionIn customer support, we have encountered scenarios where a customer has reported a large number of WFTimer records within the Schedule [sys_trigger] table.Release or EnvironmentIn customer support, we have encountered scenarios where a customer has reported a large number of WFTimer records within the Schedule [sys_trigger] table.CausePotential Cause There are two potential scenarios where this issue can occur. Note: The number of scenarios can vary due to the nature of the customer’s implementation on the instance and the build that their instance is reported on. Do not assume that the root causes below are the actual root cause for a customer issue. A full investigation is required before determining the root cause. The guidelines below are available to assist customer support. Potential Root Cause 1: A user may have created a script within their workflow to delete the Workflow Context [wf_context] record only, leaving orphaned WFTimer records in the Schedule [sys_trigger] table. Potential Root Cause 2: A user may have removed the Context reference field value from a Workflow Executing Activities [wf_executing] table. This can be done via the list view or the form itself if a user has the admin or workflow_admin role. Assistance identifying orphaned WFTimer jobs without a workflow contextResolutionIn the Schedule [sys_trigger] table, there is a field called document_key. The document_key field contains a sys_id, which is linked to a record in any table where the Schedule [sys_trigger] is being triggered. In this scenario, the expected analysis would be that the document_key within the WFTimer records on the Schedule [sys_trigger] table would contain a sys_id of the Workflow Executing Activities [wf_executing] table. This can be found by following the steps below: Log into any instance as an admin or maint user.Navigate to System Scheduler > Scheduled Jobs.Open any WFTimer records within this table.A WFTimer record appears if there was a running workflow containing the activity definition Timer or SLA Percentage Timer.Copy the document_key field value from a WFTimer record within the Schedule [sys_trigger] table.On the Application, navigate to Workflow > Live Workflows > Executing Activities (this leads to the wf_executing table).On the search navigation bar, select sys_id on the right of the Go To bar and paste the document_key within the field.Press Enter on your keyboard and only one result should appear within the Workflow Executing Activities [wf_executing] table.Open the record.You should see a field called Context, that is a reference field to the Workflow Context [wf_context] table where the triggered workflows are stored. Example 1 - workflow executing activity [wf_executing] record Actual behavior: In some customer scenarios, we have seen that although there is an Executing Activity that matches the document_key from the Schedule [sys_trigger] table, the Context reference field is empty. This is an issue because if there are workflow activities that are in running state with no reference to a context, then the activity continues to run because there is no workflow to continue the flow to the next activity. Example 2 - workflow executing list records with no workflow In order to identify the orphaned WFTimer Jobs without a Workflow Context associated, run the query below. CAUTION: Due to the nature of the query, perform the query on a sub-production instance first. Due to the amount of tables being referenced, it is expected to become a long running query depending on the data within those tables. Therefore, before running the query, take into account the number of records within the following tables: Workflow Context [wf_context]Workflow Executing Activities [wf_executing]Schedule [sys_trigger] If there is a huge amount of data contained within the tables, do not use the query. The query has been tested on a demonstration instance only and therefore it is not guaranteed to work as expected on customer instances with a huge amount of data stored within the tables listed above. Use the query at your OWN risk: Query: SELECT e.sys_id from wf_executing e left join wf_context c on e.context = c.sys_id inner join sys_trigger t on e.sys_id = t.document_key where c.sys_id is null;