siebel

Policy programs are like cheat codes. If a requirement permit asynchronous nature then policy program is gold. The key feature of policy program is it doesn't need compilation after changes and can be modified run time. Anybody good at SQL can toy around with the powers of policy program. Recently we were asked to implement email functionality for SR status update changes. As obesessed with PP, i thought of writing new policies for it instead of modiying existing workflows. Things were smooth, life was cool and eveything was deployed successfully. However to my horror emails were not getting triggered. Policy conditions were configured correctly as record was getting created in S_ESCL_REQ table on violation. Situation worsened when email was going via F9 functionality. After some debugging it was observed that Email Manager Task was not running because of which emails were not flowing out of the system. Email Manager component in conjuction with Communications Outbound Manager is t...

Statuary Warning: This is not for the old horses. My romantics with siebel goes on and so Siebel mysteries. Newbies better be careful while using "IS UPDATED" condition in the workflow policies. It can lead to undesirable/wrong results. Lets consider below problem statement. "Any service request which is not worked within 2 hours of assignment, i.e. Assigned status , should be escalated." The obvious solution which comes in mind is to configure workflow policy with duration and Owner Id update condition. Unfortunately it didn't work for me. The issue when using "IS UPDATED" criteria in combination with Workflow duration is that criteria is considered only at the time of the first update by the user. Until the configured policy duration has completed, all subsequent updates to the record are discarded by Workflow Policy Manager. As a result at any point of time only one record is available in "S_ESCL_STATE" table for this policy. At the end ...