Bookshelf v8.0: Applets Used to Define a Workflow Policy

This topic provides information about the views and applets used to define a workflow policy group. It includes the following topics:

About the Policies List Applet

Table 43. Description of Fields in the Policies List Applet
Field	Usage	Explanation
Policy Name	Define the name of the workflow policy.	(This cell is intentionally empty.)
Workflow Object	Define the workflow policy object for which the policy was created.	For example, Service Request, Activity, or Accounts. This field is required.
Group	Define the workflow policy group to which the policy belongs.	Each policy must be assigned to a workflow policy group. For more information, see Moving a Workflow Policy to a Different Group.
Comments	Define comments about the purpose or use of the policy.	(This cell is intentionally empty.)
Activation Date/Time	Define the date and time that the policy was or will be activated.	If this field is null, the policy is activated immediately.
Expiration Date/Time	Define the date and time that the policy expires.	If this field is null, the policy is active indefinitely.
Duration	Define the duration fields in days, hours, or minutes that the conditions must be true for the workflow policy to be executed.	This field is ignored if the policy is run in batch.
Created By	Define the login name of the person who created the workflow policy.	The information in this field is automatically filled. This field is read only.
Created On	Define the date and time the workflow policy was created.	The information in this field is supplied for you. This field is read only.
Quantity	Define the number of records that meet the policy conditions before the policy action executes.	If you do not specify a quantity, Siebel Workflow assumes a quantity of 1. Quantity allows policy administrators to create conditions that are based on a number of records that meet the policy conditions. For example, an administrator can create a workflow policy that sends a broadcast message when 20 or more critical service requests are open.
Batch	Specify, by checking Batch, that this policy evaluates records that potentially meet the conditions of the policy.	The Workflow Monitor Agent scans records using the conditions of the policy to find the matches. When this field is checked, run Workflow Monitor Agent with the Batch Mode flag set to TRUE. The default is unchecked.

About the Conditions Applet

Table 44 describes fields in the Conditions applet of the Workflow Policies view.

Table 44. Description of Fields in the Workflow Policy Conditions Applet
Field	Required	Usage	Example
Field	Yes	Define the workflow policy component column in the workflow policy object on which the workflow policy condition is based.	To specify the service request priority or service request open date, choose the workflow policy column instance from the picklist for the field.
Comparison	Yes	Define the comparison to make between a workflow policy agent's column value and the value you specify.	For example, equals (=) or greater than (>). Choose the comparison from the picklist for the field. For more information, see About Logical Operators in the Conditions Applet.
Value	Yes, except when the Comparison field has a value of Is Null, Is Not Null, Is Updated, Is Deleted, or Is Added.	Define the value to compare to the workflow policy column value instance.	For example, not started or very high. For more information, see About Logical Operators in the Conditions Applet, and Entering Date Calculations in the Conditions Applet.

NOTE: For a Workflow Policy to be triggered which has a Condition Field <> [Value n], there must be a value specified in this field other than that specified in the Workflow Policy condition. If there is no value, the workflow policy is not triggered. The Operator IS NULL is used in this case.

About Logical Operators in the Conditions Applet

You use comparison values in the Operation field. The field exposes the Workflow policy component column for monitoring.

Standard Comparisons in the Conditions Applet

The Comparison field supports greater than (<), less than (>), not equal to (<>), greater than or equal to (>=), less than or equal to (<=), equal (=), LIKE, IN, NOT IN, BETWEEN, IS NULL, and IS NOT NULL operators.

Table 45. Description of Comparisons for a Typical Database
Comparison	Value
<	5
>	5
<>	5
>=	5
<=	5
=	A
LIKE	Abc%
IN	(1, 2, 3)
NOT IN	('A', 'B', 'C')
BETWEEN	1 and 2
BETWEEN	'A' and 'B'

Specialized Comparisons That Must Be Used With Batch Workflows

The Comparison field supports the specialized operators IS ADDED, IS UPDATED, and IS DELETED. The IS operators serve as a starting point for the examination of the workflow policy.

When creating a batch type workflow policy, the comparison operators IS ADDED, IS UPDATED, or IS DELETED must be used in conjunction with regular conditions. These comparison operators are considered special conditions intended for Dynamic mode when triggering rows to look up regular conditions.

Comparisons that work at the workflow policy component level, but do not operate at the field level, include:

Table 46 describes specialized comparisons for database platforms that can be used in creating a workflow condition.

Table 46. Description of Specialized Comparisons
Comparison	Value	Explanation
IS ADDED	Use IS ADDED with a workflow policy component column specified in the Condition field and nothing specified in the Condition value.	The condition is met when an instance of the workflow policy component is added. For example, if the Service Request policy component column is defined in the Condition field and IS ADDED is defined in the comparison, the condition is met when you create a new service request.
IS UPDATED	Use IS UPDATED with a field specified in the Condition field and nothing specified in the Condition value. The condition is met when the field changes.	For example, if service request status is defined in the Condition field and IS UPDATED is defined in the comparison, the condition is met when the Service Request status changes. For more information, see Using IS UPDATED in the Conditions Applet.
IS DELETED	Use IS DELETED when you specify a child workflow policy component in the Condition field, and nothing is specified in the Condition value.	A child workflow policy component is a workflow policy component that is associated with a parent workflow policy component in Siebel. For example, a parent workflow policy component might be Service Request. A child workflow policy component might be Service Request Activity. If IS DELETED is used in conjunction with other conditions, the other conditions must be based on the parent workflow policy component. For more information, see Using IS DELETED in the Conditions Applet.

Note that an OR is implied between specialized comparisons, where one or more of the conditions must be met before the action occurs. For example, you can have a service representative receive an email when an open service request has an activity added to it. Conditions in the policy that you then create include:

If a workflow policy condition is IS ADDED or IS UPDATED, then the triggers generated do not represent all the conditions specified in the policy. The triggers that are not represented are ignored. This condition can be viewed by examining the trigger.sql file that is produced as a result of the comparison. This is expected behavior. Note that if the workflow policy condition is modified then Gentrig must be run to implement the updated workflow conditions.

Note that when using a condition with a standard comparison, the condition is encompassed in the triggers that are created. However, when using a specialized comparison, since Workflow Monitor Agent evaluates the condition at runtime, triggers on the tables do not include the standard comparison conditions.

Using IS UPDATED in the Conditions Applet

Although Workflow policy conditions are joined when an IS UPDATED statement is present, the format of the trigger.sql statement that is generated for the workflow policy condition will not have AND within the SQL syntax.

When IS UPDATED is not present, the Workflow Monitor Agent only invokes the policy if conditions defined in the policy are violated. However, if an IS UPDATED comparison is included as criteria on a field, then other fields in the Policy conditions are not checked.

Using IS DELETED in the Conditions Applet

As an example, assume you must notify a service request owner if an activity is deleted from a service request that has a sub-status of In Process. Table 47 describes the configuration you use in this case.

NOTE: When using IS DELETED, the ROW_ID of the deleted record from the child workflow policy component is not tracked or logged into the S_ESCL_REQ table, nor can the Workflow Monitor Agent component determine which exact row being deleted caused the policy to trigger. If you must have Workflow capture the row being deleted, you must use a workflow process driven by a run-time event. The run-time event is the PreDeleteRecord event on the BusComp event object type.

Entering Date Calculations in the Conditions Applet

Workflow Monitor considers both date and time when evaluating Workflow Policy conditions that perform a date comparison. CURRENT can be used when entering a value for a date comparison. The format for using CURRENT is CURRENT [+/-] d:h:m where d is day, h is hours, and m is minutes. For example, CURRENT + 01:02:03 is the value in CURRENT plus one day, two hours, and three minutes.

You can use CURRENT in the comparison value for date fields. You can also use CURRENT when you specify the activation and expiration dates for a broadcast message action.

About the Actions Applet

Table 48. Description of Fields in the Actions Applet
Field	Usage
Action	Define the name of the action.
Sequence	Define the sequence of the action relative to other actions. This field is required.
Contact Last Name	Define the last name of a contact when the recipient of the action is a contact in the database.
Contact First Name	Define the first name of a contact when the recipient of the action is a contact in the database.
Employee Login	Define the login name of an employee when the recipient of the action is an employee.
Position	Define the position of an employee when the recipient of the action is a position.
Relative	Define the relative type when the recipient of the action is determined by the workflow object. For example, service request owner.
Consolidate Flag	Use this flag to consolidate the action to one instance if more than one record meets the conditions of the workflow policy during the same action interval. Default is FALSE. The consolidate flag is unavailable with actions that send pages.

Many of the properties in the Workflow Policies view are predefined in other Siebel Business Process Designer views by using the Siebel client or Siebel Tools. You can modify the predefined properties or define new values for these properties. The property values appear in picklists in the applets that constitute the Workflow Policies view.

Using an Insert Operation With a Workflow Policy Action

An insert operation with a Workflow Policy Action cannot populate the Primary Owner.

For example, you cannot modify the Workflow Policy Program, such as Create SR Activity, to populate Primary Activity Owner, OWNER_PER_ID, since the intersection table, S_ACT_EMP, must also be populated. Since the same Workflow Policy Program cannot update two tables within one database operation, Workflow Process must be used to populate OWNER_PER_ID. Earlier versions, such as Siebel version 6 can support this technique because Activity can have only one employee assigned. However, in later versions, such as Siebel version 7.x, Activity can be assigned to multiple employees.

About the Send to Position Recipient Type

The Send to Position recipient type allows you to send to the primary employee of this position without having to know the name of the person. The employee must be ACTIVE. The Send to Contact recipient type allows you to pick an available contact in the Siebel system.

Siebel Business Process Framework: Workflow Guide		Copyright © 2008, Oracle. All rights reserved.