14Using Predefined Workflow Policies
Using Predefined Workflow Policies
This chapter describes workflow policies, predefined workflow policies, and workflow policy programs that you can use. It includes the following topics:
About Workflow Policies
This topic includes the following topics:
You can use a workflow policy to start a workflow process. A workflow policy includes one or more workflow policy conditions. If the workflow policy conditions are met, then Siebel CRM runs the workflow policy action.
The name Workflow Policies replaces the name Workflow Manager, which Siebel CRM uses to refer to the Siebel Business Process automation tool in earlier Siebel CRM releases.
For more information, see Administering, Testing, and Migrating Workflow Policies and Reference Materials for Siebel Workflow
Overview of Workflow Policy Objects
A workflow policy object provides the context in which Workflow Policies operate. The workflow policy object, through the policy components of the workflow process, defines the set of tables and columns that a workflow policy monitors and how each table in the workflow policy object relates to the other tables. This collection of columns and the relations between the tables of the workflow policy object represent the entity in Siebel Tools that you must monitor.
Siebel Tools allows you to access predefined workflow policy objects for common business requirements, such as opportunities, service requests, or contacts. You can modify some predefined workflow policy objects through administrative screens in the Siebel client. To define a custom workflow policy object, you can use Siebel Tools.
Relationships Between Objects of a Workflow Policy
The following figure illustrates the relationships that exist between workflow policy objects, workflow policy columns, and workflow policy programs.
Explanation of Callouts
The following relationships exist between workflow policy objects:
Workflow Policy Object. A workflow policy object is a collection of workflow policy components. It is a parent to the workflow policy components and the workflow policy component columns.
Workflow Policy Component. A workflow policy component is a logical mapping to a database table in the Siebel database. It defines the relations between the primary workflow policy component and other workflow policy components of a workflow policy object. Except for the primary workflow policy component, each workflow policy component defines a relation to another workflow policy component. To create this relation, Siebel CRM defines a source policy column and a target policy column. These source and target columns of a workflow policy component identify foreign key relations between the tables.
A primary workflow policy component is a workflow policy component to which other workflow policy components are directly or indirectly related. Siebel CRM can define the workflow policy columns that are available for monitoring in the workflow policy from these workflow policy components. Each workflow policy object contains only one primary workflow policy component. The other workflow policy components of a workflow policy object are directly or indirectly related to the primary workflow policy component.
Workflow Policy Component Column. A workflow policy component column defines the columns in the Siebel database table that Siebel CRM can monitor. You can allow Siebel CRM to monitor these columns when you define workflow policy conditions for a workflow policy. For more information, see How Siebel Tools Indicates the Primary Workflow Policy Component.
To define a workflow policy object and the components of a workflow process, it is recommended that you familiarize yourself with the Siebel Data Model. For more information, see Siebel Data Model Reference on My Oracle Support.
Viewing the Hierarchy That Exists Between Workflow Policy Objects
Each workflow policy component can expose a number of workflow policy component columns. In the Object Explorer, a workflow policy component column is the child object of a workflow policy component, which is itself a child object of a workflow policy object. To view this hierarchy, see Hierarchy of Workflow Policy Objects.
Example of an Entity Relationship Diagram for a Workflow Policy
The following figure displays the entity relationship diagram of four workflow policy components for a service request. It illustrates each of the components, their relations to one another, and the columns that are of interest. Service request is the primary workflow policy component. Siebel CRM joins the other three components to the primary directly or indirectly.
Using a Workflow Policy to Monitor Tables
A workflow policy can monitor only Siebel database tables. You cannot use a workflow policy to monitor a database table that is external to Siebel CRM.
Do not monitor the S_DOCK_TXN_LOG table or table columns of Enterprise Integration Manager (EIM). Siebel CRM prefixes the name of an EIM table with EIM_ or ends it with _IF. Siebel CRM can monitor most tables except S_DOCK_TXN_LOG and EIM tables.
Structure of a Workflow Policy
A rule includes an IF/THEN structure that provides the basic underlying logic of a workflow policy. The following statement describes the structure of a rule:
If the conditions are true, then an action occurs.
A rule includes a workflow policy condition and a workflow policy action. If the workflow policy conditions are met, then Siebel CRM calls an action. The following figure includes an example workflow policy.
Explanation of Callouts
A typical workflow policy includes the following items:
Workflow Policy. Includes workflow policy conditions and workflow policy actions. A workflow policy represents rules that the Siebel database monitors.
Workflow Policy Condition. A situation that causes something to happen.
Workflow Policy Action. An action that Siebel CRM calls if a workflow policy condition is met.
Workflow Policy Program. A predefined program that provides arguments for the workflow policy action.
Duration. The amount of time that workflow policy conditions exist to allow the conditions of the policy to be met. For more information, see Determining Requirements for the Workflow Policy.
A workflow process can support the functionality that is available with a workflow policy. It is recommended that you use a workflow policy to start a workflow process and to use a workflow process to define an action.
Workflow Policy Condition
A workflow policy condition is an object that expresses an object or the relationship of an attribute to a value. For example, a workflow policy condition can target data, such as the severity of a service request. The workflow policy condition compares severity data to a value, such as 1-Critical. In this example, the combination of the following items define the condition:
Data element
Service request severity
A comparison operation, such as the equal sign (=)
The value, such as 1-Critical
The fact that the severity of a service request is 1-Critical is a problem only if the workflow policy condition remains valid for an extended amount of time, such as two hours. In this example, to make sure the condition remains valid, you can set a two hour duration on the workflow policy. This duration is part of the condition. Siebel CRM runs the policy actions only if the conditions are met in the time period that the duration measures.
A workflow policy action can occur if a duration is not set. For example, Siebel CRM can send an email to a sales manager each time a sales representative quotes a discount rate that exceeds 25 percent on revenue that is less than $100,000.
A workflow policy can contain more than one workflow policy condition. These conditions must be met before an action can occur. For example, a service request with a 1-High severity and a two hour duration might be important only if another comparison is also valid, such as if the service request status is Open. The condition is the combination of the following comparison operations:
SR Severity = 1-Critical AND SR Status = Open
A workflow policy supports only the AND operand between workflow policy conditions. It does not support the OR operand. To monitor the service request severity to be 1-Critical or 2-High and the status to be Open, you can use the IN operand to evaluate the OR logic of the severity:
SR Severity IN (’1-Critical’,’2-High’) AND SR Status = Open
To implement OR operand logic, you can define multiple workflow policies for each workflow policy condition. For more information, see Examples of Configuring Workflow Policies.
Workflow Policy Action
A workflow policy action is an event that occurs if the workflow policy conditions are met. It includes the following items:
An action, which is a type of request, such as Send an Urgent Page
The action parameters, which are the arguments, such as the name of the recipient of the page and the alphanumeric text that Siebel CRM transmits with the page
You can define multiple actions for one workflow policy, such as sending a page to one person and an email to another person. You can reuse an action in multiple workflow policies. For more information, see Customizing Workflow Policy Objects
You can use a workflow policy action to start a workflow process.
You can pass a constant from a workflow policy action to a workflow process. For more information, see Passing a Constant from a Workflow Policy Action to a Workflow Process.
Workflow Policy Program
A workflow policy program is a predefined program that provides arguments for a workflow policy action. It identifies the action that Siebel CRM runs if the workflow policy conditions are met. A workflow process can run the action that a workflow policy program defines.
You can use a workflow policy program in multiple actions and you can use actions in multiple workflow policies.
A workflow policy program can be of the following type:
Send Message. Sends an email to one or more recipients.
Send Page. Sends a page to one or more recipients.
Send Broadcast Message. Inserts a message broadcast for one or more recipients.
DB Operation. Inserts or updates the records of a Siebel database table.
External Program. Runs an executable.
Assignment Request. For internal use only.
Generic Request Server. Sends a server request to a server component.
For more information, see the topic about the Workflow Policy Program and Workflow Policy Program Argument object types in Siebel Object Types Reference.
Predefined Workflow Policy Programs
A workflow policy uses workflow policy actions that reference workflow policy programs that are predefined. The following items are examples of workflow policy programs that are predefined:
Send Broadcast Message
Database Operation
For more information, see Types of Predefined Workflow Policy Programs.
Sequence That a Workflow Policy Uses
The following figure illustrates the sequence that a typical workflow policy uses.
Explanation of Callouts
A typical workflow policy does the following work:
Detect End-User Activity or Server Process. An end-user activity or server process occurs.
Create Triggers. To enforce workflow policies, Siebel CRM uses database triggers at the data layer. If the conditions for a workflow policy are met, then these database triggers capture the database event and provide this information to the Workflow Policy Manager server component.
Fire Triggers. Siebel CRM queues the S_ESCL_REQ table.
Read Records. The Workflow Monitor Agent reads records in the S_ESCL_REQ table. To process requests, it then runs the actions that are defined for the workflow policy. The Workflow Monitor Agent is a component of the Workflow Policy Manager.
Start. In some situations, an action can start the Workflow Process Manager.
The Workflow Policy Manager uses the Workflow Action Agent to make sure Siebel CRM can scale. This agent can run on a different application server in the Siebel Enterprise.
For more information about:
Workflow Action Agent, see Running a Workflow Policy with the Workflow Action Agent.
Generate Triggers, Workflow Process Manager and Workflow Monitor Agent, see Run-Time Architecture That Siebel Workflow Uses.
The S_ESCL_REQ table, see Fixing Problems in the S_ESCL_REQ Table.
Hierarchy of Workflow Policy Objects
Using Siebel Tools, you can modify an existing workflow policy and create a new workflow policy to meet your business requirements.
The following screen includes the Workflow Policy object type hierarchy in the Object Explorer in Siebel Tools.
You can display workflow policy objects in the Object Explorer. For more information, see Displaying Object Types You Use to Develop a Workflow Process.
If you use Siebel Tools to modify or define a workflow policy object with a local database, then any changes you make are not available on the Siebel Server until after you apply them to the Siebel Server.
For more information, see Object Hierarchy That Workflow Processes Use.
How Siebel Tools Indicates the Primary Workflow Policy Component
The Primary property provides a visual indication of the workflow policy component that is the primary workflow policy component and the workflow policy components that are not primary. For example, the Primary property for the Account workflow policy component includes a check mark, which defines Account as the primary workflow policy component. Other workflow policy components that Siebel Tools lists in the Workflow Policy Components list are nonprimary workflow policy components of the Account workflow policy object.
Types of Predefined Workflow Policy Programs
This topic describes the types of predefined workflow policy program that you can use. It includes the following topics:
Workflow Policies come with a number of predefined workflow policy programs that you can use to meet specific business requirements. You can modify a predefined workflow policy program that already exists rather than creating a new workflow policy program.
Overview of Predefined Workflow Policy Programs
A workflow policy program is a generic event that determines an action. It defines the actions that Siebel CRM runs if the workflow policy conditions are met. You can view a workflow policy program:
To view a workflow policy program. Open the Siebel client, navigate to the Administration-Business Process screen, and then the Actions view.
To view object definitions of a workflow policy program. Open Siebel Tools. In the Object Explorer, click Workflow Policy Programs.
| Program Type | Workflow Policy Program | Description |
|---|---|---|
Send Page |
Send Page |
Sends a generic page. |
Send Opportunity Page |
Sends a page regarding an opportunity. |
|
Send Quote Page |
Sends a page regarding a quote. |
|
Send SR Page |
Sends a page regarding a service request. |
|
Send Email |
Send Email |
Sends a generic email message. |
Send Opportunity Email |
Sends an email regarding an opportunity. |
|
Send Quote Email |
Sends an email regarding an opportunity quote. |
|
Send SR Email |
Sends an email regarding a service request. |
|
Send Broadcast Message |
Send Message Broadcast |
Sends a generic broadcast message. |
Send SR Message Broadcast |
Sends a broadcast message regarding a service request. |
|
Send Opportunity Message Broadcast |
Sends a broadcast message regarding an opportunity. |
|
Run External Program |
||
Run External Program |
Changes the owner of the service request. |
|
Database Operation |
Change SR Close Date to Today |
Changes the group of the service request. |
Change SR Owner |
Changes the owner of the service request to the current manager for the owner. |
|
Change SR Group |
Changes the priority of the service request to a new value. |
|
Change SR Owner to Manager |
Changes the severity of the service request to a new value. |
|
Change SR Priority |
Changes the status of the service request to a new value. |
|
Change SR Severity |
Changes the Sub-Status of the service request to a new value. |
|
Change SR Status |
Creates an activity for a service request. |
|
Change SR Sub-Status |
Creates an activity for an opportunity. |
|
Create SR Activity |
Sends a generic page. |
|
Create Opportunity Activity |
Sends a page regarding an opportunity. |
|
Workflow Policy Program That Sends a Page
The following table describes arguments and values for the Send Page workflow policy program type. If you choose a Send Page type of workflow policy program in the Actions view in the Siebel client, such as Send SR Page, then Siebel CRM displays the Send Page Arguments form and the Recipients list. The Send Page Arguments form allows you to define a template that Siebel CRM uses to create the message it sends to the recipient that you add in the Recipients list.
Table Arguments and Values for the Send Page Workflow Policy Program Type
| Argument | Description |
|---|---|
Numeric Message Template |
Specifies the numeric message if the pager is numeric. |
Alpha Message Template |
Specifies the text message if the pager is alphanumeric. The following phrase is a reserved phrase in Siebel Workflow: Workflow Policy Object Do not use this phrase in a message. |
Available Substitutions |
Specifies the dynamic fields that you can use in the Alpha Message Template. If the action runs, then Siebel CRM updates the substitution value with the value from the record that meets the workflow policy conditions. |
Request Key |
A string indicating which Page Manager should execute the action. You use this when multiple Page Managers are running. When you specify a request key string, it should match the Request Key parameter of the Page Manager that you want to execute the action. Leave this argument blank when you are running one Page Manager or when the Page Manager that executes the action is not important. |
Note the following:
Workflow Policies determine how to format the message depending on the type of pager that the person who receives the page uses.
If none of the message arguments contains a value, then Workflow Policies logs an error message and Siebel CRM does not finish the action.
Siebel CRM can send a page only to an employee. It stores pager information for an employee in the Employee Administration view. The Siebel database does not store pager information for contacts.
Siebel CRM can substitute values in a message that originates from the Available Substitutions field.
Using Numeric Paging
Numeric paging is inherently not reliable because of insufficient computer protocols that exist to send a numeric page. If Siebel CRM must send a numeric page, then you can use the Pager Pin field in the employee table to control the delay that occurs between dialing the paging phone number and sending the numeric message. You can add commas to the Pager Pin field. Two commas is equal to approximately a one second delay. It is recommended that you avoid using numeric paging in a Siebel CRM application that is mission critical.
Workflow Policy Program That Sends an Email
The following table describes arguments and values for the Send Email workflow policy program type. If you choose a Send Email type of workflow policy program in the Actions view in the Siebel client, such as Send SR Email, then Siebel CRM displays the Send Message Arguments form and the Recipients list. The Send Message Arguments form allows you to define a template that Siebel CRM uses to create the message it sends to the recipient that you add in the Recipients list.
| Argument | Description |
|---|---|
Subject |
Specifies the Subject line of the email message. |
Message Template |
Specifies the message text. The maximum length is 2000 characters, including variable substitutions. The following word is a reserved word in Siebel Workflow: Current Do not use this word in a message. |
Repeating Message |
Specifies the message that Siebel CRM repeats if the Consolidate field contains a check mark on the Workflow Policies view. The following word is a reserved word in Siebel Workflow: Current Do not use this word in a message. |
Available Substitutions |
Specifies a dynamic field that you can use in the Subject, Message Template, or Repeating Message. If Siebel CRM runs the action, then it updates the substitution value with the value from the record that meets the workflow policy conditions. |
Request Key |
A string indicating which Email Manager should execute the action. You use this when multiple Email Managers are running. When you specify a request key string, it should match the Request Key parameter of the Email Manager that you want to execute the action. Leave this argument blank when you are running one Email Manager or when the Email Manager that executes the action is not important. |
Sending an Email to an Address That Siebel CRM Stores in a Custom Field
You can configure Workflow Manager to send an email to an email address that is defined in a custom field, including to an address that Siebel CRM stores in a column other than S_EMPLOYEE.EMAIL_ADDR. For more information, see 475546.1 (Article ID) on My Oracle Support.
Workflow Policy Program That Sends a Broadcast Message
| Argument | Description |
|---|---|
Activation |
Specifies the date and time for which the broadcast message is active. You can use the CURRENT variable when you define the activation date. For more information, see Using Date Calculations in the Conditions List. |
Expiration |
Specifies the date and time when the broadcast message expires. You can use the CURRENT variable when you define the activation date. For more information, see Using Date Calculations in the Conditions List. |
Abstract |
Specifies a short description of the broadcast message. |
Message Template |
Specifies the text of message to broadcast. The maximum length is 2000 characters, including variable substitutions. The following word is a reserved word in Siebel Workflow. Do not use this word in a message: Current |
Severity |
Specifies the severity of the message to broadcast. |
Available Substitutions |
Specifies the dynamic fields that you can use in the Abstract and Message Template. If Siebel CRM runs the action, then it updates the substitution value with the value from the record that meets the workflow policy conditions. |
Activating the Check New Broadcasted Message Workflow Policy
The Check New Broadcasted Message workflow policy monitors the S_BRDCST_MSG table. If Siebel CRM adds a record to this table, then it starts the Notify Broadcasted Message workflow process to broadcast a new message. If the Type property of a workflow policy program is set to Send Broadcast Message, and if your implementation uses caching for the broadcast message on an Object Manager server component, then you must activate the Check New Broadcasted Message workflow policy. This policy belongs to the Siebel Messaging policy group. For more information about:
Activating a workflow policy, see Overview of Creating Database Triggers.
Configuring caching for a broadcast message, see Siebel Applications Administration Guide.
Consolidating Messages That Siebel CRM Sends Through the Send Broadcast Message Workflow Policy Program
Siebel CRM cannot consolidate multiple broadcast messages into a single message. A user receives every broadcast message that a workflow process sends, each as a separate message.
Workflow Policy Programs That Run a Database Operation
The following table describes arguments and values for the Database Operation workflow policy program type. Siebel CRM comes predefined with a number of database operation programs. If you choose a Database Operation type of workflow policy program in the Actions list, such as Create Opportunity Activity, then Siebel CRM displays the Arguments list. You can add these arguments.
Table Arguments for the Database Operation Workflow Policy Program Type
| Argument | Description |
|---|---|
Name |
Specifies the name of the column that Siebel CRM updates. |
Required |
Indicates that the argument is required. |
Value |
Specifies the updated value of the column. If you define a substitution in the program, then you can use a substitution in the value. To add a substitution to the value, you use rectangle (square) brackets that enclose the variable. For example: [SR Num] |
Workflow Policy Program That Runs an External Program
| Argument | Description |
|---|---|
Executable Name |
Specifies the path and name of the executable to run. For example, the executable starts from the Siebel Server. The executable can be a batch program. If you do not provide a path, then Siebel CRM assumes the executable is located in the directory where you install the Siebel Server. For example, if you install the Siebel Server in the C:\siebsrvr directory, then Siebel CRM uses the following default path for the executable: C:\siebsrvr\bin The external program cannot be an interactive program that requires a user interface or that accesses the Windows desktop. |
Command Line |
Include the parameters that Siebel CRM must send to the executable. To send multiple substitution parameters, you must include a space between each parameter. For example: "[FirstName]"^"[LastName]" where:
You must use double quotes to enclose a substitution parameter that includes a space. Siebel CRM sends these quotes as part of the parameter. For more information, see the topic about the Workflow Policy Program object type in Siebel Object Types Reference. |
Execute Type |
You can use one of the following values for the Execute Type:
If the external program is a Visual Basic program that creates a file, then you must set the Execute Type argument to Wait. If you set Execute Type to No Wait, then Visual Basic attempts to write the file two times, thus corrupting the data. |
Available Substitutions |
Specifies dynamic fields that you can use as command line parameters. If the action runs, then Siebel CRM updates the substitution value with the value from the record that caused it to run the workflow policy program. |
Using Predefined Workflow Policy Programs
This topic includes the following topics:
Using a Workflow Policy Program to Manage the Service Request Close Date
Using a Workflow Policy Program to Assign a Service Request Owner
Using a Workflow Policy Program to Escalate a Service Request
Using a Workflow Policy Program to Send a Quote Through a Pager
Using Predefined Workflow Policy Programs for Siebel Marketing.
The examples in this topic use predefined workflow policy programs. To view these programs in Siebel Tools, click Workflow Policy Program in the Object Explorer.
Using a Workflow Policy Program to Manage the Service Request Close Date
The example in this topic uses a workflow policy program to close service requests that are marked as resolved but not closed. You can define a workflow policy so that if a service request includes an activity of type Resolution, and if the service request is open for more than five days, then Siebel CRM changes the service request close date to the date for today. If this workflow policy calls the workflow policy program, then the workflow policy program changes the current system date to the value that the Close Date field of the service request contains.
| Argument Name | Description |
|---|---|
Primary ID |
Contains the row ID of the service request that meets the conditions for the workflow policy. |
Primary Table Operation Type |
Specifies the S_SRV_REQ table and the operation that Siebel CRM runs to do the Update operation. |
Sql Statement |
Contains a SQL statement to get the current date. It uses the following format: select sys_extract_utc(current_timestamp) from
&Table_Owner.S_DUAL
To get the current date, this statement calls the following Siebel function: now The SQL can include a math function. For example, the following SQL statement returns the current date plus seven days: select {fn now()}+7 from &Table_Owner.S_DUAL
Different RDBMS databases use different formats for the same function. For example, in MSSQL, the GetDate function returns the current date. The column name length must be less than 30 characters. For example, the following statement is not valid because it is more than 30 characters in length: TO_CHAR(CREATED,'dd month yyyy','NLS_DATE_LANGUAGE=FRENCH') |
Sql Statement Outputs |
Siebel CRM gets the value for the Today variable from the SQL statement. |
New Close Date (Column) |
Specifies to update the ACT_CLOSE_DT column in the record. |
New Close Date |
Specifies to update the field to the value of Today. |
Update Row ID |
Specifies the Row Id of the record you must update. This argument is the same as the value of the Primary ID. |
Using a Workflow Policy Program to Assign a Service Request Owner
The example in this topic uses a predefined workflow policy program to assign a service request that is not yet assigned. If an open service request is not assigned for a certain amount of time, then this workflow policy program assigns it to a person who is considered an expert handling this type of the service request. This configuration allows the appropriate person to view the incoming service request, choose a new owner from a drop-down list, and then place this owner in the service request field that matches the workflow policy condition.
| Argument Name | Description |
|---|---|
Primary ID |
Contains the Row Id of the service request that meets the workflow policy condition. |
Primary Table Operation Type |
Specifies the S_SRV_REQ table. Specifies to run the Update operation. |
New Owner (Column) |
Specifies to update the Owner_EMP_ID field in the record that Siebel CRM updates. |
New Owner |
Specifies to display a drop-down list that allows the user to assign a new owner. |
Visible |
If checked, then indicates that the drop-down list is visible to the user. |
Using a Workflow Policy Program to Escalate a Service Request
The example in this topic uses a predefined workflow policy program to assign an open service request to a manager. If the service request is not closed within a certain amount of time, then Siebel CRM assigns it to the manager of the service request owner. This workflow policy program does the following:
Uses the Primary ID as input into a SQL statement
Uses an SQL query statement to get the current value of the Manager field
Sets the New Owner field to default to the current value of the Manager field
Allows the user to use a drop-down list to update the New Owner field
| Argument Name | Description |
|---|---|
Primary ID |
Contains the Row Id of the service request that meets the workflow policy condition. |
Primary Table |
Specifies the S_SRV_REQ table. |
Operation Type |
Specifies to run the Update operation. |
New Owner (Column) |
Specifies to update the Owner_EM_ID field in the record that Siebel CRM updates. |
New Owner |
Specifies to display a drop-down list that allows the user to assign a new owner. |
Sql Statement |
The Workflow Policy Monitor must use object definitions that are contained in the workflow policy object, workflow policy components, and workflow policy columns. If your configuration uses a workflow policy program, and if this configuration references Siebel tables, then you must use SQL code to explicitly join the base table. The following example SQL statement joins four tables. These joins allow Siebel CRM to access the data that resides in these tables: SELECT MGRPOS.PR_EMP_ID FROM &TABLE_OWNER.S_POSTN POS, &TABLE_OWNER.S_EMPLOYEE EMP, &TABLE_OWNER.S_POSTN MGRPOS, &TABLE_OWNER.S_SRV_REQ SR WHERE SR.ROW_ID = ? AND SR.OWNER_EMP_ID = EMP.ROW_ID AND EMP.PR_POSTN_ID = POS.ROW_ID AND POS.PAR_POSTN_ID = MGRPOS.ROW_ID This SQL gets only one field. This SQL uses the following question mark as a placeholder to input the value of the Primary ID. Siebel CRM replaces the question mark with the Primary ID: SR.ROW_ID = ? |
Sql Statement Inputs |
Set to the value of Primary ID. |
Sql Statement Outputs |
Set to the value of Manager. |
Using a Workflow Policy Program to Send a Quote Through a Pager
The example in this topic uses a predefined workflow policy program to send a quote depending on the relationship that exists between the value for the quote and the revenue value of the opportunity that the quote references. If a quote contains a value that is less than some percentage of the revenue for the opportunity, then Siebel CRM considers it as heavily discounted, and then sends a page to a designated employee.
SQL Usage with This Example
This workflow policy program sends a page. The SQL statements include one default RDBMS and three that are specific to one of the following RDBMSs: Oracle Database and Oracle Database SE2.
The asterisk and equal sign (*=) specify an outer join. The default SQL statement uses this join to get five values from four tables:
select q.QUOTE_NUM, q.REV_NUM, o.NAME, a.NAME, a.LOC from &Table_Owner.S_DOC_QUOTE q, &Table_Owner.S_ORG_EXT a, &Table_Owner.S_OPTY o where q.ROW_ID = ? and q.OPTY_ID *= o.ROW_ID and q.TARGET_OU_ID *= a.ROW_ID
The plus sign (+) in the following code specifies an outer join. The SQL statement uses this join to get five values from four tables:
select q.QUOTE_NUM, q.REV_NUM, o.NAME, a.NAME, a.LOC from &Table_Owner.S_DOC_QUOTE q, &Table_Owner.S_ORG_EXT a, &Table_Owner.S_OPTY o where q.ROW_ID = ? and q.OPTY_ID = o.ROW_ID (+) and q.TARGET_OU_ID = a.ROW_ID (+)
The SQL statement is required. If an SQL statement that uses the following format occurs, then this format takes precedence:
<SQL>
Output from the SQL statement defines the following variables. These variables contain the result of the query statement. If the table that the outer join uses does not exist, then these variables contain null:
Quote Number
Revision
Opportunity
Account
Site
Using Predefined Workflow Policy Programs for Siebel Marketing
This topic describes how to use workflow policy programs to assist with a marketing campaign. It includes the following topics:
Using a Workflow Policy Program to Send Email for a Marketing Campaign
The Send Campaign Email workflow policy program allows a marketer to send an email to the targets of the marketing campaign, such as contacts or prospects. To personalize these emails, it uses Available Substitutions in the Send Message Arguments form, such as Prospect First Name. To choose the Recipient Type, you use the Recipients list in the Workflow Policy view in the Siebel client. The campaign contacts and prospects are visible in the Contacts/Prospects list in the Campaign Administration view.
Modifying Available Substitutions
To add a new substitution to the Available Substitutions list, you modify the SQL Statement Outputs property of the workflow policy program.
To modify available substitutions
In Siebel Tools, create a workspace.
Query the Name property of the Workflow Policy Programs list for Send Campaign Email.
Right-click the Send Campaign Email workflow policy program, and then click Lock Object.
In the Workflow Policy Program Arguments list, choose the SQL Statement Outputs property.
In the Default Value property, add the substitution.
The Default Value property contains a comma separated list of substitution variables. These variables hold the result of the query statement. Siebel CRM displays the list that is defined in the Default Value property in the Available Substitution field in the Send Message Argument form.
Using a Workflow Policy Program to Create Activities for a Marketing Campaign
The Create Campaign Contact Activity workflow policy program creates an activity for the contacts or prospects who are the targets of the campaign. To define the data that Siebel CRM uses to update the Contact Activity record, you use the Workflow Policy Program Arguments list.
| Argument | Description |
|---|---|
Name |
The following values are available:
|
Required |
Indicates if the argument is required. |
Value |
Text or drop-down list. |
Using a Workflow Policy Program to Assign a Contact to a Marketing Campaign
The Assign to Campaign workflow policy program adds a contact or prospect to the list of contacts or prospects that Siebel CRM uses for the campaign.
| Argument | Description |
|---|---|
New Campaign |
Choose a campaign to which Siebel CRM must assign the contact or prospect. |
Developing a Workflow Policy That Manages a Marketing Campaign
The example in this topic describes how to develop a workflow policy to manage a marketing campaign. In this example, a marketer must run a campaign that depends on how the campaign recipient replies:
Siebel CRM sends an email that informs recipients that if they order a new product over the phone, then they can receive a discount. The marketer must keep track of the recipients and give them two weeks to reply.
At the end of the two week period, Siebel CRM assigns recipients who do not reply to a new campaign.
To develop a workflow policy that manages a marketing campaign, do the following tasks:
Defining Workflow Policy Actions for the Marketing Campaign
This task is a step in Developing a Workflow Policy That Manages a Marketing Campaign.
This example uses the following workflow policy actions:
Send Campaign Email. Sends the offer email to the campaign recipients.
Create Campaign Contact Activity. Records the activity that Siebel CRM associates with the contact.
Assign to Campaign. Assigns nonrespondents to a new campaign.
To define workflow policy actions for the marketing campaign
Define the send campaign email action:
In the Siebel client, navigate to the Administration-Business Process screen, and then the Actions view.\
-
In the Actions list, add a new record using values from the following table:
Field Value Name
Send First Campaign Contact
Program
Send Campaign Email
Workflow Object
Campaign Contact
Comment
Enter appropriate text, as required.
-
In the Send Message Arguments form, define the argument using values from the following table:
Field Value Subject
Enter text and dynamic fields, as required.
Message Template
Enter text and dynamic fields for sending email to contacts.
-
In the Recipients list, add a new record using values from the following table:
Field Value Type
Choose a predefined Recipient.
Name
Choose the appropriate recipient name.
This action is now available for use in a workflow policy.
Define a create campaign contact activity action:
Navigate to the Administration-Business Process screen, and then the Actions view.
In the Actions list, add a new record using values from the following table.
Field Value Name
First CD-ROM Campaign
Program
Create Campaign Contact Activity
Workflow Object
Campaign Contact
Comment
Enter appropriate text, as required.
In the Arguments list, define the Type argument using values from the following table.
Field Value Argument
Type
Value
Define the type of contact activity for this action, such as In Store Visit, or Demonstration.
The Type argument is required. You can also define additional optional arguments, such as Description or Status. For each additional argument you define, create a new record in the Arguments list, then define the field and value.
Define an assign to campaign email action:
Navigate to the Administration-Business Process screen, and then the Actions view.
In the Actions list, add a new record using values from the following table.
Field Value Name
Assign to Campaign
Program
Assign to Campaign
Workflow Object
Campaign Contact
Comment
Enter appropriate text, as required.
In the Arguments list, define the Type argument using values from the following table.
Field Value Argument
New Campaign
Value
Not applicable
Defining the Workflow Policy Group for the Marketing Campaign
This task is a step in Developing a Workflow Policy That Manages a Marketing Campaign.
In this example, you define a workflow policy group for the marketing campaign.
To define the workflow policy group for the marketing campaign
Navigate to the Administration-Business Process screen, and then the Policy Groups view.
In the Policy Groups list, add a new record using values from the following table.
Field Value Name
CD-ROM Promotion
Comments
group of policies for CD-ROM marketing campaign
Defining the Email for the Marketing Campaign Policy
This task is a step in Developing a Workflow Policy That Manages a Marketing Campaign.
In this topic you define the email for the marketing campaign policy.
To define the email for the marketing campaign policy
Navigate to the Administration-Business Process screen, and then the Policies view.
In the Policies List, add a new record using values from the following table.
Field Value Name
Email for CD-ROM campaign
Workflow Object
Campaign Contact
Policy Group
CD-ROM Promotion
Duration
0
The Policy Group you define in this step is the group you created in Defining the Workflow Policy Group for the Marketing Campaign.
In the Conditions list, create a new name using values from the following table.
Field Value Condition Field
Name
Operation
=
Value
1st CD-ROM Promotion
In the Conditions list, define the Start Date using values from the following table.
Field Value Condition Field
Start Date
Operation
=
Value
(Enter the date where the campaign starts sending messages to the target audience.)
In the Conditions list, to define the Campaign Status, create a new record using values from the following table.
Field Value Condition Field
Campaign Status
Operation
=
Value
Launched
The Launched value starts the campaign.
Defining the Assign Non Respondents Policy
The policy that you define in this topic reassigns nonrespondents to a new campaign.
To define the assign non respondents policy
Navigate to the Administration-Business Process screen, and then the Policies view.
In the Policies List, add a new record using values from the following table.
Field Value Name
Non-Respondents of CD-ROM campaign
Workflow Object
Campaign Contact
Policy Group
CD-ROM Promotion
Duration
14
In the Conditions list, define the Name using values from the following table.
Field Value Condition Field
Name
Operation
=
Value
1st CD-ROM Promotion
In the Conditions list, define the Campaign Status using values from the following table.
Field Value Condition Field
Campaign Status
Operation
=
Value
Launched
In the Conditions list, define the Done Flag using values from the following table.
Field Value Condition Field
Done Flag
Operation
=
Value
N
Defining Logic That Calls the Assign Nonrespondents Policy
Setting the Done Flag to N identifies the activity for this recipient as requiring additional attention. If the Policy duration is 14 days, and if the Done Flag is N, then the policy runs in 14 days. Siebel CRM assigns recipients who do not reply to the first campaign to a new campaign after 14 days.
Configuring a Predefined Workflow Policy
This topic describes how to configure a predefined workflow policy.
Viewing Groups of Predefined Workflow Policies
You can view groups of predefined workflow policies. In this example, you view groups of predefined workflow policies for messaging.
To view groups of predefined workflow policies
In the Siebel client, navigate to the Administration-Business Process screen, and then the Policy Groups view.
In the Name column, choose Siebel Messaging.
Siebel CRM displays the messaging policies in the Policies list.
Configuring a Predefined Workflow Policy for Messaging
You can use a predefined workflow policy to display a message in a dialog box in the Siebel client.
To configure a predefined workflow policy for messaging
In the Siebel client, navigate to the Administration-Business Process screen, and then the Policy Groups view.
Choose Siebel Messaging in the Name column.
Locate the workflow policy you must use, such as Messaging Policy Send Screen Pop for Activity.
Set the Expiration field to NULL.
Run the Generate Triggers server component using values from the following table.
Parameter Value EXEC
True
Remove
True
For more information, see Configuring Database Triggers.
Run Generate Triggers again. This time set the Remove parameter to False.
Navigate to the Messages screen, and then the All Messages view.
Click New.
In the Last Name field, enter the name of the contact who receives the message.
In the Assigned To field, enter the name of the employee to whom this user is assigned.
In the Message field, type the text message that Siebel CRM must display in the dialog box.
Set the Alert Type field to Screen Alert.
Click the Message Alert Setup tab, and then make sure a corresponding entry exists for the message recipient and that Alert Type is set to Screen Alert.
If the message recipient is already defined, then do the following:
Click New.
Set the Last Name field to the same name you set in step 9.
Set the Alert Type field to Screen Alert.
Start a Workflow Monitor Agent server task for the workflow policy group you activated in step 5.
For more information, see Running a Workflow Policy with Workflow Monitor Agent.
Verify the configuration:
Define a test user when assigning the contact in step 9.
In a second client session, log in to the Siebel client as the test user.
In the first client session, insert a new activity for this user.
In the second client session, verify that Siebel CRM displays the dialog box and that it contains the message you previously entered in step 11 displays.
Identifying Objects That the Workflow Policy Must Modify
You might find that the predefined workflow policy objects do not reference the data that your business requires. This topic describes how to identify the objects that can provide this data. It uses account objects as an example.
To identify objects that the workflow policy must modify
In the Siebel client, navigate to the view that displays the business data that Siebel CRM must monitor.
For example, if Siebel CRM must monitor account activity, then navigate to the Accounts screen, Accounts List, and then the Activities view.
Choose the Help menu, and then the About View menu item.
The About View dialog box identifies the business object, business components, and applets that this view uses. For example, if Siebel CRM currently displays the Account Activities view, then this dialog box identifies Action as the business component that the Activities list uses.
In Siebel Tools, in the Object Explorer, click Business Component.
In the Business Components list, query the Name property for Action.
Note the value in the Table property.
In this example, the table name is S_EVT_ACT.
In the Object Explorer, click Business Object.
In the Business Objects list, query the Name property for Account.
In the Object Explorer, expand the Business Object tree, and then click Business Object Component.
In the Business Object Components list, query the Bus Comp property for Action, and then click the link in the Link Property.
The Source Field property is empty and the Destination Field property contains Account Id. The value in the Link property identifies the link that defines the relationship between the Account business component and the Action business component. This Link defines the relationship between the parent business component and the child business component through the Source field and the Destination field.
A Source Field property that is empty indicates that the join uses the ROW_ID column of the table that the Table property of the parent business component references. The Destination Field property identifies the field in the child business component that is a foreign key to the parent business component.
Click the link in the Child Business Component property.
Siebel Tools displays the Action business component in the Business Components list.
In the Object Explorer, expand the Business Component tree, and then click Field.
In the Fields list, choose the Account Id field, and then note the value in the Column property.
The Column property contains TARGET_OU_ID, which is the column in the table that the Account Id field references. You can use this information when you define the workflow policy component.
When you define a workflow policy component, you can use the table name (step 5) and column name (step 12) you previously noted.