Understanding Siebel Workflow Policies with Duration Parameter Set

Siebel Workflow Policies are a powerful mechanism used in Siebel CRM to automate business processes based on specific conditions met by records. A Workflow Policy can monitor changes in Siebel database records and trigger actions when these conditions are met.

When a Workflow Policy is defined with a Duration parameter, it means that the policy will be triggered not immediately upon the condition being met, but after a specified time has passed. This introduces an important concept of time-based processing in Siebel workflows.

In this blog, we will explore how Siebel handles records associated with a Workflow Policy that has a duration parameter set, and how records are processed through various Siebel tables.

---

Key Components of a Workflow Policy with Duration

When a Workflow Policy has a duration parameter set, Siebel uses several tables to track and process records over time. Here are the primary tables involved:

1. S_ESCL_REQ (Workflow Policy Request Table)
   • This table stores records that are being monitored by the workflow policies. When a policy condition is met, a record is inserted into this table with the relevant details.
2. S_ESCL_STATE (Workflow Policy State Table)
   • This table tracks the current state of a record in relation to the policy, including details such as when the condition was met and when the duration expires.
3. S_ESCL_LOG (Workflow Policy Log Table)
   • This table logs all actions taken by workflow policies, providing a historical record of events and actions triggered by the policies.

Scenario: Workflow Policy with Duration

Let’s say you have a Workflow Policy that is triggered when a service request remains in an “Open” status for more than 48 hours. This is a typical use case for the duration parameter: the condition is not just based on the status change but also requires the record to remain in the same state for a specific period.

Key Fields:

• Condition: The Status field of the Service Request is “Open.”
• Duration: 48 hours (2 days).

---

How Records Are Processed

1. Initial Condition Met
   • When a Service Request is created or updated, and the status becomes “Open,” Siebel evaluates the Workflow Policy conditions. Since the status is “Open,” Siebel inserts a record into the S_ESCL_REQ table. This entry indicates that the condition has been met, but the action won’t be triggered yet because of the duration parameter.
2. Waiting for Duration to Expire
   • In the S_ESCL_STATE table, Siebel records the start time when the condition was first met and when the duration will expire (i.e., 48 hours later). This entry helps the system track how long the condition has been met.
   • In this example, the EXPIRY_DT field would be set to 48 hours from the time the condition was met. The system will continuously monitor the record and check whether the condition remains valid for the specified duration.
3. Duration Met
   • After 48 hours have passed, Siebel checks whether the condition is still valid. If the Service Request is still in “Open” status, the workflow policy action is triggered. This could involve sending a notification, creating an escalation task, or another automated action.
   • At this point, the record is updated in the S_ESCL_REQ table to mark the action as completed, and an entry is made in the S_ESCL_LOG table to document that the workflow policy was triggered.
4. Condition Change Before Duration
   • If the condition changes before the 48 hours are up, for example, if the Service Request status changes to “Closed” within 24 hours, the policy is invalidated. Siebel will remove or update the corresponding entry in the S_ESCL_REQ and S_ESCL_STATE tables, and the workflow policy will not be triggered.

Workflow Policy Job Execution

Behind the scenes, a batch job known as the Workflow Monitor Agent periodically evaluates the records in the S_ESCL_REQ and S_ESCL_STATE tables. The agent checks whether the conditions are still met and whether the duration has expired. If both conditions are satisfied, the corresponding action defined in the workflow policy is triggered.

This process ensures that the system doesn’t immediately act on condition changes but instead waits for the specified duration to elapse before executing the action.

---

Best Practices for Using Duration in Workflow Policies

• Optimize Duration-Based Policies: Workflow policies with durations can add overhead to the system, as records must be continuously monitored over time. It’s important to ensure that policies are optimized and only include necessary conditions.
• Monitor Workflow Policy Tables: Regularly monitor the S_ESCL_REQ and S_ESCL_STATE tables to ensure there are no stale or invalid records. This helps prevent unnecessary processing and keeps the system efficient.
• Test with Realistic Data: Before deploying a duration-based workflow policy in production, test it with realistic data in a staging environment. Ensure that the policies trigger actions at the right time and handle changes in conditions properly.

---

Siebel Workflow Policies with a duration parameter offer a flexible way to automate business processes based on both conditions and time. By carefully designing policies and understanding how records are processed in the S_ESCL_REQ, S_ESCL_STATE, and S_ESCL_LOG tables, you can ensure that your Siebel CRM system efficiently handles time-based actions and escalations.

With proper monitoring and optimization, these policies can be a powerful tool for enforcing SLAs, automating follow-ups, and enhancing overall business process management.