15Defining Custom Workflow Policies

Defining Custom Workflow Policies

This chapter describes how to define a custom workflow policy. It includes the following topics:

• Process of Planning a Workflow Policy

• Process of Defining a Workflow Policy

• Examples of Configuring Workflow Policies

• Customizing Workflow Policy Objects

• Defining Conditions for a Workflow Policy

Process of Planning a Workflow Policy

This topic describes how to plan a workflow policy. To plan a workflow policy, do the following tasks:

1. Creating a Plan for the Workflow Policy Group

2. Creating a Plan for the Workflow Policy

3. Identifying Objects That the Workflow Policy Monitors

4. Determining Requirements for the Workflow Policy

5. Creating a Plan for the Workflow Policy Action

6. Examining Predefined Workflow Policies

7. Creating a Plan for the Test and Migration Strategy

For more information, see Examples of Planning a Workflow Policy.

Before you plan a workflow policy, you must identify the solution that most closely meets your business requirements. For more information, see Identifying an Automation Solution.

Creating a Plan for the Workflow Policy Group

This task is a step in Process of Planning a Workflow Policy.

A workflow policy group is a collection of workflow policies that allows Siebel CRM to identify policies that include similar system requirements. It helps Siebel CRM to load balance work on the Siebel Servers and to achieve scalability. A workflow policy group allows you to run similar workflow policies as a group in one Workflow Agent process, which helps to manage and optimize performance of the Workflow Agent.

You must define a workflow policy group before you define a workflow policy. Siebel CRM assigns each Workflow Policy Agent to one workflow policy group. If you run only one Workflow Policy Monitor Agent and one Workflow Policy Action Agent, then you must assign your policies to one policy group.

It is recommended that you use multiple Workflow Policy Agents for the following reasons:

• Shorten the lag time between when Siebel CRM calls the workflow policy event and when Workflow Policies detects the event

• Spread the workload across multiple Siebel Servers

• Adjust the polling interval so that polling for a noncritical workflow policy does not prevent the timely processing of a critical workflow policy

Defining workflow policy groups and using multiple Workflow Policy Agents is part of tuning your system to realize higher performance. You can do this work while you monitor system performance.

The MaxInt parameter and the S_ESCL_RULE table determines the maximum number of workflow policies that a single workflow policy group can contain.

Grouping Workflow Policies That Include Similar Durations

It is recommended that you group together the workflow policies that include similar durations. This configuration allows you to assign the workflow policy group to a Workflow Policy Agent that includes a polling rate that matches the duration of the workflow policies in the group. This configuration results in a more efficient use of resources.

Creating a Plan for the Workflow Policy

This task is a step in Process of Planning a Workflow Policy.

Many of the workflow policy objects and workflow policy programs that your workflow policies require come predefined. You can use Siebel Tools to modify workflow policy programs, define more workflow policy objects, or to make more workflow policy columns available for monitoring. The planning phase is an appropriate time to review business process activities for your company. You must identify the work that a workflow policy can automate. For more information, see the following topics:

• Process of Defining a Workflow Policy.

• Customizing Workflow Policy Objects.

Developing Workflow Policies in Small Groups

It is recommended that you define and implement a small group of workflow policies at a time. After you successfully implement the group, you can proceed to another small group of policies in a systematic manner. If the business environment requires you to change your plan, then you can assign a workflow policy to a different group. For more information, see Moving a Workflow Policy to a Different Group.

Identifying Objects That the Workflow Policy Monitors

This task is a step in Process of Planning a Workflow Policy.

You can create a plan that identifies the objects to monitor. For example, assume the service department must send an email to the contact for the service request if a user creates a service request that includes a severity level of critical. The following table describes the information to monitor in this example.

What to Monitor	Purpose of the Policy
Service request status Service request severity	Send an email to the contact of a service request if a user creates a service request, and if the severity level for this service request is critical.

Determining Requirements for the Workflow Policy

This task is a step in Process of Planning a Workflow Policy.

To determine the requirements for the workflow policy and workflow policy conditions, you can identify the properties of the workflow policy and workflow policy conditions to modify, identify the workflow policy object to monitor in the Siebel database, and determine the duration for the monitoring interval.

Name	Workflow Policy Object	Workflow Policy Group	Duration
Email Confirmation of SR	Service Request	Medium Frequency This value creates the interval period for monitoring.	0 (zero) Duration indicates the time that must elapse before Siebel CRM performs an action. Each workflow policy includes one duration. If an action must occur after one hour, two hours, and six hours, then you must define a different policy for each duration.

Field in the Workflow Policy Condition	Operation	Value
Service Request Severity	=	1-Critical
Service Request Status	=	Open

A workflow policy condition includes an expression. The Condition Field identifies the table column that Siebel CRM monitors in the Siebel database. Siebel CRM reads the value for a workflow policy condition from a drop-down list that it defines at the table column level. The value that the operation requires for the condition that you define must be available in this drop-down list. IN and NOT IN are example values. If these values are not available, then the workflow policy cannot call the workflow policy action.

Creating a Plan for the Workflow Policy Action

This task is a step in Process of Planning a Workflow Policy.

If the workflow policy conditions are met, then Siebel CRM runs a workflow policy action. Workflow Policies come with a set of predefined actions. You can use these actions or define your own custom actions.

Action Name	Workflow Policy Program	Workflow Policy Object	Arguments
Send SR Email to Contact	Send SR Email	Service Request	Send to Contact

Examining Predefined Workflow Policies

This task is a step in Process of Planning a Workflow Policy.

Siebel CRM comes with predefined workflow policies and policy programs. It is recommended that you examine these predefined policies to determine if a policy already exists that meets your business requirements. If necessary, you can modify the predefined objects rather than defining new objects. For more information, see Types of Predefined Workflow Policy Programs and the topic about the Workflow Policy Object type in Siebel Object Types Reference.

Creating a Plan for the Test and Migration Strategy

This task is a step in Process of Planning a Workflow Policy.

You must make sure that any new workflow policy that you create works properly in a test environment. The test environment can include a sample Siebel database and test data. Testing a new workflow policy, workflow policy condition, and workflow policy action makes sure that the policy you release to the production environment runs correctly and does not cause a conflict with another workflow policy.

Guidelines for Creating a Plan for the Test and Migration Strategy

If you create a plan for the test and migration strategy, then it is recommended that you use the following guidelines:

• Make sure your test environment and production environment contain identical software versions.

• To make sure the test environment includes realistic data, you can use a partial or full copy of the production database.

• To test a new workflow policy in the production environment, you can manually enter a query that starts the new policy, and then examine the reply. This technique helps you determine if a workflow policy creates excessive notification or misses the rows that Siebel CRM must monitor. For more information, see Migrating Workflow Policies to the Production Environment.

Examples of Planning a Workflow Policy

This topic includes examples you can examine to help plan a workflow policy. It includes the following topics

• Planning a Workflow Policy That Sends a Discount Notice

• Planning a Workflow Policy That Notifies the User That Service Requests Require Attention

Planning a Workflow Policy That Sends a Discount Notice

In this example, if a sales representative quotes a discount that is greater than 30%, then Siebel CRM must notify the sales manager.

To plan a workflow policy that sends a discount notice

1. Identify the items to monitor.

   What to Monitor	Purpose of the Policy
   A quote that contains a discount that is greater than 30% requires Sales Manager approval.	Notify Sales Manager to review and approve the quote.

2. Plan the workflow policy action.

   Name	Workflow Policy Object	Workflow Policy Group	Duration	Quantity	Description
   Notify Sales Manager upon Sales Approval	Quote	Low Frequency	0	5	Notify the manager if a user creates a quote that includes a discount that is greater than 30%.

3. Plan the workflow policy conditions.

   Field (Column in the Siebel database)	Comparison	Value
   Quote Status	=	In Progress
   Quote Item Discount Percent	>	30

4. Plan the workflow policy actions that Siebel CRM runs if the workflow policy conditions are met.

   You can include dynamic values in the action arguments, such as the email subject and the message template.

   Action Name	Workflow Policy Program	Workflow Policy Object	Arguments and Substitutions
   Send Email to Sales Manager	Send Quote Email	Quote	Subject: Please approve quote discount for [Account] Message Template: Please approve the quote discount for quote [Quote Number] and notify [Last User First Name] [Last User Last Name] Repeating Message: The following quote also requires approval: [Quote Number]

Planning a Workflow Policy That Notifies the User That Service Requests Require Attention

In this example, if the number of open service requests for a service representative reaches 20, then Siebel CRM must send a notification.

To plan a workflow policy that notifies the user that service requests require attention

1. Identify the items to monitor.

   What to Monitor?	Purpose of the Policy
   Monitor open service requests when they reach a quantity of 20.	Use Send Broadcast Message to alert the service representative about the situation.

2. Plan the workflow policy action.

   Name	Workflow Policy Object	Workflow Policy Group	Quantity
   Over 20 Open Service Requests	Service Request	High Frequency	20

3. Plan the workflow policy conditions.

   Field (Column in the Siebel database)	Comparison	Value
   Service Request Status	=	Open

4. Plan the workflow policy actions that Siebel CRM runs if the workflow policy conditions are met.

   You can define the action arguments.

   Action Name	Workflow Policy Program	Workflow Policy Object	Arguments and Substitutions
   Alert Representative of Open SR	Send SR Message Broadcast	Service Request	Abstract: You own over 20 service requests Message Template: You own over 20 service requests. Please review the queue for your service requests.

Process of Defining a Workflow Policy

To define a workflow policy, do the following tasks:

1. Defining a Workflow Policy Group

2. Defining a Workflow Policy Action

3. Defining a Workflow Policy

For more information, see:

• About Workflow Policies

• Examples of Configuring Workflow Policies

• Customizing Workflow Policy Objects

• Types of Predefined Workflow Policy Programs

Defining a Workflow Policy Group

This task is a step in Process of Defining a Workflow Policy.

To define a workflow policy, you begin by defining a workflow policy group. For more information, see Creating a Plan for the Workflow Policy Group.

To define a workflow policy group

1. In the Siebel client, navigate to the Administration-Business Process screen, and then the Policy Groups view.

2. From the drop-down menu in the Policy Groups list, choose New Record.

3. In the Name field, define the name of the workflow policy group.

   A workflow policy can belong to only one policy group. The name can contain no more than 30 characters.

4. Optional. Enter comments in the Comments field.

   Define comments that describe the purpose or use of the policy group.

5. In the Policies list, click New, and then define fields using values from the following table.

   Field	Usage
   Name	Define the name of the workflow policy that is included in the workflow policy group.
   Object	Define the workflow policy object for which the workflow policy is defined. For example, Service Request, Opportunity, or Quote.
   Activation	Define the date and time that Siebel CRM must activate the workflow policy. If this field is null, then Siebel CRM activates the workflow policy immediately. For more information, see Grouping Workflow Policies That Include Similar Durations.
   Expiration	Define the date and time that the workflow policy expires. If this field is null, then the workflow policy is active indefinitely.
   Comments	Define comments that describe the purpose or use of the workflow policy.

6. Repeat the step 5 for each workflow policy you must include in the group.

   If at some point in the future you must reassign the workflow policy to another group, then see Moving a Workflow Policy to a Different Group.

Defining a Workflow Policy Action

This task is a step in Process of Defining a Workflow Policy.

You must define the workflow policy action before you define the workflow policy that uses the action.

To define a workflow policy action

1. In the Siebel client, navigate to the Administration-Business Process screen, and then the Actions view.

2. In the Actions list, click New Record from the applet level menu, and then define fields using values from the following table.

   Field	Description	Value
   Name	Define the name of the workflow policy action. Siebel CRM displays this name in the Actions Applet of the Workflow Policies view.	Enter a descriptive name that is consistent with your overall naming strategy and meaningful to the policy maker.
   Program	Define the workflow policy program that is associated with the action.	You choose this program from a drop-down list. For more information, see Types of Predefined Workflow Policy Programs.
   Workflow Object	Define the workflow policy object with which this action is associated. If you define a workflow policy object, then Siebel CRM displays this action only in the Actions Applet of the Workflow Policies view for workflow policies that are associated with this workflow policy object.	Chosen from a drop-down list of workflow policy objects.
   Comments	Define comments that describe the purpose or use of this workflow policy action.	Enter comments text.

3. In the Arguments list, define each argument, as necessary.

   The Arguments list changes depending on the Program you choose in the Actions list. For more information, see Using the Arguments List.

4. If you choose a program in the Actions list in step 2, then define a recipient in the Recipients list using values from the following table. You only use the Recipients list if you choose certain programs in the Actions list. For more information, see Using the Recipients List.

   Field	Description
   Type	The following choices are available: Send to Employee. Allows you to pick an employee. Send to Position. Allows you to pick a position, thereby sending to the primary employee of this position without having to know the name of the person. The employee must be ACTIVE. Send to Contact. Allows you to pick a contact. Send to Relative. For more information, see Using the Send to Relative Recipient Type. Send to Address. Allows you to manually enter an email address. This option supports a program that sends an email.
   Name	Define the Name of the recipient depending on the value you pick for the Type field. Siebel CRM sends the message according to the position. If you choose an employee as the recipient, and if the same position is assigned to multiple employees, then Siebel CRM sends the message to every employee who is assigned to this position even though you only choose one employee as the recipient.

5. Optional. Repeat step 2 to add additional recipients, as necessary.

Restrictions with Defining a Workflow Policy Action

This topic describes restrictions with defining a workflow policy action.

Calling a DLL or External Function

You cannot call a DLL or external function through a workflow policy action. You can use a workflow process to call a DLL or external function. You cannot call a business service from a workflow policy action.

Using an Insert Operation with a Workflow Policy Action

Starting with Siebel version 7.x, an insert operation in a workflow policy action cannot update the Primary Owner. For example, you cannot modify a Workflow Policy Program, such as Create SR Activity, to update Primary Activity Owner (OWNER_PER_ID) because Siebel CRM must also update the S_ACT_EMP intersection table. One Workflow Policy Program cannot update two tables in one database operation. To update OWNER_PER_ID, you must use a workflow process. Earlier versions, such as Siebel CRM version 6, can use an insert operation in a workflow policy action to update the Primary Owner because Siebel CRM can assign an Activity to only one employee in the earlier version.

Using the Arguments List

The Arguments list is context sensitive. Siebel CRM displays a different applet depending on the Program you choose in the Actions list. For example:

• If you choose Send Message Broadcast in the Program field of the Actions list, then it displays the Send Message Broadcast Arguments list.

• If you choose Send Email in the Program field of the Actions list, then it displays the Send Message Arguments form.

If you use the Arguments form, then note the following:

• A program argument is case-sensitive. You must use the correct case. It is recommended that you use the drop-down lists in the Arguments form when possible instead of entering the arguments manually.

• Before you configure Siebel CRM to use email or paging, you must do the setup procedures described in Administering Workflow Policies.

• If the workflow policy program is Send Email, Send Page, or Send Broadcast Message, then you must use the Recipient List to enter the recipients of the action.

For a description of each workflow policy program type, workflow policy program arguments, and valid values, see Types of Predefined Workflow Policy Programs.

How Siebel CRM Refreshes the Applets You Use

The applets that Siebel CRM displays in the Workflow Policies view change automatically depending on the program type you choose for the workflow policy action. This behavior is different from most views that you use in the Siebel client. For example, if you navigate to the Administration-Business Process screen, and then the Policies view, then Siebel CRM displays the following applets:

• Policies List

• Conditions

• Actions

• Arguments

If you choose Send Page to Opportunity Sales Rep in the Action field of the Actions list, then it replaces the Arguments list with the Send Page Arguments form.

Using the Recipients List

You use the Recipients list only if you choose Send Email, Send Page, or Send Message Broadcast in the Program field of the Actions list.

Using the Send to Relative Recipient Type

The Send to Relative recipient type sends an email or page to an individual or to the user who is assigned to the position that is associated with the current record, such as Primary Sales Rep or Primary Sales Rep Manager. The choices that are available are context sensitive. They depend on the Workflow Object you choose in the Actions list.

If you define a custom Send to recipient, then you can use one of the following recipient types in the Type field of the Recipients list:

• Send to Employee

• Send to Position

• Send to Contact

• Send to Relative

Email Manager does not send an email to the same recipient twice for the same action. If it detects that it already sent an email to a specific email address, then it does not send another message. If the Send to Relative type returns more than one recipient, then it sends an email to each recipient only if each email address is unique.

Sending an Email to Multiple Relative Recipients

You can define a workflow policy that sends the same email to multiple recipients.

To send an email to multiple relative recipients

1. Define an action for the policy program.

2. In the Recipients list, add a new record, set the Type field to Send to Relative, and then pick the name of the first recipient in the Name field.

3. Repeat the step 2 to add each additional recipient, updating the Name field for each recipient.

4. Associate the action with the workflow policy.

Defining a Workflow Policy

This task is a step in Process of Defining a Workflow Policy.

You use the Workflow Policies view to define a workflow policy. For more information, see Examples of Configuring a Workflow Policy.

To define a workflow policy

1. In the Siebel client, navigate to the Administration-Business Process screen, and then the Policies view.

2. In the list for the Policies List, choose New Record from the applet level menu, and then define fields using values from the following table.

   Field	Description	Explanation
   Name	Define the workflow policy name.	Not applicable
   Workflow Object	Define the workflow policy object for which the workflow policy is defined.	For example, choose Service Request, Activity, or Accounts. This field is required.
   Policy Group	Define the workflow policy group to which the workflow policy belongs.	You must assign each workflow policy to a workflow policy group. For more information, see Moving a Workflow Policy to a Different Group.
   Activation	Define the date and time when Siebel CRM must activate the workflow policy.	If this field is empty, then Siebel CRM activates the workflow policy immediately.
   Expiration	Define the date and time when Siebel CRM must expire the workflow policy.	If this field is empty, then the workflow policy remains active indefinitely.
   Duration	Define the duration fields in days, hours, or minutes that the workflow policy conditions must be true in order for Siebel CRM to run the workflow policy.	If the workflow policy runs in batch, then Siebel CRM ignores this field.
   Qty	Define the number of records that must meet the workflow policy conditions before Siebel CRM runs the workflow policy action.	If you do not define a value in the Qty field, then Siebel Workflow assumes a quantity of 1. Qty allows you to define a workflow policy condition according to the number of records that meet the condition determines. For example, you can define a policy that sends a broadcast message if 20 or more critical service requests are open.
   Batch Mode	If the Batch Mode field contains a check mark, then this workflow policy evaluates records that meet the workflow policy conditions.	The Workflow Monitor Agent uses the workflow policy conditions to identify records to process. If the Batch Mode field contains a check mark, then you must run the Workflow Monitor Agent with the Batch Mode field set to TRUE.

3. In the Conditions list, choose New Record from the applet level menu, and then define fields using values from the following table.

   Field	Usage	Example
   Condition Field	Define the workflow policy component column in the workflow policy object that the workflow policy condition references. Values that Siebel CRM displays in the Condition Field are context sensitive, depending on the value you choose for the Workflow Object. To allow Siebel CRM to call a workflow policy that contains a Condition Field that is not equal to [Value n], a value must be defined in this field that is different than the value that the workflow policy condition contains. If Condition Field contains no value, then Siebel CRM does not call the workflow policy and it uses the IS NULL operator.	Choose Service Request Area from the drop-down list.
   Operation	Define the comparison that Siebel CRM must make between the value of the column for a workflow policy agent and the value you define. Choose the comparison from the drop-down list for the field. For more information, see Examples of Configuring Workflow Policies.	Choose equals (=) from the drop-down list.
   Value	Define the value that Siebel CRM compares to the value that exists in the column of the workflow policy instance. If the Comparison field does not contain one of the following values, then the Value field is a required: Is Null Is Not Null Is Updated Is Deleted Is Added For more information, see Examples of Configuring Workflow Policies, and Using Date Calculations in the Conditions List.	Choose Printer from the drop-down list.

4. In the Actions list, choose New Record from the applet level menu, and then define fields using values from the following table.

   Field	Usage
   Action	Pick the action that Siebel CRM runs with this workflow policy.
   Sequence	Define the sequence of the action relative to other actions.
   Consolidate	If more than one record meets the workflow policy conditions during the same action interval, then you can consolidate the action to one instance. To consolidate an action, make sure the consolidate field contains a check mark. The consolidate field is not available with an action that sends a page.

5. Optional. Repeat the step 4 to add more actions, as necessary.

Restrictions with Defining a Workflow Policy

If you define a workflow process, then note the following restrictions:

• A workflow policy cannot reference the S_DOCK_TXN_LOG table. The unique index for this table is TXN_ID rather than the ROW_ID that other Siebel tables use. Siebel Workflow uses ROW_ID to do the comparison and run actions. If it makes comparisons to the S_DOCK_TXN_LOG table, then Siebel CRM creates an error.

• You cannot run a business service from a workflow policy.

• A workflow policy updates a database field directly through the data layer. It does not update a field through the business object layer. Siebel CRM can run a workflow process that includes a business component event that is related to the updated field.

Examples of Configuring Workflow Policies

This topic describes examples of configuring workflow policy actions and workflow policies. It includes the following topics:

• Examples of Configuring a Workflow Policy Action

• Examples of Configuring a Workflow Policy

Examples of Configuring a Workflow Policy Action

This topic describes examples that use to configure a workflow policy action. It includes the following topics:

• Configuring a Workflow Policy Action That Sends a Page

• Configuring a Workflow Policy Action That Sends an Email with a Repeating Message

• Configuring a Workflow Policy Action That Sends a Broadcast Message

• Configuring a Workflow Policy Action That Runsa Database Operation

• Configuring a Workflow Policy Action That Runs an External Program

You can use these examples as the basis for defining your own workflow policy actions.

Configuring a Workflow Policy Action That Sends a Page

The example in this topic includes a workflow policy action that sends a page. If the priority for a service request is very high, and if the service request is not assigned to anyone, then Siebel CRM sends a page to a support manager.

To configure a workflow policy action that sends a page

1. In the Siebel client, navigate to the Administration-Business Process screen, and then the Actions view.

2. In the Actions list, add a new record using values from the following table.

   Field	Value
   Name	Page Support Manager when SR request changes.
   Program	Send SR Page
   Workflow Object	Service Request

   If a workflow policy object is defined in the Workflow Policy Program field, then Siebel CRM updates the Workflow Object field. If necessary, you can choose a workflow policy object from the drop-down list.

3. In the Send Page Arguments form, define the argument using values from the following table.

   Field	Value
   Alpha Message Template	The [SR Status] of [SR Number] was changed.

   You use the Numeric Message Template for numeric paging and the Alphanumeric Message Template for alphanumeric paging. The pager type in the employee table determines the type of paging to use. You can copy and paste fields that are available from the Available Substitutions window.

   You can copy and paste fields that are available from the Available Substitutions window.

4. In the Recipients list, add a new record using values from the following table.

   Field	Value
   Type	Send to Position
   Name	Support Manager

   You can now use this action in a workflow policy.

5. Navigate to the Administration-Business Process screen, and then the Policies view.

6. Query the Workflow Object field for Service Request.

   This query returns a list of policies that you can use with the action that you defined in step 4.

7. In the Name column, choose a Workflow policy, such as Page SR Owner (Gold).

8. In the Actions list, create a new record, and then locate the Page Support Manager When SR Request Changes, which is the action you defined in step 2.

9. Examine the Send Page Arguments form.

   Siebel CRM uses the information you define in this topic to update information in the Send Page Arguments form.

Configuring a Workflow Policy Action That Sends an Email with a Repeating Message

The example in this topic uses a workflow policy action to send an email that includes a repeating message. Siebel CRM must notify the vice president of sales only after a specific number of deals fail to close. It uses this action with a workflow policy that uses the Batch feature. You enter relevant information in the Repeating Message field of the Send Message Arguments form. This configuration makes sure that the recipient receives one email that includes a consolidated list of information about each deal. If you do not configure a Repeating Message, then the email might not contain meaningful information.

To configure a workflow policy action that sends an email with a repeating message

1. In the Siebel client, navigate to the Administration-Business Process screen, and then the Actions view.

2. In the Actions list, create a new record using values from the following table.

   Field	Value
   Name	Excellent Quality Opportunity
   Program	Send Opportunity Email
   Workflow Object	Opportunity
   Comment	Send an email to the VP of Sales when deals are not closing.

3. In the Send Message Arguments form, define the argument using values from the following table.

   Field	Value
   Subject	Opportunities not Closing
   Message Template	Meet with [Last User First Name] [Last User Last Name] about [Opportunity] for [Account]
   Repeating Message	Meet with [Last User First Name] [Last User Last Name] about [Opportunity] for [Account]

4. In the Recipients list, create a new record using values from the following table.

   Field	Value
   Type	Send to Position
   Name	VP Sales

   You can now use this action in a workflow policy.

5. Navigate to the Administration-Business Process screen, and then the Policies view.

6. Query the Workflow Object field for Opportunity.

   This query returns a list of policies that you can use with the action that you defined in step 4.

7. In the Name column, choose a Workflow policy, such as New Opportunity.

8. In the Actions list, create a new record, and then locate Excellent Quality Opportunity, which is the action you defined in step 2.

9. Examine the Send Page Arguments form.

   Siebel CRM uses the information you define in this topic to update information in the Send Page Arguments form.

10. In the list for the Policies List, make sure the Batch Mode field contains a check mark.

Configuring a Workflow Policy Action That Sends a Broadcast Message

The example in this topic configures a workflow policy action to send a broadcast message. In this example, a service department must automate a notification policy for open service requests when there are at least 20 open requests for one service representative.

To configure a workflow policy action that sends a broadcast message

1. In the Siebel client, navigate to the Administration-Business Process screen, and then the Actions view.

2. In the Actions list, add a new record using values from the following table.

   Field	Value
   Name	Alert Representative of Open SRs
   Program	Send SR Message Broadcast
   Workflow Object	Service Request

3. In the Send Message Broadcast Arguments form, define the argument using values from the following table.

   Field	Value
   Abstract	You own over 20 Service Requests.
   Message Template	You own over 20 service requests. Please review your service request queue.

4. In the Recipients list, add a new record using values from the following table.

   Field	Value
   Type	Send to Relative
   Name	SR Owner

   You can now use this action in a workflow policy. For information about how to add an action to a workflow policy, see Configuring a Workflow Policy Action That Sends a Page.

Configuring a Workflow Policy Action That Runs a Database Operation

The example in this topic uses a workflow policy action to run a database operation. If the user changes the Severity of a service request to Critical, then Siebel CRM changes the value of the Priority field to Very High. A workflow policy can do the following types of database operations:

• Insert. Inserts a table in the Siebel database.

• Update. Updates one or more columns in an existing record in the Siebel database.

To configure a workflow policy action that runs a database operation

1. In the Siebel client, navigate to the Administration-Business Process screen, and then the Actions view.

2. In the Actions list, add a new record using values from the following table.

   Field	Value
   Name	Update SR Priority to Very High
   Program	Change SR Priority
   Workflow Object	Service Request

3. In the Arguments form, define the argument using values from the following table.

   Field	Value
   Name	New Priority
   Value	1-ASAP

   You can now use this action in a workflow policy. For information about how to add an action to a workflow policy, see Configuring a Workflow Policy Action That Sends a Page.

Configuring a Workflow Policy Action That Runs an External Program

The example in this topic uses a workflow policy action to run an external program. To define an action that runs an external program, you can use Run External Program in Siebel Workflow. For example, you can write a custom executable that calculates the quality of a new lead. If the parameters to calculate the lead changes, then a workflow process can call this executable. You can use a program named leadcalc.exe in the following directory and an Action to call and run Run External Program:

C:\bin

To configure a workflow policy action that runs an external program

1. In the Siebel client, navigate to the Administration-Business Process screen, and then the Actions view.

2. In the Actions list, add a new record using values from the following table.

   Field	Value
   Name	Run Lead Calculation Program
   Program	Run External Program
   Workflow Object	Define the workflow object involved in this action, such as Account.

   If a workflow policy object is already defined for the chosen workflow policy program, then Siebel CRM updates the Workflow Object field. If necessary, you can choose a workflow policy object. You cannot modify the Workflow Object field after you step off the record.

3. In the External Program Arguments form, define fields using values from the following table.

   Field	Value
   Executable Name	leadcalc.exe
   Command Line	Enter the command line parameters that Siebel CRM must pass to the executable.
   Execute Type	Choose an execute type.
   Available Substitutions	Choose the appropriate dynamic fields.

4. In the Recipients list, create a new record using values from the following table.

   Field	Value
   Type	Send to Position
   Name	Support manager

   You can now use this action in a workflow policy. For information about how to add an action to a workflow policy, see Configuring a Workflow Policy Action That Sends a Page.

Configuring an External Program to Run on UNIX

This topic describes how to configure an external program to run on UNIX. The predefined Run External Program workflow policy program does not support UNIX.

To configure an external program to run on UNIX

1. Define a business service that runs an external program:

   1. Navigate to the Business Service Administration screen, and then the Business Service Methods view.

   2. Add a new business service.

      For example, Run Program.

   3. Add a new method.

      For example, Run.

   4. Add a new method argument.

      For example, Program.

   5. Select Proc: Service_PreInvokeMethod.

   6. Call Clib.system in the function.

      For example:

      var program = Inputs.GetProperty (“Program�?)
      
      if (program)
      
      {
      
      Clib.system(program);
      
      }
      
      return (CancelOperation);
      

2. Define a workflow process that calls the business service that you defined in Configuring an External Program to Run on UNIX:

   1. Add a start step, a business service step, and an end step.

   2. Connect the steps.

   3. For the business service step, define Run Program and Run.

   4. For the input argument for Program, define the external program you must run.

      For example, you can define letter.txt that exists in the following directory:

      /bin/mail [e-mail] /home/users/hkim/letter.txt
      

3. Run your workflow process.

Examples of Configuring a Workflow Policy

This topic describes examples of configuring a workflow policy. It includes the following topics:

• Configuring a Workflow Policy That Sends Paging Notification of Service Requests That Are Not Assigned

• Configuring a Workflow Policy That Sends an Email Notification of Open Opportunities

Configuring a Workflow Policy That Sends Paging Notification of Service Requests That Are Not Assigned

The example in this topic uses a workflow policy to send a page. If the priority for a service request is Very High, and if no one is assigned to this service request, then Siebel CRM sends a page to the support manager. Assume the Send Page action is already defined.

To configure a workflow policy that sends paging notification of service requests that are not assigned

1. Navigate to the Administration-Business Process screen, and then the Policies view.

2. In the Policies List, click Menu, click New Record, and then create a new workflow policy using values from the following table.

   Field	Value
   Name	Page Support Manager
   Workflow Object	Service Request
   Policy Group	High Frequency
   Duration	2 hours

3. In the Conditions list, add two new records using values from the following table.

   Condition Field	Operation	Value
   Service Request Priority	=	High
   Service Request Owner	IS NULL	(Leave this field empty.)

   This step defines the action that Siebel CRM runs if the conditions are met.

4. Scroll down to the Actions list, and then add an Action.

5. Choose the appropriate notification action in the Action field.

   For example, choose Page for Critical SR Gold Support.

Configuring a Workflow Policy That Sends an Email Notification of Open Opportunities

The example in this topic uses a workflow policy to send an email notification. If the number of deals that are not closed reaches a designated level, then Siebel CRM must notify the vice president of sales. Assume you already defined a workflow policy action that batches information on the deals and sends an email that includes information about the number of designated deals.

To configure a workflow policy that sends an email notification of open opportunities

1. Navigate to the Administration-Business Process screen, and then the Policies view.

2. In the Policies List, click Menu, click New Record, and then create a new workflow policy using values from the following table.

   Field	Value
   Name	Very High Value Opportunity
   Workflow Object	Opportunity
   Policy Group	Medium Frequency
   Quantity	5
   Batch	checked

   It is not necessary for you to define the Quantity field to display a repeating message.

3. In the Conditions list, add two new records, using values from the following table.

   Condition Field	Operation	Value
   Forecast Probability	<=	50
   Forecast Revenue	>	400000

4. In the Actions list, add a new action record using values from the following table.

   Action	Consolidate
   Excellent Quality Opportunity Email	Checked

5. Scroll to the bottom of the screen and examine the Send Message Arguments form.

   Siebel CRM updates the values in this form with information from the action that you defined previously.

6. In the Actions applet, click the Excellent Quality Opportunity E-mail link in the Action applet.

7. Examine values in the Actions applet and Send Message Arguments.

   You can modify these values to meet the specific requirements of your implementation.

Aligning the Timing of the Workflow Policy Monitor with Email Creation

This topic describes how to make sure the email that Siebel CRM includes in a list of opportunities meets the workflow policy conditions. If the Workflow Policy Action agent runs too fast, then Siebel CRM might insert an individual email each time the workflow policy conditions are met.

To align the timing of the workflow policy monitor with email creation

1. Restart the Workflow Policy Monitor agent.

2. Restart the Workflow Policy Action agent.

   Set the Sleep parameter on the Workflow Policy Action to at least 5 minutes.

   For more information about starting a server process, see Administering Workflow Policies.

Customizing Workflow Policy Objects

This topic describes how to use Siebel Tools to modify predefined workflow policy objects or to configure custom workflow policy objects. It includes the following topics:

• Displaying Workflow Policy Object Types

• Configuring a Custom Workflow Policy Column

• Configuring a Custom Workflow Policy Object

• Configuring a Custom Workflow Policy Component

• Configuring a Custom Workflow Policy Component Column

• Configuring a Custom Workflow Policy Program

• Configuring a Workflow Policy Program Argument

For more information about:

• Using the Siebel client to configure a workflow policy that references compiled objects, see Process of Defining a Workflow Policy

• Using predefined policies instead of creating new objects, see Types of Predefined Workflow Policy Programs

• Reference information, see the topic about the Workflow Policy object type in Siebel Object Types Reference.

Displaying Workflow Policy Object Types

This topic describes how Siebel CRM displays workflow policy objects in the Siebel client. For information about how Siebel CRM displays workflow policy objects in Siebel Tools, see Hierarchy of Workflow Policy Objects.

Workflow Policy Objects That Siebel CRM Displays in the Siebel Client

You must use Siebel Tools to modify a predefined workflow policy or workflow policy program, or to create a custom one.

Objects That Siebel CRM Displays in the Workflow Policy View

Workflow Object in Siebel Tools	Workflow Object in the Siebel Client
Workflow Policy Object	Workflow Object drop-down list in the Policies List.
Workflow Policy Component Column	Condition Field drop-down list of the Conditions list. Values that Siebel CRM displays in the drop-down list of the Condition field are context sensitive, depending on the value that the Workflow Object field in the Policies List contains.

Objects That Siebel CRM Displays in the Actions View

Workflow Object in Siebel Tools	Workflow Object in the Siebel Client
Workflow Policy Program	Program field drop-down list in the Actions list.
Workflow Policy Program Argument	Arguments field drop-down list in the Arguments list. Values that Siebel CRM displays in the drop-down list of the Arguments field are context sensitive, depending on the value that the Program field in the Policies List contains.

Configuring a Custom Workflow Policy Column

This topic describes how to configure a custom workflow policy column. Before you can add a workflow policy column to a workflow policy component, you must configure the workflow policy column in the Workflow Policy Columns list.

Caution: If you delete a workflow policy column, then you must removal all references to this column that exist in other workflow policy objects. Even if an active workflow policy does not currently reference a workflow policy column, the Workflow Monitor Agent might reference this column in the repository, which might allow Siebel CRM to activate a new workflow policy in the future. To avoid a potential conflict, it is recommended that you remove all old references to a column that you delete.

To configure a custom workflow policy column

1. Identify the business object, business component, and applet that use the new workflow policy column:

   1. In the Siebel client, navigate to the view that will use the new policy column.

      For example, from the Accounts List, drill down on an account record, and then choose the Activities view tab.

   2. Choose the Help menu, and then the About View menu item.

   3. Note the business object, business components, and applets that this view uses.

   4. In Siebel Tools, in the Business Components list, choose one of the business components that you identified in the step c and then note the value in the Table property.

      The Table property displays the table name for the Siebel database table that this business component references.

2. Configure the new workflow policy column:

   1. Click Workflow Policy Column in the Object Explorer.

   2. Choose the Edit menu, and then the New Record menu item.

   3. In the Workflow Policy Columns list, use the values you identified earlier to configure properties for the new object.

      The combination of the table name and the column name must be unique. If this combination is already defined for another object, then you cannot save the object.

Configuring a Workflow Policy Condition That References a Foreign Key

You can configure a workflow policy condition that references a foreign key that resides in the primary table of the workflow object. For example:

SOPTY.CURR_STG_ID

where:

• S_OPTY is the primary table of the Opportunity workflow object

• CURR_STG_ID is a foreign key from the NAME column of the S_STG table

To configure a workflow policy condition that references a foreign key

1. In Siebel Tools, in the Workflow Policy Columns list, add a new workflow policy column using values from in the following table.

   Property	Value
   Name	S_STG.NAME

2. Make sure Siebel Tools added CURR_STG_ID under the Opportunity workflow policy object.

3. Add a new workflow policy component in the Opportunity workflow policy object that references the S_STG table, using values displayed in the following table.

   Property	Value
   Name	Enter a name of your choice
   Source Table Name	S_STG
   Source Column Name	ROW_ID
   Target Component Name	Opportunity
   Target Column Name	CURR_STG_ID

4. Add the new column (step 1) to the new workflow component that you configured in step 3.

   You can now configure a workflow policy condition that references the new workflow policy column.

Configuring a Custom Workflow Policy Object

This topic describes how to configure a custom workflow policy object.

To configure a custom workflow policy object

1. In Siebel Tools, create a workspace.

2. Navigate to the Workflow Policy Objects list.

3. Choose the Edit menu, and then the New Record menu item.

4. Configure properties for the new record.

5. In the Object Explorer, click Workflow Policy Components.

6. Choose the Edit menu, and then the New Record menu item.

7. Make sure the Primary property contains a check mark.

   Caution: You must define only one record in the Workflow Policy Components list as the primary workflow policy component. You can add a check mark to the Primary property for only one record. For more information, see How Siebel Tools Indicates the Primary Workflow Policy Component.

8. Add more workflow policy components, configuring relations to the primary workflow policy component, as required.

9. In the Object Explorer, click Workflow Policy Component Col.

10. In the Workflow Policy Component Columns list, add an object for each of the workflow policy components that you configured in step 8.

Configuring a Custom Workflow Policy Component

The example in this describes how to configure a custom workflow policy component.

To configure a custom workflow policy component

1. In Siebel Tools, create a workspace.

2. In the Object Explorer, click Workflow Policy Object.

3. In the Workflow Policy Objects list, query the Name property for Account.

4. In the Object Explorer, expand Workflow Policy Object, and then choose Workflow Policy Component.

5. In the Workflow Policy Components list, add a new record with a value in the Name property.

6. Enter a value in the Source Table Name property.

7. Enter a value in the Source Column Name property.

   The Source Column Name property creates a relationship between the workflow policy component you are currently configuring and the primary policy component.

8. Identify the set of columns that you must monitor for the workflow policy component that you created in step 5.

   1. Navigate to the Workflow Policy Column list.

   2. Identify predefined workflow policy columns that you can use.

      To use a column, an activity must be assigned to it and Siebel Tools must not currently display it in the Workflow Policy Component Column list.

Configuring a Custom Workflow Policy Component Column

This topic describes how to configure a custom workflow policy component column. Your might require terminology that more clearly describes your business environment than the labels that come predefined with Siebel CRM describe. Siebel CRM uses the Alias property to update the values that it displays in the Condition Field drop-down list of the Conditions list. It displays this list in the Workflow Policies view in the Siebel client. To configure a custom label, you can use the Alias property in the Workflow Component Columns list in Siebel Tools.

To configure a custom workflow policy component column

1. In Siebel Tools, create and workspace and navigate to the Workflow Policy Columns list.

2. Query the Name property for the name of the column you must modify.

   If the query returns no results, then add a new workflow policy column that references the data table and data table column that you require.

3. Navigate to the Workflow Policy Objects list, and then query the Name property for the workflow policy object that you require.

4. Navigate to the Workflow Policy Components list, and then query the Name property for the Workflow Policy Component that you require.

5. Navigate to the Workflow Policy Component Columns list.

6. Configure your customization:

   • If you are configuring a new object, then choose the Edit menu, and then the New Record menu item. Add values to the Workflow Column Name and Alias properties, as required.

   • If you are modifying an existing object, then query the Workflow Column Name property for the Workflow Policy Component Column that you required, and then modify the Alias property.

   When you configure the Workflow Column Name property, you can use the drop-down list to choose a column from the current set of columns that are available for this Workflow Policy Component.

   If the workflow policy component column that you must monitor is not in the list, then you must use the Workflow Policy Columns list to configure a new object for it.

7. In the Object Explorer, click Workflow Policy Object.

   By default, the Workflow Policy Object with the name of the object you modified in step 6 is the active record in the Workflow Policy Objects list.

8. Deliver the workspace.

9. In the Siebel client, navigate to the Administration-Business Process screen, and then the Policies view.

10. In the Policies List, click Query.

11. Query the Workflow Object field for the workflow object you modified (step 6) and then click Go.

    Siebel CRM displays the custom alias in the Condition Field drop-down list in the Conditions list.

Modifying a Workflow Policy Component Column to Display a Custom Label

The example in this topic modifies a workflow policy component column. The sales department in your company must refer to the person who manages an opportunity as the Opportunity Primary Sales Associate.

To modify a workflow policy component column to display a custom label

1. In Siebel Tools, create a workspace and in the Object Explorer, click Workflow Policy Object.

2. In the Workflow Policy Objects list, query the Name property for Opportunity.

3. In the Object Explorer, expand the Workflow Policy Object tree, click Workflow Policy Component, and then query the Name property of the Workflow Policy Components list for Opportunity.

4. In the Object Explorer, expand the Workflow Policy Component tree, and then click Workflow Policy Component Col.

5. In the Workflow Policy Component Columns list, query the Workflow Column Name property for Opportunity Primary Sales Rep Position, and then change the Alias property to Opportunity Primary Sales Associate.

6. In the Object Explorer, click Workflow Policy Object.

   By default, the Workflow Policy Object named Opportunity is the active record in the Workflow Policy Objects list.

7. Deliver the workspace.

8. In the Siebel client, navigate to the Administration-Business Process screen, and then the Policies view.

9. In the Policies List, click Query, enter New Opportunity in the Name field, and then click Go.

10. In the Conditions list, add a new record. Set the Condition Field to Opportunity Primary Sales Rep Position and set the Operation to IS ADDED.

    Siebel CRM displays the custom alias in the Condition Field drop-down list.

Configuring a Custom Workflow Policy Program

This topic describes how to configure a custom workflow policy program, which is a generic event that determines an action. To configure a custom workflow policy program, you configure the workflow policy event.

Caution: Make sure you thoroughly test any SQL query that you use with a custom workflow policy program. If this SQL query fails to find a row, then the workflow policies action cannot process a token.

To configure a custom workflow policy program

1. In Siebel Tools, create a workspace and in the Object Explorer, click Workflow Policy Program.

2. In the Workflow Policy Programs list, locate a workflow policy program that provides some or most of the functionality that you require.

3. Right-click the workflow policy program you located in step 1 and then click Copy Record.

   Siebel Tools copies the entire program, including the program arguments. For more information, see Copying an Existing Workflow Policy Program.

   Caution: Do not rename or change the name of an existing workflow policy program. If you change this name, then Siebel CRM might not be able to locate the actions that it creates for this workflow policy program.

4. In the new workflow policy program, modify the properties as necessary to meet the requirements of the custom program, such as the Workflow Object property.

5. Configure the workflow policy program arguments.

6. To avoid Workflow Monitor Agent errors, delete any workflow policy program arguments that are not active or that are not complete.

Copying an Existing Workflow Policy Program

If you configure a new workflow policy program, then it is recommended that you copy an existing workflow policy program that provides functionality that is similar to the functionality that you require. You can then modify this copy. If something goes wrong with your custom workflow policy program, then you can start over with the original, unmodified workflow policy program. If you modify a copy, then you can often reuse a significant portion of the existing configuration, which leads to fewer errors than if you configure an entirely new workflow policy program.

Using a Carriage Return in a Workflow Policy Program

It is recommended that you avoid using the carriage return character. If you configure a workflow policy program argument, and if a carriage return character exists in SQL Statement or SQL Statement Outputs, then unexpected behavior might result. Siebel CRM might not substitute the substitution value with the intended value. It might literally substitute it with the [Label].

Configuring Required Values

Required Values

Values Not Required

If you configure a workflow policy program that inserts a new record, then you must provide a value for each field that Siebel CRM requires to add this record. If you configure a default value for a column, and if the workflow policy program does not specify a value, then Siebel CRM uses that default value on the insert. For example, the S_EVT_ACT table includes the following required columns: NAME ROW_STATUS Siebel CRM sets ROW_STATUS to Y by default. It is not necessary for you to set a value for ROW_STATUS.

Siebel CRM does not require a value for a system column. For example, the following columns are system columns: CREATED CREATED BY LAST_UPD LAST_UPD_BY ROW_Id MODIFICTION_NUM CONFLICT_Id

Configuring a Workflow Policy Program Argument

The example in this topic uses a workflow policy program argument to send an email. It limits the current recipients of type relative to the Primary Sales representative. You add a relative for Primary Contact, which allows a user to configure an action that sends an email to the Primary Contact of the opportunity.

To configure a workflow policy program argument

1. In Siebel Tools, create a workspace and in the Object Explorer, click Workflow Policy Program.

2. In the Workflow Policy Program list, query the Name property for Send Opportunity Email.

3. In the Object Explorer, expand the Workflow Policy Program tree, and then click Workflow Policy Program Arg.

4. In the Workflow Policy Program Arguments list, make sure the Send to Relative workflow policy program argument exists.

5. Create a new workflow policy program argument and set the Name property to Primary Contact.

   A new workflow policy program argument cannot contain the same name as an SQL Statement Output. If you attempt to add a new workflow policy program argument that contains the same name as an SQL Statement Output, then the Monitor Agent server task pauses, and then displays the following message:

   Examining request for policy
   

6. Add the following SQL statement to the Default Value property.

   select O.PR_CON_ID, 'Send to Contact'
   
   from &Table_Owner.S_OPTY O
   
   where O.ROW_ID=?
   

   Siebel Workflow passes the ROW_ID of the violating row. An SQL query must use this same ROW_ID. In this example, the WHERE clause uses the ROW_ID of the opportunity row that meets the policy. For more information, see Guidelines for Using an SQL Statement with a Workflow Policy Program Argument.

7. Set the PickList property to Workflow Relative Type Picklist.

   This drop-down list identifies the argument as a relative.

Guidelines for Configuring a Workflow Policy Program Argument

If you configure a workflow policy program argument, then make sure you use the following formats:

• Make sure capitalization, punctuation, and spelling are correct.

• Enter the configuration in the Name column exactly as described in the Workflow Policy Program Argument object type in Siebel Object Types Reference. The following items must contain one space between each word and you must capitalize each word correctly:

  • Primary ID

  • Primary Table

  • Operation Type

  • SQL Statement

  • SQL Statement Outputs

• For example, Primary Id must include one space between Primary and Id, a capital P, a capital I, and a lowercase d.

• Avoid using a carriage return. For more information, see Using a Carriage Return in a Workflow Policy Program.

• If you use an SQL statement in a program argument, then make sure the RDBMS you use supports this statement.

  • To enter the names of the column pairs, use the following format

  • Include one space between each word.

  • Use identical capitalization.

  • Include one space before the start of parenthesis.

  • Do not include spaces in the column.

• The order of the rows is not important.

Guidelines for Using an SQL Statement with a Workflow Policy Program Argument

If you use an SQL statement with a workflow policy program argument, then it is recommended that you use the following guidelines:

• Make sure the table name and column name are in upper case.

• You must prefix the case-sensitive table name with the following value:

  &Table_Owner
  

• Make sure the RDBMS you use supports the SQL statement.

• It is recommended that the SQL statement return only one record. Use a statement that uses the outer join rather than the inner join.

• Siebel CRM can use only one workflow policy program argument that uses an SQL statement for a workflow policy program. Do not use two or more workflow policy program arguments that use SQL statements for a given workflow policy program.

• Use an SQL tool that is external to Siebel CRM to test your statement.

Caution: It is recommended that you thoroughly test your SQL statement in the context of the workflow policy program before you implement it in a production environment.

Defining Conditions for a Workflow Policy

This topic describes how to define conditional logic for a workflow policy. It includes the following topics:

• Using Standard Comparisons in the Conditions List

• Using Specialized Operators in the Conditions List

• Using Date Calculations in the Conditions List

• How Siebel CRM Interprets a Field That Is Not Known

Using Standard Comparisons in the Conditions List

Comparison	Value
greater than or equal to (>=)	5
less than or equal to (<=)	5
equal (=)	A
LIKE	Abc%
IN	(1, 2, 3)
NOT IN	('A', 'B', 'C')
BETWEEN	1 and 2
BETWEEN	'A' and 'B'
IS NULL	Not applicable
IS NOT NULL	Not applicable
greater than or equal to (>=)	5

You must use the following requirements:

• If you use LIKE, IN, NOT IN, or BETWEEN with a character field, then you must enclose the value with single quotes.

• If you use IN or NOT IN, then you must enclose the value with parentheses.

• Siebel CRM implies an AND operator between multiple conditions that use these comparison values. AND means that all the conditions must be met for the statement to evaluate to true.

• LIKE and NOT LIKE allow you to use wildcards. For example, LIKE Smith%, or NOT LIKE Sm%th%.

You must use the following requirements for the database:

• Any value that you define for a LIKE, IN, NOT IN, or BETWEEN operator in the Value field of the Conditions list of the Workflow Policies view must be in a format that the RDBMS supports.

• The IN, NOT IN, and BETWEEN operators require you to use the format that the RDBMS supports. For example:

  • IN ('a', 'b', 'c') or IN (1, 2, 3, 4)

  • BETWEEN 'A' and 'B'

  • BETWEEN 1 and 10

• If your implementation uses an MS SQL Server database, and if you define a workflow policy condition on a LONG column, then you can use only the following operators on this column:

  • IS NULL

  • IS NOT NULL

  • LIKE

  • NOT LIKE

You must manually make sure you use the correct format. The Process Designer passes the BETWEEN clause to the RDBMS. It does not confirm format, except for date and time. For date and time fields, the Process Designer converts the date and time columns to the following format:

month/day/year

hour:minute:second

Using Specialized Operators in the Conditions List

‘The Comparison field supports the IS ADDED, IS UPDATED, and IS DELETED specialized operators. Siebel CRM uses these operators for special conditions that it uses with Dynamic mode when it calls rows to look up a regular condition. If you define a workflow policy that runs in batch, then you must use a specialized operator in conjunction with a regular workflow policy condition.

Siebel CRM uses the following operators only at the workflow policy component level:

• IS ADDED. If Siebel CRM adds a new row for this workflow policy component, then it calls the workflow policy that it must examine. If you use IS ADDED in conjunction with a standard comparison, then you can use IS ADDED to update a record.

• IS DELETED. If Siebel CRM deletes a row from a workflow policy component, then it calls the workflow policy that it must examine.

Siebel CRM uses the following operators only at the field level:

• IS UPDATED. If Siebel CRM modifies the field in an existing record, or if it adds a new record that includes this field, then it calls the workflow policy that it must examine. Note the following:

  • To determine if Siebel CRM updates a field for a particular table, you can use the workflow policy component column that represents the LAST_UPD column for this table.

  • To determine if Siebel CRM modified a field in the workflow policy component, you can use the field that is named after the workflow policy component.

Guidelines for Using Specialized Operators

If you use specialized operators, then it is recommended that you use the guidelines that the following table describes.

Table Guidelines for Using Specialized Operators

Comparison	Value	Explanation
IS ADDED	If you define a workflow policy component column in the Condition field, and if you define nothing in the Condition value, then use IS ADDED.	If an instance of the workflow policy component is added, then the workflow policy condition is met. For example, if you define the workflow policy component column for the service request in the Condition field, and if you use IS ADDED in the comparison, then the condition is met when Siebel CRM creates a new service request.
IS UPDATED	If you define a field in the Condition field, and if you define nothing in the Condition value, then use IS UPDATED. The condition is met when the field changes.	For example, if you define the status of a service request in the Condition field, and if you use IS UPDATED in the comparison, then the workflow policy condition is met when Siebel CRM changes the status of the service request. For more information, see Using IS UPDATED in the Conditions List.
IS DELETED	If you define a child workflow policy component in the Condition field, and if you define nothing in the Condition value, then use IS DELETED.	A child workflow policy component is a workflow policy component that Siebel CRM associates with a parent workflow policy component. For example, a parent workflow policy component might be Service Request. A child workflow policy component might be Service Request Activity. If you use IS DELETED in conjunction with another workflow policy condition, then the other condition must reference the parent workflow policy component. For more information, see Using IS DELETED in the Conditions List.

Generating Database Triggers with Specialized and Standard Operators

Siebel CRM implies an OR between specialized operators, where one or more of the workflow policy conditions must be met before the action occurs. For example, a service representative can receive an email if Siebel CRM adds an activity to an open service request. The following conditions in the policy implement this example:

• Service Request Status = 'Open'

• Service Request Activity Component IS ADDED

If a workflow policy condition is IS ADDED or IS UPDATED, then the database triggers that Siebel CRM creates do not represent every condition defined in the policy. The policy ignores any database triggers that are not represented. For details, you can examine the entries in the trigger.sql file that Siebel CRM creates as a result of doing the comparison. This behavior is expected.

If you modify a condition, then you must run Generate Triggers so that Siebel CRM implements this condition.

If you use a workflow policy condition with a standard operator, then the database triggers that Siebel CRM creates encompass the condition. If you use a specialized operator, then Workflow Monitor Agent evaluates this condition at run time.

Using IS UPDATED in the Conditions List

Siebel CRM joins workflow policy conditions when it runs an IS UPDATED statement, but the format of the trigger.sql statement that it creates for the condition does not include an AND operator in the SQL format.

If a workflow policy condition is met, and if IS UPDATED does not occur, then the Workflow Monitor Agent calls the policy. If an IS UPDATED operator is included as criteria on a field in this condition, then Siebel CRM does not check any of the other fields that the condition references.

Using IS DELETED in the Conditions List

The example in this topic uses IS DELETED in the Conditions list. If a user deletes an activity from a service request that includes a Sub-Status of In Process, then Siebel CRM must notify the service request owner.

Policy	First Condition	Second Condition	Action
References the Service Request Workflow policy object.	The first condition depends on each of the following situations being true: Field is Activity Component Comparison is IS DELETED Value is empty	The second condition depends on each of the following situations being true: Field is Service Request Sub-Status Comparison is equal (=) Value is In Process	Send an email to the service request owner.

If you use IS DELETED, then Siebel CRM cannot track the ROW_ID of the record that it deletes from the child workflow policy component. It cannot log this record in the S_ESCL_REQ table and the Workflow Monitor Agent cannot identify the deleted row. If you must use Siebel Workflow to capture the deleted row, then you must use a workflow process that a run-time event starts. The run-time event is the BusComp_PreWriteRecord event. For more information about the BusComp_PreDeleteRecord event, see Siebel Object Interfaces Reference. For more information, see Tables That Workflow Monitor Agent Uses.

Using Date Calculations in the Conditions List

The Workflow Monitor considers date and time when it evaluates a workflow policy condition that performs a date comparison. You can use the CURRENT operator for a date comparison. You can use the following format:

CURRENT [+/-] d:h:m

where:

• d is the day

• h is the hour

• m is the minutes

For example, the following value is the value in CURRENT plus one day, two hours, and three minutes:

CURRENT + 01:02:03

You can use CURRENT in the comparison value for a date field. You can use CURRENT to define the activation date and expiration date for a broadcast message action.

For more information, see Predefined Business Services.

How Siebel CRM Interprets a Field That Is Not Known

If a field value is not known rather than having no value, then Siebel CRM interprets it as null. For example, assume a condition includes the following logic:

FIeldA IS UPDATED

FieldB <> "MyValue"

In this situation, if FieldB is null, then the following condition is false:

<> "MyValue"

Siebel CRM interprets a Null field value as not known. It assumes this field could be set to anything, including Y. Siebel CRM cannot conclude that the field is definitely not set to Y, so it returns false and does not run the Workflow Monitor Agent.