Bookshelf Home | Contents | Index | Search | PDF

Siebel Business Process Designer Administration Guide > Testing Workflow Policies >

Troubleshooting

---

Because workflow policies are based on database triggers, a workflow policy can take effect on a database record only after the record is committed. If you have a policy that is based on multiple database tables, the policy takes effect only if the records on all tables are committed. For example, Opportunity Revenue is stored in the S_OPTY_POSTN table, and lead quality is stored in the S_OPTY table. A policy with conditions Opportunity Revenue > 10M and Lead Quality = high takes effect only when the records are committed on both tables.

Also keep in mind that multiple business components can be created for the same database table using search specifications. If you are creating a workflow policy component to monitor a business component, be sure to include all the fields that are being used in search specifications as workflow policy columns. The workflow policy column can then be used in the policy conditions to allow appropriate behavior to be enforced.

If your workflow policy action does not occur, check the following:

Verify that your test record meets ALL your workflow policy conditions.
Verify that the client configuration file is pointing to the correct enterprise server (one error that can occur if the server is incorrect is ESC-00053, "Error loading rule definitions").
Check the workflow policy activation date/time.
Check the monitor task:
Is the monitor awake and running against the correct group?
Search the Task Information log for the Row_Id of your test record.
If Row_Id does not exist, run GENERATE TRIGGERS.
Update your test record.
Check the Action Agent task:
Is Action Agent awake and running against the correct workflow policy group?
Search the Task Information log for the Row_Id of the test record.
Make sure your triggers are generated.

Bookshelf Home | Contents | Index | Search | PDF