Fixing Problems in the S_ESCL_REQ Table

If a database trigger runs on a Workflow Policy condition, then Siebel CRM inserts a record in the S_ESCL_REQ (escalation request) table. This table contains the rows that can cause a Workflow Policy to run. After the Workflow Monitor Agent processes a request, it removes the row from this table.

A database trigger does not include the logic that you define in a Workflow Policy condition. The conditions in the database trigger file might not be indicative of the Workflow Policies that are met. When Workflow Monitor Agent runs, the records in the S_ESCL_REQ table causes Siebel Workflow to evaluate the related Workflow Policy conditions. The database triggers exist only to trigger the Workflow Engine to examine the Workflow Policy conditions.

To fix problems in the S_ESCL_REQ table

• Use your database tools to monitor the size and efficiency of the table:

  • If the table is very large, then this situation indicates that Siebel CRM is monitoring too many Workflow Policies. To fix this problem, redefine the Workflow Policy Groups so that they share the load.

  • If Siebel CRM monitors rows but does not remove them after the time interval finishes, then this situation might indicate that you deactivated a Workflow Policy but did not remove the database triggers that are associated with this policy. The database triggers continue to send data that no Workflow Policy works on. To fix this problem, remove the database triggers that are associated with the deactivated Workflow Policy.

• If you create a new business component, then do not set the Table property to the S_ESCL_REQ table. A business component cannot reference the S_ESCL_REQ table.

• Expire, rather than delete a Workflow Policy. For more information, see Expiring a Workflow Policy.

• Remove rows that belong to obsolete Workflow Policies. For more information, see Deleting an Obsolete Workflow Policy.