BPFWorkflow

Siebel Business Process Framework: Workflow Guide
Version 8.1, Rev A July 2009
Copyright 2005, 2009 Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be errorfree. If you find any errors, please report them to us in writing. If this software or related documentation is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT RIGHTS. Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065. This software is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications which may create a risk of personal injury. If you use this software in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy and other measures to ensure the safe use of this software. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software in dangerous applications. The Programs may provide links to Web sites and access to content, products, and services from third parties. Oracle is not responsible for the availability of, or any content provided on, third-party Web sites. You bear all risks associated with the use of such content. If you choose to purchase any products or services from a third party, the relationship is directly between you and the third party. Oracle is not responsible for: (a) the quality of third-party products or services; or (b) fulfilling any of the terms of the agreement with the third party, including delivery of products or services and warranty obligations related to purchased products or services. Oracle is not responsible for any loss or damage of any sort that you may incur from dealing with any third party.
Contents
Siebel Business Process Framework: Workflow Guide 1
Chapter 1: Chapter 2:
Whats New in This Release Overview of Siebel Workflow

15
15
About Siebel Workflow
Business Requirements That Can Be Addressed by Managing a Business Process Overview of Technologies That Are Used to Automate a Business Process 16 Overview of Objects That Are Used with a Workflow Process 18 Scenario to Promote Timely Resolution of a Service Request 19 Viewing Example Workflow Processes 21
Overview of How a Workflow Process Is Developed
22
Chapter 3:
Architecture of a Workflow Process

25
About the Architecture of a Workflow Process
Development Architecture of a Workflow Process 26 Simulation Architecture of a Workflow Process 28 Deployment Architecture of a Workflow Process 30 Run-Time Architecture of a Workflow Process 31
How a Workflow Process Interacts with Other Siebel Components
36
Chapter 4:
Environment for Developing a Workflow Process

39
About the Object Hierarchy of a Workflow Process
Properties of an Object 41 Relations Between Object Types of a Workflow Process 42 Locating a Workflow Process in the Workflow Processes Object List Editor
43
About the Process Designer About the Process Property
44 47
49
Process Property and the Property Set 48 Arguments of the Step of a Workflow Process Multi Value Property Window 50 Process Properties That Are Predefined 54 Manipulating a Process Property 57
About the WF/Task Editor Toolbar
62
Siebel Business Process Framework: Workflow Guide Version 8.1, Rev A
Contents
Chapter 5:
Steps and Connectors of a Workflow Process

65
67 68
Overview of Workflow Process Steps
Adding a Step to a Workflow Process 66 Name of a Step in a Workflow Process or a Process Property How Properties Are Defined for a Step in a Workflow Process Sequence Number for a Step in a Workflow Process 68
Types of Steps of a Workflow Process

About About About About About About About About About About About the the the the the the the the the the the Start Step 69 Business Service Step 70 Decision Point 72 Sub Process Step 73 Siebel Operation Step 75 Task Step 84 User Interact Step 85 Wait Step 87 Stop Step 88 End Step 90 Workflow Connector 91
69
Defining a Decision Condition
92
95
Defining a Branch Connector 92 Defining a Decision Condition on a Branch Connector
Chapter 6:
Developing a Workflow Process

97 99
Roadmap for Developing a Workflow Process Process of Analyzing Business Requirements
Gathering Information for Planning a Workflow Process 99 Identifying Actions That a Business Process Performs 100 Identifying an Automation Solution 101
Process of Planning a Workflow Process
104
Determining the Mode of the Workflow Process 104 Determining How the Workflow Process Is Started 105 Determining Decision Logic of a Workflow Process 107 Determining Actions of a Workflow Process 109 Determining Error Handling 111 Examining Seed Workflow Processes 111 Determining Requirements for Managing the Development of Objects Addressing Other Business Requirements 113
112
Job Roles That Are Involved in Developing a Workflow Process
114
Contents
Chapter 7:
Process of Building a Workflow Process

115
116
Preparing Siebel Tools to Develop a Workflow Process Defining a Workflow Process 117
Exposing Object Types That Are Used to Develop a Workflow Process Reviewing Workflow Processes 117 Copying a Workflow Process 118 Modifying a Workflow Process 118 Revising a Workflow Process 119 Defining a New Workflow Process 120 Naming a Workflow Process 120 Externalizing Workflow Properties 120 Making a Workflow Process Editable 120 Deleting a Workflow Process 121
Diagramming a Workflow Process
122
123
Displaying the Label for a Connector 122 Adding or Removing a Point in a Connector
Defining a Process Property for a Workflow Process
124 126
Defining a Property for the Step of a Workflow Process
Chapter 8:
Options for Developing a Workflow Process

127
About the Workflow Mode Property
Types of Modes for a Workflow Process 127 Options for the Workflow Mode Property 129 Options for an Interactive Workflow Process 130 Options for a Long-Running Workflow Process 139 Workflow Persistence 141
Starting a Workflow Process
143
Starting a Workflow Process from a Workflow Policy 143 Starting a Workflow Process from a Run-Time Event 144 Starting a Workflow Process from a Business Service 147 Starting a Workflow Process from Another Workflow Process 149 Starting a Workflow Process Through the Workflow Process Manager 150 Starting a Workflow Process Through the Application Object Manager 152 Starting a Workflow Process Through a Script 152 Example of Starting a Workflow Process from a Custom Toolbar 154 Other Techniques for Starting a Workflow Process 156
About Events
157
Run-Time Event 157 About the User Event 161
Contents
Handling Errors
164
Using an Error Exception Connector to Handle Errors 164 Using a Stop Step to Handle Errors 168 Error Handling with an Error-Workflow Process 168 Recovery for a Workflow Process That Has Failed 171
Using Batch Processing
172 175
175
Defining a Workflow Process for a Multilingual Environment
Defining a Workflow Process to Function in a Multilingual Environment Expressions in a Multilingual Environment 176 Wait Step and Global Time Calculations 176 Local Code Parameter and Data Format 177
Chapter 9:
Manipulating Data
179 182
Accessing Data From a Run-Time Event From a Workflow Process Passing Data to and from a Workflow Process
Passing an Input to a Workflow Process 182 Passing an Output From a Workflow Process 183 Passing a Parameter from a Workflow Process to a Global Variable 183 Passing a Constant from a Workflow Policy Action into a Workflow Process Examples of Scripts That Pass Data to and from a Workflow Process 184
183
Timestamp Usage
188 188
189
Decision Conditions for a Workflow Process
Fields in the Compose Condition Criteria Dialog Box Expressions in the Expression Builder 190
Chapter 10: Testing a Workflow Process

About the Testing Tools 197
Validate Tool 197 Process Simulator 198 Business Service Simulator Event Logs 201
201
Process of Testing a Workflow
202
203
Validating the Workflow Process 202 Preparing to Use the Process Simulator Using the Process Simulator 204 Verifying Functionality 206
Troubleshooting Validation and Simulation Problems
208
Contents
Chapter 11: Administering a Workflow Process

Process of Deploying a Workflow Process
Preparing the Run-Time Environment Publishing a Workflow Process 216 Activating a Workflow Process 216 Developing a Migration Strategy 218 Migrating a Workflow Process 223 212
211
Process of Migrating a Workflow Process
218
Process of Administering a Workflow Process
227
Viewing Run-Time Instances of a Workflow Process 227 Using the Workflow Instance Admin View 228 Stopping an Instance of a Workflow Process 229 Deactivating the Instance of a Workflow Process 230 Removing a Workflow Process From the Run-Time Environment
231
Monitoring a Workflow Process
233
Overview of Monitoring and Troubleshooting Tools 233 Setting Monitoring Levels for a Workflow Process 233 Setting Monitoring Levels for Tracing and the Event Log 236 Defining Metrics for a Workflow Process 237 Capturing Data with Siebel Application Response Measurement Recording Behavior with the Siebel Flight Data Recorder 239
238
Diagnosing a Workflow Process That Has Failed
240
240
Diagnosing a Workflow Process That Has Failed in a Production Environment Troubleshooting Execution Problems with a Workflow Process 243 About the Workflow Recovery Manager 246
About Upgrading a Workflow Process
253
Chapter 12: Examples of Defining a Workflow Process

Example of Defining a Workflow Process That Creates an Activity for a Sales Representative 255
Defining the Workflow Process 256 Testing the Workflow Process 262 Deploying and Verifying the Workflow Process
263
Example of Defining a Workflow Process That Traverses a Record Set to Close Service Requests That Are Obsolete 264 Example of Defining a Workflow Process That Attaches an Activity Plan to an Opportunity 281 Example of Defining a Workflow Process That Manages Research Activities for a Service Request 288
Siebel Business Process Framework: Workflow Guide Version 8.1, Rev A 7
Contents
Example of Defining a Workflow Process That Manages Creation of a Service Request 292 Example of Defining a Workflow Process That Manages Creation of a Service Request then Navigates the User 301
Chapter 13: Examples of Using a Business Service with a Workflow Process

Examples of Using the Server Requests Business Service 305
Example of Using the Server Requests Business Service to Start a Workflow Process from a Script 305 Example of Using the Server Requests Business Service to Call EIM 306
Examples of Using the Outbound Communications Manager Business Service
309
Example of Defining a Substitution when Using the Outbound Communications Manager 309 Example of Using the Outbound Communications Manager to Send an Email to the Owner of a Product Defect 310
Example of Externalizing Properties when Using a Business Service
316
Chapter 14: Defining a Custom Workflow Policy

About Workflow Policies 323
323 Overview of Workflow Policy Objects Structure of a Workflow Policy 327 Sequence of a Workflow Policy 330 Hierarchy of Workflow Policy Objects
331
Process of Planning a Workflow Policy
332
Planning a Workflow Policy Group 332 Planning a Workflow Policy 333 Planning Objects to Monitor with a Workflow Policy 334 Planning the Workflow Policy and Workflow Policy Conditions 334 Planning the Workflow Policy Action 335 Examining Workflow Policies and Workflow Policy Programs That Are Predefined Planning a Test and Migration Strategy for a Workflow Policy 336 Examples of Planning a Workflow Policy 336
335
Process of Defining a Workflow Policy

Defining a Workflow Policy Group Defining a Workflow Policy Action Defining a Workflow Policy 346 340 341
340
Examples of Defining Workflow Policy Configurations

Examples of Defining a Workflow Policy Action Examples of Defining a Workflow Policy 357 349
349
Contents
Customizing Workflow Policy Objects
360
361
Display of Workflow Policy Objects 360 Defining a Customized Workflow Policy Object
Conditions for a Workflow Policy
370
Standard Comparisons in the Conditions List 370 A Field That Is Not Known Is Interpreted as Null 371 Specialized Comparisons in the Conditions List 371 Date Calculations in the Conditions List 375
Chapter 15: Using a Predefined Workflow Policy

Configuring a Predefined Workflow Policy 377
378 Configuring a Predefined Workflow Policy for Messaging 377 Identifying the Source Table When Modifying an Existing Workflow Policy
Types of Workflow Policy Programs That Are Predefined
381 388 393

394
Examples of Workflow Policy Programs That Are Predefined
Workflow Policy Programs that Are Predefined for Siebel Marketing
Example of Developing a Workflow Policy That Manages a Marketing Campaign
Chapter 16: Administering a Workflow Policy

Administering a Workflow Policy 401
Confirming the Installation of Workflow Policies 401 Administering Database Triggers on the Workflow Policy Server 402 Administering Email Manager and Page Manager 409 Executing a Workflow Policy with the Workflow Action Agent 415 Executing a Workflow Policy with Workflow Monitor Agent 417 Defining a Workflow Policy to Run in Batch Mode 428 Moving a Workflow Policy to a Different Group 431 Expiring a Workflow Policy 432 Deleting a Workflow Policy That Is Obsolete 434 Tracing and Reporting a Workflow Policy 436 Guidelines for Converting a Workflow Policy to a Workflow Process 439
Testing, Troubleshooting, and Migrating a Workflow Policy

Testing a Workflow Policy 440 Troubleshooting a Workflow Policy 442 Migrating Workflow Policies to the Production Environment
440
443
Appendix A: Reference Materials for Siebel Workflow

Properties of Siebel Workflow 445
445 Properties of a Workflow Process
Contents
Properties of the Step and Connector of a Workflow Process Fields and Arguments of Process Properties 462
450
Properties of Workflow Policies

Properties Properties Properties Properties Properties Properties of of of of of of the the the the the the Workflow Workflow Workflow Workflow Workflow Workflow Policy Policy Policy Policy Policy Policy
470
Column 470 Object 471 Component 472 Component Column Program 475 Program Argument
474 476
Predefined Business Services
482
Server Requests Business Service 482 Workflow User Event Service Business Service 486 Workflow Utilities Business Service 487 Workflow Admin Service Business Service 489 Other Business Services That Are Used with a Workflow Process
491
Appendix B: Glossary
Siebel Workflow Glossary 495
Index
10
Whats New in This Release
Whats New in Oracles Siebel Business Process Framework: Workflow Guide, Version Version 8.1, Rev A
Table 1 lists changes in this version of the documentation to support release Version 8.1, Rev A of the software.
Table 1. Topic
Documentation Changes in Siebel Business Process Framework: Workflow Guide, Version 8.1 Description Describes a procedure for passing a user-defined process property to an error-workflow process. A process property can be used as a substitution variable within an expression. You can copy a value to a record being updated or inserted in a subprocess by defining a process property in the subprocess and assigning the value to it. An expression for a Search Specification can be defined with a compound expression and substitution from a process property or field. You can update a field in a nonprimary business component. You can use a Siebel operation step to update a process property. The Upsert Operation provides a way to perform either an insert or update operation, based on whether a record exists in the database. You can implement branching declaratively. For example, with multiple branches that emanate from a single step in a workflow process. In some cases, you can achieve the same result through a script. For example, with a script on a business service. Describes example scenarios for using a workflow policy compared with a run-time event. You can use the Siebel client to identify predefined workflow processes that appear in the Action Set Field of the Administration-Runtime Events screen.
Passing a Process Property to an Error-Workflow Process on page 58 Referencing a Process Property on page 60 Copying a Value from a Parent Workflow Process to a Sub Workflow Process on page 74 Example of Defining a Siebel Operation Search Specification on page 77 Updating the Field of a Nonprimary Business Component on page 78 Updating a Process Property with a Siebel Operation Step on page 80 How the Upsert Operation Is Used with the Siebel Operation Step on page 82 Comparison of Branching Declaratively to Programming with a Script on page 93
Comparison of Using a Run-Time Event to a Using a Workflow Policy on page 145 Identifying A Predefined Workflow Process That Is Started by a RunTime Event on page 147
11
Table 1. Topic
Documentation Changes in Siebel Business Process Framework: Workflow Guide, Version 8.1 Description Key Based Enabled can be defined for the Workflow Process Manager to assist with routing and recovery. You can define an error exception connector to handle an update conflict that occurs when multiple attempts are made to write to the same record at the same time. You can use the Repeating Component Request feature with the workflow process to schedule the workflow to execute at a predetermined time. Use the Workflow Process Batch Manager server component when you must run the workflow process for every record of a particular business component. You can use the Run Workflow Process program to pass a constant from a workflow policy action into a workflow process. Describes the Watch window, including how to use it within the context of an example. Describes Process Simulator usage. You can define a workflow process to send a notification email to mobile users who are not synchronized. Describes how a workflow process can be deployed as a Web service. You can use the Workflow Recovery Manager to recover an interrupted workflow process. Provides a detailed example that describes how to traverse a record set.
Key Based Routing with Workflow Process Manager on page 150 Defining an Error Exception Connector to Handle an Update Conflict on page 166 Usage of the Repeating Component Request on page 173 Usage of the Workflow Process Batch Manager with Primary and Nonprimary Business Components on page 173 Passing a Constant from a Workflow Policy Action into a Workflow Process on page 183 Using the Watch Window on page 199 Using the Process Simulator on page 204 Notification to Mobile Users Who Are Not Synchronized on page 214 Deploying a Workflow Process as a Web Service on page 215 About the Workflow Recovery Manager on page 246 Example of Defining a Workflow Process That Traverses a Record Set to Close Service Requests That Are Obsolete on page 264 Example of Using the Server Requests Business Service to Start a Workflow Process from a Script on page 305 Example of Using the Server Requests Business Service to Call EIM on page 306
You can use the Server Requests business service to start a workflow process from a script and to pass field values to process properties. You can use the Server Requests business service to call EIM.
12
Table 1. Topic
Documentation Changes in Siebel Business Process Framework: Workflow Guide, Version 8.1 Description You can define a substitution variable when calling the Outbound Communications Manager business service from a workflow process. You can use the Outbound Communications Manager to send an email to the owner of a product defect.
Example of Defining a Substitution when Using the Outbound Communications Manager on page 309 Example of Using the Outbound Communications Manager to Send an Email to the Owner of a Product Defect on page 310 Example of Externalizing Properties when Using a Business Service on page 316 Table Monitoring with a Workflow Policy on page 326
Removed references to Universal Application Network (UAN), which is no longer supported. Workflow Policies can monitor only Siebel tables. Do not use a workflow policy to monitor database tables that are external to the Siebel application, or to monitor certain Enterprise Integration Manager (EIM) tables. You can use a predefined messaging policy to display a message in a pop-up dialog box in the Siebel client. Workflow Manager can be defined to send an email message to an email address that is stored in a column other than S_EMPLOYEE.EMAIL_ADDR. Procedure removed. Workflow Monitor Agent can no longer be run from the Siebel client. You must start Workflow Monitor Agent from the Server Manager command line interface. Provides reference information for the properties of the various step types that are used in Siebel Workflow.
Configuring a Predefined Workflow Policy for Messaging on page 377 How an Email Can Be Sent to an Email Address That is Held in a Custom Field on page 384 Defining a New Workflow Monitor Agent Server Component on page 419 Properties of the Step and Connector of a Workflow Process on page 450
Additional Changes
Version 8.1, Rev A of Siebel Business Process Framework: Workflow Guide includes style changes to the content, such as topic organization and heading arrangement, and revisions to procedures. NOTE: The Siebel Bookshelf is available on Oracle Technology Network (OTN) and Oracle E-Delivery. It can also be installed locally on your intranet or on a network location.
13
14
Overview of Siebel Workflow
This chapter describes a conceptual overview of Oracles Siebel Workflow. It includes the following topics: About Siebel Workflow on page 15 Overview of How a Workflow Process Is Developed on page 22
About Siebel Workflow

Siebel Workflow is a customizable business application that allows you to define, manage, and enforce your business processes, thereby establishing process automation within Oracles Siebel applications. Siebel Workflow orchestrates the various Siebel process automation technologies. A workflow process graphically sequences a series of automation steps that support a business process, and it specifies inputs and outputs for individual steps and for the workflow process as a whole. A workflow process can be simple, such as entering a product order, or complex, such as managing a call center workflow. A complex workflow process can include multiple subprocesses. Challenges you can address when using Siebel Workflow to manage a business process in your organization include: Automating the escalation of events and notification of appropriate Siebel Workflow parties Routing and assigning work Processing work Enforcing authorization and transition rules
Business Requirements That Can Be Addressed by Managing a Business Process

In theory, a business is managed according to the business processes that enforce efficiency, quality of service, adherence to contractual agreements, and profitability. The following are some examples of these business processes: Allow objectives for response time to be met for customer callbacks and open service requests Define review policies for important processes, such as contracts, quotes, or product shipments Monitor service requests or opportunities over time
In practice, the benefits of a business process are often not realized because the business process is not consistently enforced. This situation can exist due to the large number of business processes that exist in the business environment, or because of the dynamic nature of the information being monitored.
15
Overview of Siebel Workflow About Siebel Workflow
Managing important events is central to the enforcement of a business process. Workflow Management is the timely management of an event in order to allow proper handling. For example, a service department uses procedures for managing an open service request or for making sure a measurable response time is met. A workflow process can increase the visibility of these business processes within an organization and check that they are handled correctly. A service department uses business rules that match the requirements of the business: Standards for processing calls. For example, when a Severity 1 call is assigned, the new owner is automatically paged. Contracted service agreements that must be adhered to. For example, a customer can purchase a support agreement that guarantees a callback within two hours and problem resolution within four hours.
A sales department uses business rules to enforce the required practices of the business: Discount authority. If a sales representative quotes a discount that exceeds the maximum discount allowed, then it requires the approval of the district sales manager or VP of Sales. Pipeline management. Each sales representative manages their pipeline in order to promote sufficient levels of prospects at each stage of the sales cycle. If an area of the pipeline requires attention, then the representative or manager must be alerted. Forecasting accuracy. Opportunities that are forecasted but never closed or forecasts that include wide discrepancies with the actual revenue must be flagged.
Overview of Technologies That Are Used to Automate a Business Process

Siebel Workflow brings together Workflow Processes and other repository configuration objects, including the Workflow Policies module, to establish a comprehensive workflow design. Some of the technologies for automating a business process that are available to a Siebel application are described briefly in this topic. While each of these technologies provide specific functionality to automate a business process in the Siebel application, Workflow Processes can orchestrate many of the services that the technologies perform. A workflow process orchestrates services by directly calling each technology, or by interacting with other technologies through the Siebel event model.
16
Table 2 describes automation technologies.
Table 2.
Automation Technologies Description Allows you to define business processes for your company by using a familiar flowcharting interface. Consists of one or more process steps, such as a start step, subprocess step, decision point, and task. Workflow Processes is the key technology behind building business processes in the Siebel application. Allows you to define workflow policy conditions and actions that can start a workflow process. If workflow policy conditions are met, then the policy action executes the relevant workflow process. A workflow policy generates an event based on a database operation. A workflow policy is effective for performing a simple action, such as sending email, or generating an activity or assignment. Allows you to define a user interface with multiple step, interactive operations that can include branching and decision logic to guide an end user through Siebel Task UI execution. Allows navigation backward and forward within task UI execution, and allows a task UI to pause and resume. For more information, see Siebel Business Process Framework: Task UI Guide. Expresses rules to assign records to people. Allows assignment of records based on skill, workload, and availability. Supports ownership transition within a business process. For more information, see Siebel Assignment Manager Administration Guide. Guides the end user through data entry activities. Effective for call scripting and includes basic support for transaction level commits. For more information, see Siebel SmartScript Administration Guide. Provides a predefined series of steps to be performed. Effective for handling asynchronous and offline work. For more information on Activity Template, see Siebel Applications Administration Guide. Restricts transition of record status based on a current value and the position of the user. Can also enforce directional progression of status. For example, opportunities move forward but not backward through a pipeline. For more information on the State Model, see Siebel Applications Administration Guide.
Automation Technology Workflow Process
Workflow Policy
Siebel Task UI
Assignment Manager
SmartScript
Activity Template
State Model
17
Overview of Objects That Are Used with a Workflow Process

To plan for building a workflow process, it is important to understand the basic objects that can be defined. With Siebel Workflow, the run-time engine manages process flow, application flow, and integration flow. Basic objects such as a start step, decision point, Siebel operation step, and connectors are available to build your workflow process. Some of the basic objects for a workflow process are illustrated in Figure 1.
Figure 1.
Basic Objects of a Workflow Process
The basic objects of a workflow process include:
Workflow Events. A workflow process can be started from a run-time event in the Siebel application, a workflow policy, or through a script. An event can pass context from the caller, for example a user session, to a workflow process by using a row ID. For more information, see Determining How the Workflow Process Is Started on page 105. Workflow Rules. A workflow decision rule is a rule that guides the flow of control within the workflow process. It can be based on business component data or on a local variable in the workflow process that is known as a process property. A rule expression is defined using Siebel Query Language. For more information, see Determining Decision Logic of a Workflow Process on page 107. Workflow Actions. A workflow action is an action in a workflow process that performs some form of data manipulation, where data is used as input, a transformation occurs or data is examined, then data is produced as output. A workflow action can perform an operation on a database record or call a business service. For more information, see Determining Actions of a Workflow Process on page 109.
18
Scenario to Promote Timely Resolution of a Service Request

This topic gives one example of how a workflow process can be used to resolve a service request in a timely fashion. You might use workflow processes differently, depending on your business model. This scenario demonstrates how basic concepts for a workflow process can be used to automate a business process. Prior to implementing Siebel Call Center, a service manager for a high volume service agency felt her organization was unable to resolve many customer issues in a timely manner. To better track and manage service requests, the service manager decides to implement the service request module in order to automate the service request management process. The goal is to meet a Service Level Agreement commitment by making sure newly logged service requests (SRs) are resolved within a specific amount of time. The service manager requires the SRs to be assigned by the Siebel application to the most appropriate representative based on the availability and skill of the representative. If the SR requires immediate attention, then the owner of the SR is notified. The developer uses the Process Designer in Siebel Tools to define the business process for a new service request. Figure 2 illustrates how the process is displayed in the Process Designer. The diagram includes the steps and decision point that are involved when a new service request comes into the organization. For information on how this workflow fits within the development architecture, see Overview of How a Workflow Process Is Developed on page 22.
Figure 2.
New Service Request Workflow Process in the Process Designer
19
If an SR is logged, then the workflow process is started. The workflow calls Siebel Assignment Manager to assign the SR to the service representative who is available and possesses the skills required to resolve the SR. Based on the severity of the SR, the workflow can use the Siebel Communications Server to send email notification to the representative. Automating this process helps the company achieve faster turnaround time in order to resolve SRs and to meet service commitments.
Steps That Are Used in the Scenario

Table 3 describes each step that is used in the service request scenario.
Table 3.
Steps in the New Service Request Scenario Step Type Start Description Every workflow process contains a start step that is used to start the process. The condition that starts a workflow is defined on the connector that emanates out of the start step. The workflow is started by the creation of a new service request. The service request is assigned to the appropriate service representative, based on assignment rules that are executed in the subprocess. The decision point uses the severity of the service request to determine the next step that is executed: Critical, High, or Medium. If the priority for the service request is critical, then the business service step sends an email to the assigned service representative. The service request priority is set to High. The sub status is set to Assigned. If the email is undeliverable or if the Send Email business service step returns some other error, then an error exception connector is executed. An activity is generated to manage the error. The service request priority is set to Very High and the substatus is set to Dispatch. The workflow process ends.
Step Name Start
Open SR Assign Service Request Severity?
Branch Connector Sub Process
Decision Point
Send Email
Business Service
Set Priority to High Assign Substatus Email Error
Siebel Operation Siebel Operation Error Exception Connector Siebel Operation Siebel Operation End
Generate Error Activity Set Priority Very High then Dispatch End
20
Viewing Example Workflow Processes

To examine examples that ground the concepts discussed in this chapter, see Chapter 12, Examples of Defining a Workflow Process. There are also a number of predefined workflow processes you can peruse. For more information, see Examining Seed Workflow Processes on page 111. You can also view example workflow processes.
To view example workflow processes 1 2 3

In Siebel Tools, navigate to the Workflow Processes Object List Editor (OBLE). Query the Comments property for *Sample*. Right-click a record in the Workflow Processes OBLE, then choose Edit Workflow Process.
21
Overview of Siebel Workflow Overview of How a Workflow Process Is Developed
Overview of How a Workflow Process Is Developed

Figure 3 illustrates an overview of components that are involved when you develop a workflow process.
Figure 3.
Overview of Workflow Development
Components involved when developing a workflow process include:
Siebel Tools. Siebel Tools provides an integrated development environment for configuring various aspects of a Siebel application. The Process Designer, which resides in Siebel Tools, is used to build a workflow process. These modifications are saved in the Siebel Repository File (SRF). Siebel Tools provides the design interface and the debugging interface to Siebel Workflow. After a workflow process is designed and tested, it is written to repository tables for deployment from the administrative interface in the Siebel client.
2 3 4
Siebel Server. The Object Manager in the Siebel Server manages the workflow process components that automate business policies. Database Server. A relational database provides the set of data that Workflow Policies act against. Siebel Client. Workflow processes and workflow policies are administered through the Administration-Business Process screen in the Siebel client.
For more information, see Chapter 3, Architecture of a Workflow Process. For a description of the Siebel Server architecture, see Siebel System Administration Guide.
22
Workflow Processes allows you to define a business process for your company by using the Process Designer in Siebel Tools. Hosting the Process Designer in Siebel Tools provides an integrated development environment in order to define the workflow process, along with other Siebel objects. This environment allows a top down development framework for building business logic, beginning with the creation of a workflow, then providing pluggable services and data objects that make the workflow executable. You define a workflow process that consists of process steps, such as a start step, decision point, subprocess step, or business service step. Work can be finished with a predefined business service or a custom business service. A predefined action can include an update to the Siebel database, a notification, such as an email or page, an integration message to an external system, or a call to a server task. A custom action can be defined by using Siebel VB or Siebel eScript. For more information, see Chapter 6, Developing a Workflow Process. A workflow process is administered through the Administration-Business Process screen in the Siebel client. For more information, see Chapter 11, Administering a Workflow Process.
23
24
Architecture of a Workflow Process
This chapter describes architectures that are used with Siebel Workflow. It includes the following topics: About the Architecture of a Workflow Process on page 25 How a Workflow Process Interacts with Other Siebel Components on page 36
Siebel Workflow is an interactive software tool that allows you to automate how your organization handles workflow processes. The basic model for a workflow process is similar to the process model that an organization uses in sales, marketing, and service departments that determine business workflow. You can use a workflow process to promote consistency and adherence to a business process through the automatic enforcement of business policies and procedures.
About the Architecture of a Workflow Process

This topic describes the workflow process architecture. It includes the following topics: Development Architecture of a Workflow Process on page 26 Simulation Architecture of a Workflow Process on page 28 Deployment Architecture of a Workflow Process on page 30 Run-Time Architecture of a Workflow Process on page 31
The following topics also include information of an architectural nature: About the Object Hierarchy of a Workflow Process on page 39 Overview of Workflow Policy Objects on page 323 Sequence of a Workflow Policy on page 330
25
Architecture of a Workflow Process About the Architecture of a Workflow Process
Development Architecture of a Workflow Process

Figure 4 illustrates the development architecture of a workflow process.
Figure 4.
Development Architecture of a Workflow Process
The following architectural components are used to develop a workflow process:
Siebel Tools. The repository object for a workflow process is a top level object in the Object Explorer of Siebel Tools. You use the Object List Editor (OBLE) to define the object definition for a workflow process. A workflow process belongs to a project. There is independent versioning of a workflow process in Siebel Tools and in the Siebel client. You use the Process Designer in Siebel Tools to develop a workflow process. In the Process Designer, you use process properties to define a workflow, or alternatively, you can enter data through unbounded picklists. In the Process Designer, configuration data is available, but runtime data is not available.
Repository Tables. A workflow process that is under development is stored in the Siebel repository tables and run-time tables. When you edit the workflow in Siebel Tools, it is stored in the repository tables. When you deploy a workflow, it is also inserted into the run-time tables. To deploy a workflow, you publish, then activate it. XML file. A workflow process can be exported as an XML file. SIF File. A workflow process can be exported as a sif file (Siebel archive file).
3 4
26
You can also use Application Deployment Manager (ADM) to migrate workflow processes from one Siebel environment to another. For more information, see: Migration with Application Deployment Manager on page 219 Overview of How a Workflow Process Is Developed on page 22
Functional View of Developing a Workflow Process

Figure 5 illustrates a typical approach for developing a workflow process.
Figure 5.
Typical Approach to Developing a Workflow Process
This approach outlines activities typically performed when a workflow process is developed:
Define. Siebel Tools is used to define the workflow process. When defining a workflow process, you define the object definition for the workflow process, define process properties, add steps and connectors, and so forth.
Save. The workflow process is frequently saved to the local database.
27
3 4
Test. The Siebel client is used to test the workflow process. Debug. Siebel Tools, the Siebel client, and the local master or test database are used to publish, activate, and debug the workflow process. The workflow is checked out from the repository into the local database, where it is modified and debugged locally before checking in to the master repository. Debugging against a server or test database instead of debugging locally allows the Workflow Engine to access server components, such as the Server Request Broker. During the development effort, work that you can optionally perform in Siebel Tools include:

Check the workflow process into and out of your master database. Export the workflow process to an XML file for backup purposes, or import the workflow process from an XML file to restore it.
Verify. To verify that the workflow process implements the functionality described during the planning phase, the workflow process is run from the Siebel client by using the local master or test database. Migrate. The workflow process is migrated from the master database to the staging or production database.
Simulation Architecture of a Workflow Process

After you define a workflow process, you can test it by using the Process Simulator. Testing your workflow before migrating it to the production environment verifies that the resulting actions are accurate and useful, and that the results meet your business requirements.
28
Figure 6 illustrates the architecture to simulate a workflow process.
Figure 6.
Architecture to Simulate a Workflow Process
Architectural components to simulate a workflow process include:
1 2
The Process Simulator accesses object definitions that are part of the workflow process or that are referenced by the workflow process. Depending on how the workflow is defined, user data in the run-time database, such as data that resides in various fields of an opportunity, is accessed or manipulated during the simulation.
If the workflow process is run from the Process Simulator, then it runs in the application object manager. The workflow can be started in the application object manager or in a server session of the Workflow Process Manager, depending on specific parameters. For more information, see About the Testing Tools on page 197.
29
Deployment Architecture of a Workflow Process

After you define and test a workflow process, it is deployed. Deploying includes performing the following work:
Publishing. Reading object definitions for a workflow process that exist in the Siebel repository tables, then writing those definitions, along with deployment parameters, into the run-time tables. Activating. Making the workflow process available for use in the Siebel client.
Figure 7 illustrates the relationship between Siebel Tools and the Siebel client when deploying a workflow process.
Figure 7.
Architecture to Deploy a Workflow Process
The following process is used to deploy a workflow process:
1 2 3 4
The workflow process is marked Completed for deployment. The workflow process is read from the repository. When activated, the workflow process is written to the run-time tables. Some parameters of the deployed workflow process can be modified in the Siebel client.
30
To deploy a workflow process, it is not necessary to compile the SRF, nor is a merge required. Workflow components and definitions are defined in Siebel Tools and are stored in the repository that is used by Siebel Tools. Before you can run a workflow as a server task or from the Siebel client, you must first publish the workflow from Siebel Tools, then activate the workflow from the Siebel client. If you use Publish/Activate in Siebel Tools rather than Publish, then it is not necessary to separately activate the workflow in the Siebel client.
Run-Time Architecture of a Workflow Process

This topic includes the following topics: Overview of the Run-Time Architecture of a Workflow Process on page 31 Workflow Process Manager on page 32 Modes of a Workflow Process on page 35 How a Workflow Process Is Started on page 35 Administration and Monitoring of a Workflow Process on page 35
Overview of the Run-Time Architecture of a Workflow Process

The run-time architecture for Siebel Workflow is based on the Siebel Object Manager layer and the server infrastructure layer of the architecture for Siebel Business applications. The run-time environment is available both as a business service and as a server component. The following modes are used to start and resume a workflow process: Local Synchronous Remote Synchronous Remote Asynchronous
31
Figure 8 illustrates the run-time architecture for a workflow process.
Figure 8.
Run-Time Architecture for a Workflow Process
Workflow Process Manager

The Workflow Process Manager (WfProcMgr) is a server component that uses the Siebel Object Manager framework and runs a workflow process as a business service. The Workflow Process Manager, which hosts the Business Object layer and the Data Object layer provides the ability to run multiple object managers and multiple server tasks for each object manager. The term Workflow Process Manager refers to both the Workflow Engine and the workflow server components. The Workflow Process Manager is in an Online status it is considered active and can receive and process requests. The Workflow Process Manager is inactive in other statuses, such as Shutdown and Offline. In such cases, requests to the Workflow Process Manager and Workflow Process Batch Manager (WfProcBatchMgr) server components cannot be processed. For example, if a request is saved to the database, and if the request is submitted in DirectDB, then the request can be submitted later when the Workflow Process Manager comes back online. Otherwise, the request is lost. For more information, see Starting a Workflow Process Through the Workflow Process Manager on page 150.
How Siebel Workflow is Run as a Business Service Execution for Siebel Workflow in an application object manager is started as a business service. The Workflow Process Manager business service and the Workflow Process Manager (Server Request) business service are referred to collectively as the Workflow Engine. As a business service, the Workflow Engine uses input arguments and returns output arguments.
32
Table 4 describes how the business service determines where the workflow process is run.
Table 4.
How the Business Service Determines Where the Workflow Process Is Run Location Where Workflow Process Is Run The object manager of the application that is called. The Workflow Process Manager server component.
Business Service Workflow Process Manager Workflow Process Manager (Server Request)
How Siebel Workflow is Run in the Workflow Process Manager Server Component A workflow process can be executed in the background by using a Workflow Process Manager server component that is configured and optimized to run the Workflow Process Manager business service. The Workflow Process Manager server component acts as the object manager to run the workflow process, including application logic within the workflow process. The Workflow Process Manager accepts the process name in the following ways: Through the Process Name component parameter. For example, when starting a server task from Server Manager or (Repeating) Server Component Requests. Through the Encoded Args component parameter. For example, when a request is submitted from the Workflow Monitor Agent business service or the Server Requests business service.
If a workflow policy starts a workflow process, then the Workflow Monitor Agent typically uses Encoded Input Arguments to pass input arguments to the Workflow Process Manager. However, setting Encoded Input Arguments in the Component Request Parameters applet fails because it is not in a format that can be recognized by the Workflow Process Manager server component.
33
Components in the Workflow Management Server Component Group Table 5 describes server components that are used in the Workflow Management server component group.
Table 5.
Components in the Workflow Management Server Component Group Alias WfProcMgr Description The following functionality is provided by the Workflow Process Manager and Workflow Process Batch Manager server components: Acts as the application object manager to run workflows Are specialized server components configured and tuned to run workflow processes Similar to server components, provides a multi threaded environment
Server Component Workflow Process Manager Workflow Process Batch Manager
WfProcBatchMgr
Workflow Monitor Agent Workflow Action Agent Workflow Recovery Manager
WorkMon WorkActn
Executes and monitors workflow policies, then executes actions when the conditions of a workflow policy are met. Process requests are logged in the action request table, S_ESCL_ACTN_REQ, for a policy group and calls actions that are linked with the workflow policy that is being processed. Polls the Workflow Engine to check for instances of workflow processes that are running on the server. Recovers failed instances and resumes instances that are waiting beyond a due date. For more information, see About the Workflow Recovery Manager on page 246. The following functionality is provided by the Generate Triggers component: Allows you to define database triggers that Workflow Policies uses to identify records that match the conditions of a workflow policy Must be rerun when a new policy is defined or deleted, and when an existing policy is updated Can be run from either the Server Manager graphical user interface, or through a command line interface
WfRecvMgr
Generate Triggers
GenTrig
34
Modes of a Workflow Process

The following modes of a workflow process characterize run-time behavior: Service Flow. A workflow process that executes a set of operations upon calling an event. Interactive Flow. A workflow process that assists the end user in navigating across Siebel views. Long-Running Flow. A persistent workflow process that can last for hours, days, or months. 7.0 Flow. A workflow process that provides backward compatibility for a workflow that was defined earlier than version 7.7.
The mode is set through the Workflow Mode property in the Workflow Processes OBLE in Siebel Tools. For more information, see Types of Modes for a Workflow Process on page 127.
How a Workflow Process Is Started

A workflow process can be started from an event in the Siebel application or from an external system. The ways that a workflow process can be started within the Siebel application include: From a workflow policy From an event, such as an insert of a record or a button click By a server component
This book describes how to start a workflow process through these mechanisms. For more information, see Starting a Workflow Process on page 143.
Administration and Monitoring of a Workflow Process

You can use the Administration-Business Process views in the Siebel client to administer and monitor a workflow process. The following work that can be performed in these views: Stop a workflow process Delete a workflow process instance Purge a workflow process instance from the database Monitor a workflow process that is running Recover a workflow process that is interrupted
For more information, see Process of Administering a Workflow Process on page 227.
35
Architecture of a Workflow Process How a Workflow Process Interacts with Other Siebel Components
How a Workflow Process Interacts with Other Siebel Components

This topic describes how Siebel Workflow interacts some other Siebel components.
Siebel Server Components

The Workflow Engine interacts with other server components through the Server Request Broker. Working as a business service, the Workflow Engine calls server components. To call a server component that is exposed as a specialized service, the Workflow Engine calls the signature for the service. For example, to send an email, the Workflow Engine calls the Communications Server as the Outbound Communications Manager business service. To assign an object to a user, it calls the Assignment Manager component as the Synchronous Assignment Manager Requests business service. To call a server component that is not exposed as a specialized service, the Workflow Engine uses the predefined Server Requests business service. This business service sends a generic request to the Server Request Broker. For more information, see Server Requests Business Service on page 482.
Server Request Broker

The Workflow Engine sends a request to the Server Request Broker, synchronously or asynchronously, and the Server Request Broker brokers the request to the appropriate component. The following work is performed: Sending asynchronous messages from an interactive server component to the Workflow Engine Communicating, synchronously and asynchronously, between the Workflow Engine and batch components Scheduling repeated server tasks that are executed periodically in the Workflow Engine
The Server Request Broker also performs load balancing. If the Server Request Broker receives a request, then it routes the request to the server component in the current server. For a workflow process, if the component is not available in the current server, then the Server Request Broker sends it to other servers on a round robin basis where the Workflow Process Manager component is activated. A workflow process also uses Server Request Broker to resume a waiting workflow process. The Server Request Broker queries a database table on a regular basis in order to identify server tasks that must be resumed. For more information, see Server Requests Business Service on page 482, and Siebel System Administration Guide.
36
Personalization Engine
The Personalization engine handles run-time events, such as application events, applet events, and business component events. A workflow process handles run-time events through integration with the Personalization engine. A workflow started or resumed by a run-time event registers itself with the Personalization engine when the process is activated. If a run-time event occurs in a user session, then the Personalization engine calls Siebel Workflow in the local object manager.
Inbox
The Inbox is a single screen in Siebel Business Applications that displays approval and notification items and instances for Siebel Task UI that are assigned to an end user regardless of the screen where the item originated. The Inbox displays enough detailed information about the item so that the end user can act on the item from the Inbox and not be required to navigate to other screens. For more information, see Siebel Applications Administration Guide.
Siebel Task UI
Siebel Task UI allows you to define a user interface that is similar to a wizard, with multiple step, interactive operations that can include branching and decision logic to guide an end user through the execution of a task UI . Siebel Task UI allows navigation both backward and forward within a task UI, and allows a task UI to be paused and resumed, as required. You can call a task UI from within in a workflow process by including a task step. For more information, see About the Task Step on page 84, and Siebel Business Process Framework: Task UI Guide.
37
38
Environment for Developing a Workflow Process
This chapter describes the workflow process development environment. It includes the following topics: About the Object Hierarchy of a Workflow Process on page 39 About the Process Designer on page 44 About the Process Property on page 47 About the WF/Task Editor Toolbar on page 62
About the Object Hierarchy of a Workflow Process

The object hierarchy that is used with objects for a workflow process can be viewed in Siebel Tools. You use Siebel Tools to modify standard Siebel objects and to define new objects in order to meet a business requirement for your organization. Just as you use Siebel Tools to extend the data model, modify business logic, and to define the user interface, you also use Siebel Tools to define a workflow that the Siebel application uses to automate a business process for your organization.
39
Environment for Developing a Workflow Process About the Object Hierarchy of a Workflow Process
Siebel Tools consists of an Object Explorer (OE) window and one or more Object List Editor (OBLE) windows, as illustrated in Figure 9.
Object Explorer (OE)
Object List Editor (OBLE)
Figure 9.
Object Explorer and Object List Editor (OBLE)
The Object Explorer provides navigation between each group of object definitions of a particular object type. An object type is an entity that is displayed as an element in the Object Explorer. An object type contains a predefined set of properties and is used as the template from which object definitions are defined. Workflow Process is one object type. An object definition implements one piece of the software. This object definition consists of object properties, which are characteristics of that piece of the software. If the Workflow Process object type is not visible in the Object Explorer, then you must expose it. For more information, see Exposing Object Types That Are Used to Develop a Workflow Process on page 116.
40
Properties of an Object
If the Workflow Process object type is chosen in the Object Explorer (OE), then the Workflow Processes Object List Editor (OBLE) displays a list of workflow processes that are currently defined in the SRF. One row in the Workflow Processes OBLE represents one object definition. For example, values in the properties in the workflow process named Contact-New Order constitute one object definition. Properties of the object definition can be edited in the OBLE. Object properties are represented as columns in the OBLE. Information entered into the columns of an OBLE window represent values. You edit properties of the currently chosen object definition in an OBLE window by changing values in the columns. You can change the property values in an object definition. You cannot change the set of properties that constitute an object definition. You can also use the Properties window to edit the properties of the currently chosen object definition. Changing the value of a property in the Properties window also changes the corresponding value of that property in the Object List Editor window, and conversely.
41
Relations Between Object Types of a Workflow Process

A parent and child relationship is a type of hierarchical relationship that exists between one Object Type and another Object Type. The parent and child relationship is represented in the Object Explorer as a hierarchical tree, as illustrated in Figure 10.
Parent and child relationship between the Workflow Process parent object type and the WF Step child object type.
Figure 10. Parent and Child Relationship Between Object Types in the Object Explorer When the Types tab is chosen in the Object Explorer, the arrangement of folder icons is hierarchical. An object type that is beneath and slightly to the right of another object type is the child of the parent and child relationship. The object type that is above the child object type is the parent object type for the child. A parent object type can contain multiple child object types. For example, WF Process Metric, WF Process Prop, and WF Step is each a child object type of the Workflow Process object type.
42
This guide assumes that you understand the basics of using Siebel Tools. The skills you must possess include: Using the Siebel Tools application, particularly Object Explorer and Object List Editor usage Defining object properties, applets, and applet controls Using the Siebel Tools menu bar Checking out and checking in projects Working with projects
For more information, see Using Siebel Tools, and Configuring Siebel Business Applications.
Locating a Workflow Process in the Workflow Processes Object List Editor

This topic describes how to locate the object definition for a workflow process in the OBLE.
To locate a workflow process in the Workflow Processes object list editor 1 2

Open Siebel Tools. If necessary, expose the workflow process object hierarchy. For more information, see Preparing Siebel Tools to Develop a Workflow Process on page 115.
3 4
In the Object Explorer, click Workflow Process. In the Workflow Processes OBLE, query the Process Name property for the workflow process you must modify. If the workflow process exists, then the object definition for the workflow displays in the OBLE. Querying for the workflow in this way results in a single, isolated record being displayed. This technique helps to make sure that the correct workflow is chosen in the OBLE when you modify child objects for the workflow or when you perform other work, such as publishing or revising.
43
Environment for Developing a Workflow Process About the Process Designer
About the Process Designer

This topic describes the Process Designer that is used to define a workflow process in Siebel Tools. It includes the following topics: Graphical User Interface of the Process Designer on page 44 Data That Is Available for Configuration on page 46
Graphical User Interface of the Process Designer

Figure 11 illustrates the main elements of the GUI (Graphical User Interface) of the Process Designer.
Figure 11. Graphical User Interface of the Process Designer
44
The Process Designer includes elements you use frequently when building a workflow process:
Process Designer Canvas. A work area where you build the workflow process. You right-click the canvas in order to access a context sensitive menu that allows you to perform various work on the workflow that is displayed in the canvas. Workflow Designer Palette. A window that contains icons that represent the various step types you can add to a workflow process. To add a step to a workflow, you drag, then drop an object from the palette to the canvas. Multi Value Property Window (MVPW). A window that allows you to define properties for a workflow process, and arguments for a step in a workflow. For more information, see Multi Value Property Window on page 50. Properties Window. A window that allows you to define properties for an individual step in a workflow process, or for the overall workflow. The window is context sensitive. If a step or connector is chosen in the canvas, then properties for the step or connector are displayed in the Properties window. If no step or connector is chosen in the canvas, then properties for the workflow process are displayed in the Properties window. For more information, see Overview of Workflow Process Steps on page 65.
Functionality of the Process Designer

You use the Process Designer in Siebel Tools to build your workflow process. The following work can be performed in the Process Designer: Copy and paste. Copy and paste objects in the canvas of the Workflow Designer as you are building the workflow process. Edit shape properties and layout. Define shape colors and other attributes, such as the look of the line, the fill pattern, and the font for labels. Establish consistency by controlling alignment of shapes and by making shapes the same size as other shapes in the workflow process. Zoom. Zoom in and out on the canvas of the Process Designer in order to view the workflow process at various magnifications. Copy drawings. Copy a workflow process into another application, such as a Microsoft Word document. In the canvas, you right-click, then choose Copy Drawing. Print. Print the workflow process. Hide connector and error exception connector names. You can choose to hide the names of connectors and error exception connectors within a workflow process. Hiding a connector name can be helpful in order to clarify the meaning of conditional branching that emanates from a start step or a decision point.
The copy and paste functionality works the same as with a typical Windows applications. For example, by using the CTRL+C and CTRL+V keyboard combinations. Other functionality is employed by right-clicking the canvas of the Process Designer.
45
How the Process Designer Indicates Whether a Workflow Process Is Editable

The canvas color in the Process Designer indicates whether the workflow process is editable: A yellow canvas indicates the workflow process cannot be edited A white canvas with a grid indicates the workflow process can be edited
If a workflow process is editable, then you can modify the workflow in a variety of ways, such as adding and removing steps and connectors, or changing step and connector properties. For more information, see Making a Workflow Process Editable on page 120.
Data That Is Available for Configuration

Because the Process Designer is in Siebel Tools, data objects are available for use as you design your workflow process. A change in the repository data is immediately available for use in a workflow without the requirement to compile the SRF. You can use configuration data, such as a business component field or other repository information, while you are building your workflow. For example, if a List of Values (LOV), such as Account Status, contains values of Gold, Silver, and Bronze, then you can use a newly added LOV in a decision condition of your workflow process as you define it. For another example, if you add a field to a business component, then that new field is readily available for use in the Process Designer. The type of data that is not available for use in designing a workflow process is run-time data, such as an account name or a ZIP code, and other transactional data. To use run-time data while you are building a workflow process, make the data available through a process property. If necessary, you can also hard code run-time data into your workflow by using an unbounded picklist. For more information, see About the Process Property on page 47.
46
Environment for Developing a Workflow Process About the Process Property
About the Process Property

This topic describes information about process properties. It includes the following topics: Process Property and the Property Set on page 48 Arguments of the Step of a Workflow Process on page 49 Multi Value Property Window on page 50 Process Properties That Are Predefined on page 54 Manipulating a Process Property on page 57
A process property is a container that stores a value that the workflow process retrieves from the database or derives before or during processing. You can use the value that is stored in a process property in the following ways: Pass information between objects. For example, between steps in a workflow process, between a workflow process and a subprocess, or between a workflow and a business service. The process property is defined as an input or output argument for a workflow step. Base a decision branch on the value in a process property. Use the value in a process property in an expression.
When a workflow process finishes, the final value of each process property is available as a separate output argument that can be passed to another object. For more information about: How a process property is defined in Siebel Tools, see Defining a Process Property for a Workflow Process on page 124 An example that uses a process property, see Example of Defining a Workflow Process That Traverses a Record Set to Close Service Requests That Are Obsolete on page 264 Arguments that are used with a process property, see Fields and Arguments of Process Properties on page 462 A detailed description of property sets, see Integration Platform Technologies: Siebel Enterprise Application Integration
47
Process Property and the Property Set

A property set is a hierarchical structure that contains name and value pairs, known as properties, at each level in the hierarchy. The process property stores data that is associated with the property set. A workflow process uses a property set in order to pass data to and from a step that exists within a workflow process. Figure 12 illustrates how a process property can be used within a workflow process.
Figure 12. How a Process Property Can Be Used within a Workflow Process Example usage within a workflow process is described in the following sequence:
1 2 3 4
A process property is used to send data to Workflow Step 1 as an input argument. Workflow Step 1 manipulates the data according to the configuration for Step 1. An output argument on Workflow Step 1 sends data from the step to the process property. An input argument on Workflow Step 2 brings the data that is manipulated in Step 1 into Workflow Step 2, where it can be manipulated according to the internal configuration that is defined for workflow Step 2.
The process property and step arguments are defined in the Multi Value Property Window. For more information, see Multi Value Property Window on page 50.
Initial Values of a Process Property

When a workflow process is started, a process property that is of type string, number, or date with an In/Out type of In or In/Out is initialized to the input property with the same name, if one exists. A hierarchy process property with an In/Out type of In or In/Out is initialized with child input property sets that contain a matching name. A process property that contains a Default String set to [Value] is initialized with the value in the Value property of the input property set.
48
Concluded Values of a Process Property

When a workflow process concludes, a process property that is of type string, number, or date with an In/Out type of In or In/Out is stored as a property in the output property set. A hierarchy process property with an In/Out type of In or In/Out is stored as a child property set. If a process property with the name [Value] is defined, then the value of the property is stored in the Value property of the output property set. NOTE: The process property [Value] can also be used to pass binary data in a sub process step. The input argument [Value] of the subprocess can be initialized with data in the main process, then retrieved in the sub process step. For more information, see Passing Data to and from a Workflow Process on page 182.
Arguments of the Step of a Workflow Process

An argument is a part of the process property hierarchy that allows you to define values for fields. An argument field is a variable on an argument that allows you to define a value that shapes the parameters of a process property. Table 6 describes how an argument can be defined in the MVPW in order to pass data to and from an individual step in a workflow process.
Table 6.
Arguments That Can Be Defined on a Workflow Process Step Description Used to bring data into a workflow process step. Used to send data out of a workflow process step. Used to define a search specification for a Siebel operation step. Used to define a recipient for a task step or a sub process step.
Argument Input Argument Output Argument Search Specification Recipient
A step for a workflow process can contain several types of arguments. The type of step determines the possible arguments that can be defined. The Type field for an argument affects other fields in the argument that must be defined. For more information, see Defining an Argument of a Step in the MVPW on page 53.
Input Arguments of the Business Service Step, Sub Process Step, and Wait Step
An input argument allows you to define the value for a field that you must pass to the method of a business service. There are many methods that require an input argument. For more information, see Fields of an Input Argument of a Process Property on page 465.
49
Output Arguments of the Business Service Step, Sub Process Step, and Siebel Operation Step
An Output argument can be the result of work that is performed by the method of a business service. An output argument can be stored in a process property. A calculated field is not available as a value for an input or an output argument. If you must use a calculated value, then use an expression. For more information, see Fields of an Output Argument of a Process Property on page 466.
Process Properties of the Business Service Step

Process properties for the business service step include a data type of hierarchy, integration object, or strongly typed integration object, and can be used as an input or output argument for the method of a business service that includes a data type of hierarchy, integration object, or strongly typed integration object. If you must call a workflow process through a business service, then you can map the data that is contained in the input and output property sets to and from a process property. This technique is useful when you must run a workflow within a script.
Multi Value Property Window

The Multi Value Property Window (MVPW) is a window that can be used to define a process property. It can also be used to define an argument for a workflow process step. Table 7 describes this usage.
Table 7. Object
How the Multi Value Property Window Is Used Description Used to store values that apply to the entire workflow process. Used to communicate information between a process property and an individual step in a workflow process. How Defined Click the canvas of the Process Designer, then use the MVPW. Click a workflow process step, then use the MVPW.
Process Property Step Argument
For an example that uses the MVPW, see Defining the Workflow Process on page 266.
MVPW Usage with the Process Property

Process properties appear when the canvas is first opened for editing, or when no object is chosen in the Process Designer. For more information about the following: An illustration of the MVPW that displays a predefined process property, see Figure 11 on page 44. A description of how the process property and the step argument work in conjunction with one another, see Process Property and the Property Set on page 48.
50
MVPW Usage with the Step Argument

Figure 13 illustrates the MVPW displaying arguments for an object in the workflow process. These arguments are displayed when an object is chosen. In this example, the Set Commit Time in 1 Hour Siebel operation step is chosen. Three input arguments for the step are displayed in the MVPW.
Figure 13. Multi Value Property Window Displaying Arguments for an Object Elements displayed in the MVPW when an object is chosen include:
1 2 3
Argument tab. The argument tabs change based on the type of step that is chosen. Field. A field in the MVPW is a parameter you can specify that provides instructions for the argument. Figure 13 displays the Field Name, Sequence, Type and Value fields. Argument. Each row in the MVPW represents a single argument. The collection of fields for a row constitute the definition for the argument.
51
Viewing the Definition of an Argument in the Object Explorer

The definition of an input or output argument that is displayed in the MVPW when an object is chosen in the Process Designer is also visible through the Object Explorer.
To view the definition of an argument in the object explorer 1

Locate the workflow process. For more information, see Locating a Workflow Process in the Workflow Processes Object List Editor on page 43.
2 3 4 5
In the Object Explorer, expand the Workflow Process tree. Expand the WF Step tree. In the WF Steps OBLE, choose the workflow process step of interest. In the Object Explorer, click WF Step I/O Argument. The definitions for the input and output arguments that are defined for the step are displayed in the WF Step I/O Arguments OBLE.
Viewing a Process Property in the MVPW

If you click the canvas with no step or connector chosen, then the child objects of the overall workflow process are displayed. The Process Properties tab in the MVPW displays the definitions of the process properties.
To view a process property in the MVPW 1 2 3 4 5

If necessary, expose the MVPW by choosing, from the application-level menu, the View menu, Windows, then the Multi Value Property Window menu item. In the Process Designer, click the canvas of the workflow process. Make sure no steps or connectors are chosen. In the MVPW, make sure the Process Properties tab is chosen. Examine the records that are displayed in the MVPW.
Viewing an Argument of a Step in the MVPW

If you click a step in the canvas of the Process Designer, then the input and output arguments for the step are displayed in the MVPW. Depending on the type of step chosen, the MVPW displays one or a combination of tabs.
52
To view an argument of a step in the MVPW 1

Click a step in the process designer. If necessary, expose the MVPW by choosing, from the application-level menu, the View menu, Windows, then the Multi Value Property Window menu item.
Choose the required tab in the MVPW, then examine the arguments that are displayed.
Defining an Argument of a Step in the MVPW

You can define an input or output argument for a step in the MVPW.
To define an argument of a step in the MVPW 1 2 3 4

In the Process Designer, click the step on which you must define an argument. In the MVPW, click an arguments tab. In the MVPW, right-click anywhere below the column headings, then choose New Record. Define the argument field. For example, if you are defining an input argument on a Siebel operation step, then define the Field Input Argument.
Define the Type field and other fields, as necessary. For more information, see How the Type Field Affects Other Fields of a Step Argument on page 53.
How the Type Field Affects Other Fields of a Step Argument The value you choose in the Type field for a step argument determines how you define other fields of the argument in the MVPW.
53
Table 8 describes how to define an argument based on the type you choose.
Table 8.
How to Define an Argument in the MVPW Based on the Type You Choose Work You Perform Choose a business component from the picklist in the field for the Business Component Name, then choose a business component field from the picklist in the field for the Business Component Field. Type an expression into the Value field. Alternatively, you can click the dropdown button to launch the Expression Builder. The expression you enter is evaluated at run time to determine the value.
Type You Chose Business Component
Expression
Literal
Type a string into the Value field. The value you enter defines the literal value for the argument.
Process Property
Choose a Property Name from the pick applet for the Property Name field. Process Property is only available for an input argument.
Output Argument
Choose a property from the picklist in the Output Argument field. The picklist allows you to choose process properties that are of type In/ Out or Out. Output Argument is only available for an output argument.
Changes for Siebel CRM Version 8.0

With Siebel CRM version 8.0, the Multi Value Properties Window (MVPW) replaces the list applet in most cases in the Process Designer. Rather than viewing properties for a step by clicking the step, then accessing a list applet below the canvas, you view properties for the step in the Properties window and child items for the step in the MVPW. Rather than right-clicking a step to view input and output arguments for the step, you view them in the MVPW. You can add and delete values from within the MVPW in the same manner as was performed in earlier releases in the list applets.
Process Properties That Are Predefined

The following list includes some of the default process properties that are automatically defined for each workflow process: Object Id. The Siebel row ID of the record against which the workflow process is started. Error Code. An error symbol of the instance of the workflow process if a step returns an error. This process property is automatically populated when an error occurs. Error Message. A text error message of the instance of the workflow process if a step returns an error. This process property is automatically populated when an error occurs.
54
Siebel Operation Object Id. The Siebel row ID of the record that is updated, created, or queried during a Siebel operation step. This process property is automatically populated when a Siebel operation step is executed. Process Instance Id. A unique number that is assigned to the currently running instance of the workflow process. This process property is automatically populated when a workflow is executed and persistence is activated.
Object Id Process Property

The Object Id process property is the Siebel Row Id of the primary business component record against which a workflow process is started.
Run-Time Event Behavior If a workflow process is started by a run-time event, then the instance of the active business component that started the run-time event is automatically passed to Siebel Workflow. A run-time event is received on the row that is defined by the Object Id property. Siebel Workflow receives and processes this event only when the business object that the instance of the active business component belongs to is the same as the business object in the definition for the workflow process. If Siebel Workflow can receive this event, then the Object Id process property is automatically set to the active row of the primary record in the business object. If the business component that started the run-time event is not the primary business component, then the active row of the business component is not reflected in the Object Id process property, and it must be retrieved through some extra processing.
Behavior for Long-Running, Interactive, and Service Workflow Processes The following list describes behavior of the long-running, interactive, and service workflow processes: The Object Id must match the Row ID of the active row for the primary business component. The Workflow Engine does not allow the active row of the primary business component to be different from the Object Id process property. If the Object Id process property is different from the active row, then the primary business component is executed again to make the active row the same as the Object Id. It is possible to change the active row by assigning a new Row Id to the Object Id property. If Siebel Workflow detects that an assignment is made to the Object Id process property, then Siebel Workflow executes the business component again and makes the new Row ID the active row. If you set the Object Id to an empty string, then Siebel Workflow does not enforce the must match rule. However, the parts of Siebel Workflow that require an Object Id, such as the runtime event and Siebel operation step, cannot be used until the Object Id is set to a new Row ID.
55
Changing the Active Row in a Workflow Process Step You can add a step that performs an operation that results in a change of the active row.
To change the active row in the step of a workflow process 1 2

Add a Siebel operation or business service step that performs an operation that results in a change of the active row. Update the Object Id process property to the new active Row ID in the output argument of the workflow process step you added in Step 1. After a workflow process step finishes and output arguments are evaluated, Siebel Workflow checks to make sure the Object Id matches the active row. Therefore, a change to the active row must be reflected in the Object Id property within the affected step.
In/Out Process Property

If necessary, you can run a workflow process and avoid receiving response data back. For example, to avoid inserts to the S_SRM_DATA table that can cause a heavy backlog. Configuration within a workflow process determines whether response data is returned. If the type of a process property is Out or In/Out, then outputs are returned to the caller. For example, outputs are returned to the Server Request Processor. If the caller receives a response that is not null from a callee, then it writes the response into the S_SRM_DATA table. If no response data is received, then the response is not written into the S_SRM_DATA table. If a request is inserted into the S_SRM_REQUEST table, then one or more rows are inserted into the S_SRM_DATA table for the component request parameters and input arguments that are used by the request. During submission of a request, the S_SRM_DATA table column MSG_TYPE_CD contains a value of REQ_DATA, which indicates the type of data is to request data or inputs for the request. If the request finishes execution, then a set of rows is also inserted into the S_SRM_DATA table with the MSG_TYPE_CD column having a value of REQ_RESPONSE, which indicates that the request returned a response back to the caller. In this case, because the request is in the S_SRM_REQUEST table, the caller is the Server Request Processor component.
Running a Workflow Process to Avoid a Response Data Insert You can run a workflow process to avoid response data inserts.
To run a workflow process to avoid a response data insert 1

Define one of the following options:

Until immediately upstream of the end of the workflow process, leave the In/Out property of the process property set to In/Out. Immediately upstream of the end of the workflow process, call another step that nulls out values that are stored in the process properties. In this way, the Server Request Processor receives no response text and an insert is not made into the S_SRM_DATA table.
Review process properties for the workflow process, then set the In/Out property to NONE.
56
Manipulating a Process Property

This topic describes how a process property is manipulated. It includes the following topics: Passing a Process Property In and Out of a Step of a Workflow Process on page 57 Passing a Process Property by Reference on page 58 Passing a Process Property to an Error-Workflow Process on page 58 Concatenating a Process Property on page 59 Referencing a Process Property on page 60
Passing a Process Property In and Out of a Step of a Workflow Process

In a long-running, interactive, or service workflow process, when a hierarchical process property is passed to a step in a workflow process, the Type field of the top level process property is overwritten by Siebel Workflow for the duration of the call in order to match the name of the argument, as defined by the configuration for the input argument. For example, assume MyTree is a process property with data type Hierarchy. MyBusSvc is a business service that contains a hierarchical Input Argument named SomeTree. Consider the process property described in Table 9.
Table 9.
Example of a Process Property in the MVPW Type Process Property Property Name MyTree
Input Argument SomeTree
If the input argument is defined with the values that are displayed in Table 9, then the call into MyBusSvc receives a child in the input process property for the argument with the Process Property Type field set to SomeTree , instead of MyTree. The rest of the data in the child process property is the same as the contents of the MyTree process property. Similarly, Siebel Workflow expects an output argument of a step in a workflow process that passes out a hierarchy to send it out as a child of the output property set. Siebel Workflow locates the child by examining the Type field of the child. The string in the Type field must match the name for the Output Argument, as defined in the output argument applet of the step. After Siebel Workflow finds such a child, the data is copied into the indicated destination process property. However, the Type field on the incoming hierarchy is discarded, and instead the name of the process property overwrites the Type field. To summarize, when passing a hierarchy into and out of a step, the Type field of the top level of the data is used as the name of the argument. NOTE: It is recommended the Type field of the top level of a hierarchical argument not contain data.
57
Passing a Process Property by Reference

A subprocess that modifies a large amount of data must copy a large amount of data through input and output arguments. This situation can negatively affect the performance and scalability. If you can avoid unnecessary copying of data, then you can achieve improvements in performance and scalability. Pass By Reference is a feature that allows you to avoid passing a large property set by passing just a pointer to the property set. You can use Pass By Reference for a workflow process by using a sub process step. For more information, see Pass By Reference Feature for a Business Service on page 71.
Passing a Process Property to an Error-Workflow Process

You can pass more than just a system defined process property to an error-workflow process. The following conditions apply when a process property is passed to an error-workflow process: To pass the original instance of a workflow process to a process property that is defined by the user to the error workflow, you must explicitly redefine those user-defined process properties in your error workflow, giving them the same name and data type. To pass a property set from the original workflow process to the error workflow, you must define a common user-defined hierarchy process property in the original workflow and in the error workflow, then use this common hierarchy property to pass the property set. To get the name of the original workflow process, you must define a common user-defined process property in the original workflow and in the error workflow, then pass the original name for the workflow through this common user-defined process property.
To pass a process property to an error-workflow process 1 2

Define an error exception connector. For more information, see Defining an Error Exception Connector on page 165. Click the stop step, then define an input argument in the MVPW using values from the following table. Field Name Type Value Value %1 Literal Error Message (or a valid string)
In the Workflow Processes OBLE, define a new workflow process that references the errorworkflow process.
58
Concatenating a Process Property

You can use values for a process property in an expression by concatenating properties of a workflow process with other process properties or with text. The following example illustrates how four process properties can be used in a workflow to concatenate three string values. The three process properties contain values in the Default String property of Welcome, to, and Siebel.
To concatenate a process property 1

In Siebel Tools, in the Workflow Processes OBLE, define a new workflow process using values from the following table. Property Process Name Business Object Workflow Mode Value Concatenate Account Interactive Flow
For an example, see Defining the New Workflow Process on page 256.
Open the Process Designer for the workflow process you defined in Step 1, then define the flow to resemble the following diagram:
For more information, see Overview of Workflow Process Steps on page 65, and Diagramming a Workflow Process on page 122.
In the MVPW, define four process properties using values from the following table.
Name ProcessProperty1 ProcessProperty2 ProcessProperty3 ProcessProperty4
In/Out In/Out In/Out In/Out In/Out
Business Object Account Account Account Account
Default String Welcome to Siebel (no value)
Data Type String String String String
For more information, see Multi Value Property Window on page 50.
Click the wait step, then click the Output Arguments tab in the MVPW. The wait step is often used for testing and development. For more information, see About the Wait Step on page 87.
59
Define an Output Argument for the wait step using values from the following table.
Type Expression
Output Arguments ProcessProperty4
Value [&ProcessProperty1]+' '+[&ProcessProperty2]+' '+[&ProcessProperty3]
The ampersand (&) identifies the text that immediately follows the ampersand as the name of a process property. The process property you indicate can also be the name of a field in a business component. ProcessProperty1, ProcessProperty2, and ProcessProperty3 can be of different types, such as string or date. The Data Type property for the process property in this example must be set to String. Because an error might occur when a binary type is used with an expression, you cannot use an expression in order to set a process property whose Data Type property is set to binary. An example error in this situation is a process property that includes truncated data.
6 7 8 9
Validate, then simulate the workflow process. For more information, see Process of Testing a Workflow on page 202. After control returns to Tools, right-click the Simulation window, then choose Watch Window. In the Watch window, expand PS:Property Set. Note the values for the four process properties that you defined in Step 3.
10 Click Simulate Next.

In the Watch window, ProcessProperty4 now contains a concatenation of values from ProcessProperty1, ProcessProperty2, and ProcessProperty3.
Referencing a Process Property

A process property can be referenced from within an expression. The syntax is [&PropName]. For example: [&Object Id] like '99-28B1T' where: & indicates a process property Object Id is the name of the process property
60
The following example illustrates how a process property can be used as a substitution variable within a more complex expression. This example uses an input argument to establish a message body: The Activity #" + [&Object Id] + ", owned by " + [&First Name]+" "+[&Last Name] + " is three days past the Due Date. where: Object Id, First Name, and Last Name are defined as process properties.
For more examples of using a process property as a substitution variable, see Example of Defining a Siebel Operation Search Specification on page 77 and Substitution Variables That Are Commonly Used in an Expression on page 194.
61
Environment for Developing a Workflow Process About the WF/Task Editor Toolbar
About the WF/Task Editor Toolbar

The WF/Task Editor Toolbar is used to manage deployment of a workflow process. Figure 14 illustrates how the toolbar is displayed in Siebel Tools.
Figure 14. WF/Task Editor Toolbar in Siebel Tools For procedural information on publishing and activating a workflow process, see Process of Deploying a Workflow Process on page 211.
Buttons on the WF/Task Editor Toolbar

Table 10 describes buttons on the WF/Task Editor Toolbar. To identify a button in the WF/Task Editor Toolbar, position your mouse over an icon in the toolbar, then note the name for the button when it is displayed in a small pop-up message.
Table 10.
Buttons on the WF/Task Editor Toolbar Description Moves the definition of a workflow process from the repository tables into the run-time tables of the Siebel client. If you click Publish, then the status of the workflow process changes from In Progress to Completed, and is available in the following situations: If you are connected to the server data source, then the finished workflow process is ready to be activated at run time. If you are connected to the local data source, then check in the workflow process. After you check in the workflow, it is ready to be activated at run time.
Button Name Publish
Publish/Activate
Publishes and activates the workflow process with a single button click from within Siebel Tools while in local mode. If you use Publish/Activate rather than Publish to publish the workflow, then it is not necessary to separately activate the workflow in the Siebel client. To use this feature, you must also set the [Workflow] VerCheckTime parameter to -1 (negative 1) for the Siebel client on which you are testing. For more information, see Preparing Siebel Tools to Develop a Workflow Process on page 115.
62
Table 10.
Buttons on the WF/Task Editor Toolbar Description Creates a new version of the workflow process for editing. The new version displays in the Workflow Processes OBLE with the version property incremented by 1. Sets the status for the workflow process to Not In Use. After the workflow is expired, it can no longer be edited, published or activated. However, it can be revised.
Button Name Revise
Expire
Exposing the WF/Task Editor Toolbar

Upon first use of the toolbar, you must expose it. For more information, see Preparing Siebel Tools to Develop a Workflow Process on page 115.
Activate Button in the Siebel Client

If you choose to publish a workflow process but not activate it in Siebel Tools, then you must use the Siebel client to activate the workflow by clicking Activate in the Workflow Deployment view. Activate adds a new record that is visible in the Active Workflow Processes list. Activate performs the following:
1 2 3 4
Checks the syntax for validity. Registers run-time events, if used. Changes the status of the workflow process to Active. If the workflow process was previously activated, then Activate changes the status of the previous active version to Outdated.
Activate chooses the active version of the workflow process in the run-time tables. Only one version of a workflow can be active at a time for a Siebel Enterprise. Activate provides version control to address an environment where multiple developers can publish multiple versions of the same workflow process. Activation occurs from within the Siebel client, where multi select is supported. For more information, see Activating a Workflow Process on page 216.
Validation of a Workflow Process

If you click Publish or Publish/Activate in the WF/Task Editor toolbar, then the workflow process is validated before it is published. For more information, see Validate Tool on page 197.
63
Deployment Changes Beginning with Siebel CRM Version 8.0

A workflow process is deployed by using buttons in Siebel Tools labeled Publish and Publish/Activate. In both releases, the button was labeled Deploy, and activation can only occur in the Siebel client. Beginning with Siebel CRM version 8.0, if you set the VerCheckTime parameter in the Workflow section of the .cfg file to -1 ([Workflow] VerCheckTime = -1), then you can activate a workflow in Siebel Tools. For more information, see Preparing Siebel Tools to Develop a Workflow Process on page 115. If there are no validation errors, then neither the Validate dialog box nor the message stating that the validation was successful is displayed. The validation is executed implicitly without visibility to you, unless an error is detected.
Copying Instead of Revising a Workflow Process

In some cases, you can copy an existing workflow process rather than revising it. The copy feature allows you to continue to work on the original workflow. For an example, see Modifying the Existing Workflow Process on page 301.
64
Steps and Connectors of a Workflow Process
This chapter describes the types of steps that can be defined in a workflow process. It includes the following topics: Overview of Workflow Process Steps on page 65 Types of Steps of a Workflow Process on page 69 Defining a Decision Condition on page 92
Overview of Workflow Process Steps

This topic describes an overview of steps that are used in a workflow process . It includes the following topics: Adding a Step to a Workflow Process on page 66 Name of a Step in a Workflow Process or a Process Property on page 67 How Properties Are Defined for a Step in a Workflow Process on page 68 Sequence Number for a Step in a Workflow Process on page 68
For more information, see Types of Steps of a Workflow Process on page 69. Figure 15 displays the Workflow Designer Palette.
Figure 15. Steps and Connectors in the Workflow Designer Palette
65
Steps and Connectors of a Workflow Process Overview of Workflow Process Steps
Table 11 describes the types of steps and connectors that are available in the Workflow Designer Palette.
Table 11.
Types of Steps and Connectors in the Workflow Designer Palette Description Defines the decision condition that must be met in order to execute an instance of a business process. The condition is defined on the connector that emanates from the start step, and not on the start step itself. Calls a business service that allows you to execute actions that are predefined or custom in a workflow process. Evaluates a decision condition in order to determine the next step to execute. Calls a workflow process. The called workflow can be a standalone workflow, with a separate object definition and separate flow of workflow steps. Performs actions on a business component, such as Insert, Update, or Query. Calls a Siebel Task UI. Controls the flow of Siebel views within an application. Guides the end user through a defined flow of Siebel views based on the user action, or executes a defined set of actions. Suspends execution of the workflow process for a specific amount of time or until a specific event occurs. Terminates the workflow process instance. Presents an error message to the end user. Indicates when execution for the workflow process is finished. Determines direction of flow between steps in a workflow process. Traps for a deviation from normal processing, such as an error that is generated by the system or an error that is generated by an end user.
Step Type Start
Business Service Decision Point Sub Process Siebel Operation Task User Interact
Wait Stop End Connector Error Exception Connector
Adding a Step to a Workflow Process

You use the Process Designer to add a step to a workflow process. After you add a step, you can use the Properties window to define properties for the step. In some cases, you can use the WF Steps OBLE to define properties for a step. After you save a workflow, a record for the new step displays in the WF Steps OBLE, where you can modify properties.
66
To add a step to a workflow process 1

Locate the workflow process you must modify. For more information, see Locating a Workflow Process in the Workflow Processes Object List Editor on page 43. If the status of the workflow process is Completed or Not In Use, then click Revise in the WF/ Task Editor toolbar. For more information, see About the Process Property on page 47.
Right-click the workflow process in the Workflow Processes OBLE, then choose Edit Workflow Process. The Workflow Designer Palette and Properties windows open along with the Process Designer. The workflow is editable. If the palette is not visible, then you can display it by choosing, from the application-level menu, the View menu, Windows, then the Palette menu item.
3 4
Drag, then drop the step type that you must add from the Workflow Designer Palette to the canvas. In the Properties window, enter or modify the Name property. If you step out of the property, then the name updates on the step in the canvas. For more information, see Name of a Step in a Workflow Process or a Process Property on page 67.
5 6
(Optional) Enter a description of the purpose of the step. Define other properties for the workflow process step, as necessary. For more information, see Properties of the Step and Connector of a Workflow Process on page 450.
Name of a Step in a Workflow Process or a Process Property

The name for a step in a workflow process or for a process property must be unique within the workflow. When you define a new step, the Name property for the step is automatically populated with a name and number combination that you can change. If you change the name, then the new name, including the number, must be unique from the names of the other steps in the workflow. The name that is defined automatically for a step or a connector is based on the step or type for the connector. For example Business Service 0 for a business service step, or Siebel Operation 0 for a Siebel operation step. The number that is defined automatically in the name for a step or a connector is an integer, such as 0, 1, 2, 3, and so forth. This number differentiates instances of the same type of step or connector. For example, Business Service 0, and Business Service 1. This number, named sequence, is stored as part of the name. Some symbols, such as the period (.), cannot be used in the name of a process property.
67
How Properties Are Defined for a Step in a Workflow Process

You can define properties for a step in a workflow process. If you are working in the Process Designer, then some of these properties can be defined in the Properties window. If working in the Object List Editor (OBLE), then properties can be defined in the WF Steps OBLE. For more information about: Reference information about properties for a step in a workflow process, see Table 86 on page 459. An inventory of properties for each type of step and connector, see Properties of the Step and Connector of a Workflow Process on page 450.
Sequence Number for a Step in a Workflow Process

If a new step of the same type is added to the workflow process, and if there is no gap between the sequence numbers for the type, then the next number in the sequence is used. Otherwise, the first sequence number in the first gap for the step type is the sequence assigned to the new step. A gap can be created when a step is deleted. For example, assume there are five business service steps in a workflow process: Business Service 0, Business Service 1, Business Service 2, Business Service 3, Business Service 4. If Business Service 1 and Business Service 2 are deleted, then the next business service step assumes the sequence number 1, and it is automatically named Business Service 1. The same approach for sequencing is used for connectors.
68
Steps and Connectors of a Workflow Process Types of Steps of a Workflow Process
Types of Steps of a Workflow Process

This topic describes each type of step that can be defined in a workflow process. It includes the following topics: About the Start Step on page 69 About the Business Service Step on page 70 About the Decision Point on page 72 About the Sub Process Step on page 73 About the Siebel Operation Step on page 75 About the Task Step on page 84 About the User Interact Step on page 85 About the Wait Step on page 87 About the Stop Step on page 88 About the End Step on page 90 About the Workflow Connector on page 91
For more information, see Overview of Workflow Process Steps on page 65.
About the Start Step

A start step is a type of step in a workflow process that indicates the starting point for the workflow. A workflow can contain only one start step. A decision condition and a run-time event can be defined on the connector that emanates from the start step, but not on the start step itself. You can define the connector that emanates from a start step to perform the following work: To establish the decision conditions that must be met in order for the workflow process to execute. For example, to handle an open service request, you can define a condition of Status equals Open on the connector. For more information, see Defining a Decision Condition on page 92. To define a run-time event that is used to start the workflow process. For example, to generate an activity when the revenue for an opportunity is greater than $10,000, you can define a WriteRecord run-time event, then define a workflow that inserts the activity when an opportunity is saved that meets the decision condition. For more information, see Starting a Workflow Process from a Run-Time Event on page 144. For an example that uses a run-time event, see Example of Defining a Workflow Process That Creates an Activity for a Sales Representative on page 255.
Defining a Start Step

You define a start step in the Process Designer in Siebel Tools.
69
To define a start step 1

Add a start step to a workflow process. For more information, see Adding a Step to a Workflow Process on page 66.
If a run-time event is used to start the workflow process, then attach a connector to the start step, and then define the run-time event on that connector.
About the Business Service Step

A business service step is a type of step in a workflow process that allows you to execute a predefined or custom action in a workflow. Some examples of predefined business services include: Notification. A notification can be sent to an employee or contact by using the Outbound Communication Server business service. Assignment. Assignment Manager can assign an object in a workflow process by calling the Synchronous Assignment Manager Request business service. Server task. You can run a server component task by using either the Asynchronous Server Requests or the Synchronous Server Requests business service.
For a list of some of the more commonly used predefined business services, see Predefined Business Services on page 482. You can also define your own custom business service by using Siebel Tools or the Administrationbusiness service view in the Siebel client. You can use Siebel VB or Siebel eScript to define your own custom business service that you call from within a workflow process. CAUTION: A business service that is called from within a workflow process cannot include a browser script. A business service only works with a server script. If a business service with a browser script is executed from within a workflow process on the Siebel Server, then the business service fails.
Defining a Business Service Step

You define a business service step in the Process Designer in Siebel Tools.
To define a business service step 1

Add a business service step to a workflow process. For more information, see Adding a Step to a Workflow Process on page 66.
2 3
Make sure the step you added in Step 1 is still chosen in the Process Designer. From the picklist of the Business Service Name property, pick the name of the business service to be called. The picklist contains the business services that are defined in Siebel Tools or the Siebel client. For more information about defining a custom business service, see Integration Platform Technologies: Siebel Enterprise Application Integration.
70
4 5 6
In the Business Service Method property, choose the method that calls the service. The choices available for this property depend on the business service you defined in Step 3. Make sure the business service step is chosen. Use the MVPW to define input and output arguments. For more information, see Defining an Argument of a Step in the MVPW on page 53.
Making a Business Service Visible to a Workflow Process

A business service object, which includes the business service, business service method, and business service method argument, contains Display Name and Hidden properties in Siebel Tools. For this object to be displayed in a picklist, the Hidden flag for the object must be set to FALSE. For example, the methods and arguments you define in your business service appear in the picklists in the Arguments list applets for the business service. By default, a business service that is defined in the Siebel client is not hidden. When you define a workflow process in Siebel Tools, the value that is defined for the Name property for a business services object is the value that is also displayed in the picklists.
To make a business service visible to a workflow process 1

In Siebel Tools, in the Object Explorer, click Business Service. A list of business services that are predefined displays.
2 3 4 5 6 7 8 9
In the Business Services OBLE, click the business service you must modify. In the Properties window, change the Hidden property to FALSE. In the Object Explorer, expand the Business Service tree, then click Business Service Method. In the Business Service Methods OBLE, click the method you must modify, then change the Hidden property to FALSE in the properties window. Repeat Step 5 for each method, if applicable. In the Object Explorer, expand the Business Service Method tree, then click Business Service Method Arg. In the Business Service Method Arguments OBLE, click the argument you must modify. In the Properties window, change the Hidden property to FALSE.
10 Repeat Step 9 for each method argument, if applicable.
Pass By Reference Feature for a Business Service

The SupportsPassByRef user property is available for use on a Siebel business service. You cannot add this user property to a custom business service. If, in a workflow process, you define a business service step that is not marked for Pass By Reference, then the Workflow Engine returns an error.
71
For the Workflow Engine to use Pass By Reference, the following configuration must exist: The Business Service User Prop must be set to TRUE for the business service. The business service step in the workflow process must be marked for Pass By Reference.
CAUTION: Use of the Pass By Reference feature is not supported for a custom business service. For more information, see Defining a Subprocess to Support Pass By Reference on page 74.
Business Service Calls to a UNIX Shell Script

A Siebel process that runs on UNIX runs as the user that launches Siebel Services. If a workflow process calls a business service that calls a UNIX shell script, then the shell script runs as the Siebel Service Owner account.
About the Decision Point

A decision point is a type of step in a workflow process that evaluates one or more decision conditions in order to determine the next step that is executed in the workflow. A decision point evaluates the user data of a business component in a record when the workflow is executed. For example, assume the workflow is started by a workflow policy and multiple violations of a workflow policy condition occur during the action interval of the Workflow Monitor Agent. In this case, when the workflow is executed, the decision point determines which branch to pursue, based on the current value of the field of the business component.
Branch Logic in a Workflow Policy

If the logic of a branch connector is moved from the workflow process to the workflow policy level, then the workflow policy generates unique events within the defined action interval. In this way, the workflow is started by the violation of a workflow policy. For more information, see Expressions in the Expression Builder on page 190.
Defining a Decision Point

You define a decision point in the Process Designer in Siebel Tools.
To define a decision point 1

Add a decision point to a workflow process. For more information, see Adding a Step to a Workflow Process on page 66.
Define a decision condition for the decision point. For more information, see Defining a Decision Condition on a Branch Connector on page 95.
72
About the Sub Process Step

A sub process step is a type of step in a workflow process that allows you to start a separate workflow from within a workflow. A workflow can contain one or more sub process steps. You can also define a sub process step to support Pass By Reference. For more information, see Passing a Process Property In and Out of a Step of a Workflow Process on page 57 and Defining a Subprocess to Support Pass By Reference on page 74. If using the Process Simulator, then you must publish and activate a subprocess that is called by the workflow process you are simulating prior to calling the simulator. For more information, see Using the Process Simulator on page 204. For a description of properties of the sub process step, see Table 79 on page 456.
Defining a Sub Process Step

After a sub process step is added to a workflow process, you can edit the subprocess by double clicking the sub process step. You can also right-click the sub process step, then choose Edit Sub Process.
To define a sub process step 1

Make sure the workflow process that is called by the sub process step is defined. An object definition for the workflow process that is started by the sub process step must exist. If it does not, then you must define it before proceeding. For more information, see Defining a Workflow Process on page 117.
2 3 4 5
Add a sub process step to a workflow process. For more information, see Adding a Step to a Workflow Process on page 66. Make sure the step you added in Step 1 is still chosen in the Process Designer. Use the Subprocess Name property in the Properties window in order to choose the name of the workflow process that the sub process step calls. In the MVPW, define new input and output arguments. For more information, see Defining an Argument of a Step in the MVPW on page 53 and Defining an Input Argument on a Sub Process Step on page 74.
Define recipient arguments in the MVPW. For more information, see Fields of a Recipient Argument of a Process Property on page 468.
73
Defining an Input Argument on a Sub Process Step

You can define an input argument on a sub process step. This input argument allows you to populate a process property in the sub process step. For example, the Object Id is passed from the main workflow process to the subprocess through an input argument. If the subprocess is based on a different business object, then you must pass the relevant row ID of the target object as the subprocess Object Id Process Property. NOTE: If the subprocess generates a child object, then the Object Id that is passed to a subprocess must not contain the Object Id of the parent process. If a subprocess generates a child object, then it is recommended that the Object Id that is passed to a subprocess be null.
To define an input argument on a sub process step

Define an input argument on a sub process step. For more information, see Defining an Argument of a Step in the MVPW on page 53.
Copying a Value from a Parent Workflow Process to a Sub Workflow Process

You can copy a value to a record that is updated or inserted by a subprocess by defining a process property in the subprocess, then assigning the value to it through an Input Argument on the sub process step. The process property can then be used in the Siebel operation step of the subprocess. In the following example, you copy the Order Name for an order into the Name field of a newly created opportunity.
To copy a value from a parent process to a subprocess 1

Add a process property to the subprocess named Opportunity Name. For more information, see Defining a Process Property for a Workflow Process on page 124.
2 3
In the Sub Process step, map Order Parent Product Name to Opportunity Name. Assign Opportunity Name to the Name field of the opportunity that is created within the Siebel operation step.
Defining a Subprocess to Support Pass By Reference

If a subprocess modifies a large amount of data, then the subprocess must copy large quantities of data, thus resulting in a negative affect on performance and scalability. In such cases, you can use the Pass By Reference feature so that a pointer to the data is passed, but not the data itself.
74
Figure 16 illustrates an example workflow process that passes a large property set that is created by the Create Siebel Message step to the 11i Process Order step.
Figure 16. Example Workflow for Which Pass By Reference with a Sub Process Step is Useful If you define a sub process step to support Pass By Reference, then it is not necessary to map the output argument in the sub process step for the hierarchical properties that you are passing. The sub process step overwrites the passed input hierarchical argument. Optionally, you can define the sub process step to modify the passed input hierarchical argument.
To define a sub process step to support pass by reference 1 2

In the Workflow Processes list, choose the workflow process that is your subprocess. In the Properties window, set the Pass By Ref Hierarchy Argument process property to TRUE. In the Worfklow Process list, the Pass by Ref Hierarchy property is now checked for the child workflow.
About the Siebel Operation Step

The Siebel operation step is a type of step in a workflow process that performs operations, such as Insert, Update, or Query. The operation is performed on a business component. This topic includes the following topics: Defining a Siebel Operation Step on page 76 How the Search Specification Is Used with a Siebel Operation on page 77 Updating the Field of a Nonprimary Business Component on page 78 Updating a Field That Is Based on a Multi-Value Group on page 78 How the Calculated Field Is Used with a Siebel Operation Step on page 79 How the Siebel Operation Step Is Used to Traverse a Record Set on page 79 Updating a Process Property with a Siebel Operation Step on page 80 How the Object Id Process Property Is Used with the Siebel Operation Step on page 82 How the Upsert Operation Is Used with the Siebel Operation Step on page 82 Relations Between a Siebel Operation Step and the Siebel Object Hierarchy on page 83 Defining a Primary Business Component for a Business Object on page 83
75
Defining a Siebel Operation Step

You can define a Siebel operation step for a business component that is associated with the business object defined for the workflow process. If you must update a business component that is not associated with the business object, then you can use Siebel Tools to start a subprocess or associate the business component to the business object.
To define a Siebel operation step 1

Add a Siebel operation step to a workflow process. For more information, see Adding a Step to a Workflow Process on page 66.
2 3
Make sure the step you added in Step 1 is still chosen in the Process Designer. In the Operation property, choose the type of operation. For an update or insert to a field that contains a dependency, make sure the field is valid. For example, if a service request process and a workflow process updates the area and sub area fields, then you must make sure the values chosen for the subarea field are valid for that associated area.
4 5
For the Business Component property, choose the name of the business component on whose data the Siebel operation performs an operation. (Optional) In the MVPW, define new input and output arguments. If an Insert or Upsert operation is performed, then make sure you add the required arguments in the MVPW. Make sure you define the name of the field to be updated in the Field Name field. In the Type field, choose an input argument type, then define other fields, depending on the type you define. For more information, see Arguments of the Step of a Workflow Process on page 49.
(Optional) Define a search specification in the MVPW:
In the Type field, choose a search specification type, as described in the following table. Type Literal Expression Description A static string where the run-time value is the same as the value defined in the Process Designer. A Siebel expression, often based on other run-time variables, where
the run-time value can only be determined at run time by evaluating the expression. b c
In the Search Specification field, enter a search specification. If the search specification Type is Expression, then choose the applicable name of the business component. For more information, see How the Search Specification Is Used with a Siebel Operation on page 77.
76
How the Search Specification Is Used with a Siebel Operation

You can define a search specification to identify the specific data on which to perform the operation. A search specification is used when the business component contains multiple records and you must perform the operation on only some of the records. For example, if a workflow process for the account object must update only those opportunities that possess a lead quality of Poor, then you define a search specification to access only those opportunities. CAUTION: Define your search specification for a Siebel operation as efficiently as possible, so that only the smallest necessary set of rows match. A search specification that results in a large set of rows can cause severe performance degradation. For search specification usage in an example workflow, see Defining the Workflow Process on page 266.
How a Literal Search Specification is Defined A search specification of type Literal is executed as written. For example, [Status] LIKE '*Open*'. A search specification of type Expression allows you to build a search specification dynamically. For example, if the New ID process property is 1-ABC at run time, then "[Contact ID] = ' " + [&New ID] + " ' " is evaluated to [Contact ID] = '1-ABC'.
How a Business Component Field is Referenced Both sides of an expression can reference a business component field. The Filter Business Component defines the business component that is referenced on the left side, and the Expression Business Component defines the business component that is referenced on the right side. For example, consider the configuration described in Table 12.
Table 12. Field
Example of Arguments That Are Used in a Search Specification Value Account Contact "[Id] = [Account Id]"
Filter Business Component Expression Business Component Expression
In this example, the expression evaluates as described in the following syntax: "[Account.Id] = [Contact.Account Id]"
Example of Defining a Siebel Operation Search Specification An expression for a search specification can be defined with compound expressions and substitutions from process properties or fields. For example, consider the following generic syntax: "([Field1] > '" + [&Process Property Name] + "') OR ([Field2] IS NULL) OR ([Field3] IS NULL)"
77
This syntax is translated to: ([Field1] > 'value') OR ([Field2] IS NULL) OR ([Field3] IS NULL) Expressions that now include literal representations of the business component fields, where dFromDate is a custom process property, include: "([Open] > '" + [&dFromDate] + "') OR ([Open] IS NULL)" "([Open] > '" + [&dFromDate] + "') AND ([Status] IS NULL)"
For more information about using a process property as a substitution variable, see Referencing a Process Property on page 60.
Updating the Field of a Nonprimary Business Component

You can update the field of a nonprimary business component.
To update the field of a nonprimary business component

Make sure one of the following situations exists:

A join exists between the base table for the primary business component and the field you must update. A link exists between the primary business component and the business component that contains the field you must update.
For example, assume you must update sales stage data in a workflow process whose business object property is set to Opportunity. The predefined Sales Stage join on the opportunity business component provides the capability to update the sales stage field.
Guidelines for Using Joins and Links Guidelines for using joins and links include: If a predefined join or link does not exist, then you can define one. In some cases, to update a field in a nonprimary business component, you can copy an existing business object, then define it in the business object property of a workflow process. If you choose a different business component as the primary business component for this business object, then you must make sure link or join information that is defined for that business component is removed or corrected. Otherwise, an error can result.
For more information about: Defining a business component, see Defining a Primary Business Component for a Business Object on page 83 Modifying joins and links, see Configuring Siebel Business Applications
Updating a Field That Is Based on a Multi-Value Group

You can update a field that is based on a multi-value group.
78
To update a field that is based on a multi-value group 1 2

Define a business component for the field. Link the business component to the object that is using Siebel Tools.
For example, assume you must update the Account Team business component field. Account Team is based on a multi-value group, so it cannot be updated by choosing the Account business component. However, you can define a business component named Account Team, then associate it with the Account business object by using Siebel Tools. You can then choose Account Team as the business component to update with the Siebel operation step. For more information about multi-value groups, see Configuring Siebel Business Applications.
How the Calculated Field Is Used with a Siebel Operation Step

A Siebel operation step cannot be used to update a calculated field because, typically, the calculated field requires values from the fields of another business component. Instead, use an expression to perform calculations.
How the Siebel Operation Step Is Used to Traverse a Record Set

The NextRecord, PrevRecord, and QueryBiDirectional operations on the Siebel operation step are used in conjunction with the Update, Query, and Insert operations to traverse a record set. Using NextRecord and PrevRecord, you can navigate through the records of a child business component of the business object that is associated with the workflow process: The NextRecord operation changes the active row of the target business component to the next record in the current workset. The PrevRecord operation changes the active row to the previous record.
You must perform a query on the target business component before using subsequent Next Record and Previous Record operations. If the workflow process is traversing active records, or if your workflow uses the PreviousRecord operation, then query bidirectionally. Otherwise, use the standard Siebel query operation. NextRecord, PrevRecord, and QueryBiDirectional cannot be used to navigate through records of the primary business component. These operations are designed to navigate records of a child business component in a workflow process. Therefore you must use a child business component. For a detailed example that uses the traversing a record set technique, see Example of Defining a Workflow Process That Traverses a Record Set to Close Service Requests That Are Obsolete on page 264.
Output Arguments That Are Used with Traversing a Record Set If you use Next Record and Previous Record to traverse records of a child business component, then an output argument named NoMoreRecords in the Siebel operation is set to TRUE when the Siebel operation attempts to read the next record but finds there are no more records in the record set to traverse. NoMoreRecords is set to TRUE in the forward direction for Next Record or in the backward direction for Previous Record.
79
NoMoreRecords can be assigned to a process property, and in conjunction with a decision point, can be used to exit the loop after navigating through every record in the record set. To support this output argument, the Process Designer displays an Output Argument column in the output arguments tab for the Siebel operation step. Another output argument, NumAffRows (Number of AFFected Rows) exists for Query, Update and Upsert operations: If used with Query, then NumAffRows provides the number of rows that are returned as a result of the query If used with Update and Upsert, then NumAffRows provides the number of rows that are updated
Updating a Process Property with a Siebel Operation Step

You can define a test workflow process that uses a Siebel operation in order to update a process property. This technique can be useful during development. For example, you can use the sum of two business component integer fields that provide input to a decision that is downstream in the workflow process. By updating a process property in the Siebel operation step with the sum of the two required fields, you can use this property on a subsequent branch connector.
To update a process property with a Siebel operation step 1

In Siebel Tools, define a new workflow process using values from the following table. Property Process Name Business Object Workflow Mode Value Updating a Process Property Action Service Flow
Add steps and connectors until your workflow process resembles the workflow illustrated in the following figure:
Click the canvas, making sure no workflow process step or connector is chosen.
80
In the MVPW, right-click, then add a new process property using values from the following table. Field Name Display Name In/Out Business Object Value Custom Process Property Custom Process Property In/Out Action
For more information, see About the Process Property on page 47.
5 6
Click the Update Process Property step, then click the Search Spec Input Arguments tab in the MVPW. Right-click, choose New Record, then define a new record using values from the following table. Field Expression Business Component Filter Business Component Search Specification Type Value List of Values Query [Name] = 'Personal' AND [Type] = 'TODO_TYPE' Literal
7 8 9
Make sure the Update Process Property step is chosen in the Process Designer. Click the Output Arguments tab in the MVPW. Right-click, choose New Record, then define a new record using values from the following table. Field Property Name Type Value Business Component Name Value Custom Process Property Expression [Class Code] List Of Values
10 Validate, then simulate the workflow process.

For more information, see Process of Testing a Workflow on page 202.
11 Implement this technique in your production workflow process.
81
How the Object Id Process Property Is Used with the Siebel Operation Step
After an Insert or Upsert operation is executed, the Siebel Operation Object Id process property automatically stores the row ID of the record that was created. The Object Id for the workflow process is automatically passed to Siebel operation step. Because this automatic passing occurs, it is not necessary to define a search specification unless you are updating child records. For example, if a workflow that is based on the service request business object must update the service request, then it is not necessary for you to enter a search specification. However, if you must update activity records for the service request, then you can enter a search specification to query the specific activity you must update. Otherwise, the update step updates every activity that is associated with the service request. If you execute a Siebel operation, then the Object Id cannot be null, unless you insert into the primary Object Id. If the workflow process contains no Object Id, then the Siebel operation step returns an error. Values returned by the Siebel Operation Object Id process property when a query operation is performed for child records include: The row ID if one record matches. Null and no value if no records match. An asterisk (*) if multiple records match. This result is provided in order to distinguish from a value that returns a unique record or no record. Typically, either a unique record matches or no records match. In most cases, multiple records do not match and an asterisk is returned.
The only option returns the row ID of a matching row. The Insert, Update and Upsert operations update the Siebel Operation Object Id process property of the row ID for the record.
How the Upsert Operation Is Used with the Siebel Operation Step
The Upsert Operation provides a way to perform either an insert or update operation based on whether a record or records exist in the database. Hence the name, Upsert. The operation can perform an update or insert operation. For example, assume a search specification on a Siebel operation step queries the database. Table 13 describes how Upsert works in this case.
Table 13. Situation
Example of Work That the Upsert Operation Performs Work Performed by Upsert Upsert performs similar to an Update operation, and updates each record with modified values as determined by the workflow process. Upsert performs similar to an Insert operation and inserts a new record.
A record exists in the database If a record does not exist in the database
82
Examples Where Upsert Is Useful In the Siebel client, assume the end user is navigated to a view where the user clicks a checkbox to create a new contact, then enters the relevant contact information. Assume the Yes default for the checkbox creates a new contact. If the user creates a new contact, navigates away from the view, then returns to the view, when the user returns there is the potential that another contact is created. In this example, an evaluation must be made whether the contact already exists or not. If a contact does exist, then the contact must be updated. If the contact does not exist, then a new contact must be created. In another example, assume a workflow runs in the background at midnight, processing orders that are submitted from an external system. If an order does not exist, then Upsert creates a new record. If an order already exists but must be updated, then Upsert updates the record.
Relations Between a Siebel Operation Step and the Siebel Object Hierarchy
The workflow policy program and the Siebel operation step use different object layers in order to update data. For example, you can define a workflow policy that calls a workflow policy program to update a service request. This technique proceeds through the data layer, where the state model does not apply. Conversely, if you define a workflow policy that calls a workflow process action, and in the workflow process you define a Siebel operation step to update a service request, then this technique proceeds through the object layer, where the state model does apply.
Defining a Primary Business Component for a Business Object

The business object that is defined for a workflow process must contain a primary business component.
To define a primary business component for a business object 1 2 3

In Siebel Tools, in the Object Explorer, click Business Object. In the Business Objects OBLE, query the Name property for the business object you must modify. In the Properties window, use the picklist in the Primary Business Component property to pick the appropriate component name. Define a primary business component by choosing the key business component for the specific business object.
Compile the SRF.
After a primary business component is defined, the business object displays in the Workflow Processes OBLE.
83
About the Task Step

A task step is a type of step in a workflow process that launches a task UI from within a workflow process. After a workflow process calls a task UI, the task UI is visible in the Inbox for the end user. Until the user finishes the task UI, the workflow is in a waiting state. After the task UI finishes, the workflow moves to the next step in the workflow, and continues execution of the workflow. The main parts of defining a task step for a workflow process include: Defining input arguments for the task step, including associating the task step with a task UI Defining output arguments for the task step Assigning a recipient for the task UI
After you define a task step in the Process Designer and you associate the task step with a task UI, you can open the Task Editor by double clicking the task step in the Process Designer. Requirements for using a task step include: To define a task step in a workflow process, the task UI that is called by the task step must already be defined. For information on defining a task UI, see Siebel Business Process Framework: Task UI Guide. If the workflow process launches a task UI, then the Mode property for the workflow must be set to Long Running Flow.
Defining a Task Step

You define a task step in the Process Designer in Siebel Tools.
To define a task step 1

Add a task step to a workflow process. For more information, see Adding a Step to a Workflow Process on page 66.
2 3 4 5
Make sure the step you added in Step 1 is still chosen in the Process Designer. In the Task Name property, use the picklist to choose a task UI in order to associate the task UI with the task step. In the Properties window, make sure the Inactive property is set to FALSE. In the MVPW, define new input, output, and recipient arguments. For more information, see About the Process Property on page 47, and Siebel Business Process Framework: Task UI Guide.
84
About the User Interact Step

The user interact step is a type step in a workflow process that provides a way to define the flow of Siebel views within an application. Siebel Workflow guides the end user through a defined flow of Siebel views based on interactions with the end user, or executes a defined set of actions. This flow can be modified as the business environment changes. The user interact step can use a process property as an input argument. In this way, you can dynamically set view names as you design your interactive workflow process. The view name property is set in the View property, an unbounded picklist, of the user interact step.
Behaviors of the User Interact Step

Behaviors of the user interact step include: The user intact step sends a request to the Siebel Web Engine to build the view, then brings up the required view in the user session. Only one view can be built at a time. You cannot combine a user interact step with another action, such as bringing up a message box or building another view simultaneously. Also, you cannot use both a UserInteract step and start a task UI. The user interact step waits in the memory of the user session for a run-time event to resume processing. When there is no run-time event defined, the workflow process continues to the end. If, after a user interact step, the end user manually navigates out of the view, then the workflow process remains in the memory of the user session. The instance of the workflow is deleted when the user session is terminated or when another workflow process is instantiated in the same user session. If not already in the executed state, then the user interact step automatically queries the primary business component of the business object for the workflow process. The query searches for a record where the ID matches the value of the Object Id property. The workflow process is resumed after a user interact step only if the ID of the record where the run-time event that is registered in the decision conditions that are defined on the connector match the value of the Object Id process property.
Restrictions for the User Interact Step

Restrictions when defining a user interact step include: A workflow process running in the Workflow Process Manager server component must not contain a user interact step. That is, if the workflow is running in background mode or in batch mode, then it cannot include a user interact step. In this situation, if the Workflow Process Manager encounters a user interact step, then an error results. The user interact step is only supported if the workflow process is started through a script or a run-time event and the workflow is run locally in the application object manager. It is not possible to use a user interact step in a workflow process in order to move to a view and start the Search Center.
85
The user interact step, or another activity that is started from the background, cannot interfere with the activity of an end user. Because the end user controls work performed in the Siebel client, a workflow process that is running in the background cannot disturb work that is performed by the end user.
Defining a User Interact Step

You define a user interact step in the Process Designer in Siebel Tools.
To define a user interact step 1

Add a user interact step to a workflow process. For more information, see Adding a Step to a Workflow Process on page 66.
2 3 4 5
Make sure the step you added in Step 1 is still chosen in the Process Designer. In the Properties window, use the picklist in the User Interact View property to define the view name to which you must navigate the end user. In the Description property, enter a description of the purpose of the user interact step. If the user interact step requires conditional logic, then define a decision condition. A decision condition can be defined on one or more connectors that emanate from the user interact step. For more information, see Defining a Decision Condition on page 92.
Defining a Run-Time Event with a User Interact Step

A branch that emanates from a user interact step in an interactive workflow must be associated with a run-time event. An error occurs during validation if both of the following statements are true: The mode property for the workflow process is set to Interactive Flow The workflow process contains a user interact step that does not contain a run-time event defined on the outgoing branch
To avoid this error, if the run-time event is not required or not used in the user interact step, then change the Workflow Mode property of the workflow process to 7.0 Flow. For more information, see About the Workflow Mode Property on page 127.
Using a User Interact Step to Dynamically Set the Name of a View

You can associate the name of a view with a process property so that the view name can be set dynamically at run time. You do this by assigning the name of the view to the run-time value of a process property.
86
To use a user interact step to dynamically set the name of a view

In the User Interact View property of a user interact step, type the following string: [&ProcessPropertyName] The Workflow Engine recognizes this string and assigns the view name at run time.
About the Wait Step

The wait step is a type of step in a workflow process that allows you to suspend execution of the process for a specific amount of time, or until a specific event occurs. You can pause the instance of a process in units of seconds, minutes, hours, or days. In addition, you can define a service calendar to account for business hours and days. If a workflow process includes a wait step, then by default it is persistent. The wait step is often used for testing and development purposes. Unlike the Siebel operation step, the wait step can be used without affecting metadata of the business component or user data. For an example that uses the wait step for testing, see Defining a Run-Time Event within a Many to One Relationship on page 158.
Defining a Wait Step

You can define a wait step to pause the instance of a workflow process.
To define a wait step 1 2 3

Add a wait step to a workflow process. For more information, see Adding a Step to a Workflow Process on page 66. Make sure the step you added in Step 1 is still chosen in the Process Designer. Make sure the Workflow Mode property for the workflow process is set to Interactive Flow. A wait step can only be used in an Interactive Flow. For more information, see About the Workflow Mode Property on page 127.
4 5
Make sure the wait step is chosen in the Process Designer. Define input and output arguments for the wait step in the MVPW. For more information, see About the Process Property on page 47. If defining a duration argument that is greater than 60 seconds, then define minutes or a larger unit of measure so that data of the business component is refreshed. The workflow process is resumed from the Workflow Process Manager when units of minutes or higher are defined. A wait step with a duration that is measured in something other than seconds is automatically persistent.
87
SleepMode and the 7.0 Workflow Process

If the Workflow Mode property for a workflow process is set to 7.0 Flow, then the SleepMode input argument allows you to define how the wait step resumes the workflow: If set to the default Local value, then the workflow process is resumed within the session that launched the workflow. If set to Remote, then the workflow process is resumed on the server by the Workflow Process Manager server component. A component request for the Workflow Process Manager server component is created that runs at the time determined by the Duration input argument on the wait step.
If the Workflow Mode property for a workflow process is set to something other than 7.0 Flow, then the SleepMode input argument is ignored and the mode is Remote. For more information, see About the Workflow Mode Property on page 127.
Processing Mode Property of a Wait Step

There are performance considerations when choosing between synchronous and asynchronous for the Processing Mode property on the wait step. For more information, see Server Requests Business Service on page 482.
SetFieldValue and the Processing Mode It is recommended that when SetFieldValue is used to start a workflow process that the Processing Mode property be set to Local Synchronous. SetFieldValue can occur without committing data. Therefore, setting the Processing Mode to Remote Synchronous or Remote Asynchronous when using SetFieldValue can result in a workflow running out of process, and the workflow is not able to access the uncommitted data for the workflow.
About the Stop Step

The stop step is a type of step in a workflow process that is used to display an error to the end user and terminate the instance of the workflow. The main parts of defining a stop step for a workflow process include:
1 2
Defining a Stop Step on page 89 Defining a Custom Error Message on a Stop Step on page 90
NOTE: If using a stop step in a subprocess, then the stop step stops the subprocess and it also stops the parent workflow process that starts the subprocess. It is not necessary to define a stop step in the parent workflow in order to stop the subprocess from executing.
88
Table 14 describes the way the stop step is handled, depending on how it is called and in which object manager it is running.
Table 14. Situation
How Workflow Process Manager Handles a Stop Step Where Process Runs Not applicable Work Performed by the Workflow Process Manager Exits. Writes an error message to the log file. Writes an error message to the log file. Displays an error message to the end user.
A workflow policy calls a workflow process that contains a stop step. A script or a run-time event calls a workflow process that contains a stop step.
Workflow Process Manager Object Manager Application Object Manager
Defining a Stop Step

This topic describes how to define a stop step.
To define a stop step 1

Add a stop step to a workflow process. For more information, see Adding a Step to a Workflow Process on page 66.
2 3
Make sure the step you added in Step 1 is still chosen in the Process Designer. In the Properties window, In the Error Code property, choose a predefined error code from the picklist. For information, see Defining a Custom Error Message on a Stop Step on page 90.
4 5
In the Error Message property, enter an error message. Define input arguments for the step in the MVPW. For more information, see Arguments of the Step of a Workflow Process on page 49. No picklist is available for the Name field. The input arguments for a stop step are the substitution variables that appear in the error message. Substitution variables are identified by a percent sign (%). To define the substitution value, enter it in the Name field for the input argument. For example: %1.
Calling the Stop Step

It is recommended that the stop step be used only in a workflow process that is started from a script. For example, consider a workflow that displays a custom error message in a stop step. When the workflow is run, the custom error message displays that includes stack information that you must suppress. It is not possible to suppress stack information with a stop step.
89
However, a workflow process that is started from a script can contain an end step that defines the error message in a process property. If the workflow encounters the required decision condition, then the process property that contains the error message is sent. Because the subsequent step is an end step that does not display messages, control is returned to the calling script that checks for the value that is set in the process property, then uses RaiseErrorText() to display the message. The error dialog displays the error text but does not display workflow or stack trace information.
Defining a Custom Error Message on a Stop Step

If none of the predefined error messages that are provided in the Error Code property on the stop Step meet your requirements, then you can define a custom error message on the stop step.
To define a custom error message on a stop step 1 2

Add a stop step to your workflow process. Click the stop step, then use the Properties window to set the Error Code property to WF_ERR_CUSTOM_1. The Error Message property defaults to %1.
Define a new input argument in the MVPW for the stop step. For more information, see Arguments of the Step of a Workflow Process on page 49.
Set the Name field to the value that is displayed in the Error Message property in the Properties window. In this case, that value is %1.
Enter the custom text message in the Value field. If you define the input argument in this way, then the value you define is used in the %1 variable.
Multiple Custom Error Messages for a Stop Step Several customizable codes are available in the Error Code property on the stop step. These are indicated by WF_ERR_CUSTOM_x. Because each WF_ERR_CUSTOM_x is unique, it can only be used for a one time, specific purpose. If you must display multiple custom error messages, then use WF_ERR_CUSTOM_2, WF_ERR_CUSTOM_3, and so forth, instead of using %1, %2 for the same WF_ERR_CUSTOM_x.
About the End Step

An end step is a type of step in a workflow process that specifies when the instance of a workflow process is finished. It also provides one last chance to store output arguments to a process property. Each workflow must contain at least one end step. For more information, see Defining an End Step on page 91.
90
Differences Between the End Step and the Stop Step

An important difference between the stop step and the end step is that the stop step sets the state for the workflow process to In Error, while the end step sets the state to Completed. It is important to consider this situation if you use the Workflow Monitor Agent to call a workflow. If the Ignore Errors parameter of the Workflow Monitor Agent is set to False, then a workflow that encounters a stop step causes Workflow Monitor Agent to exit with error. If the workflow encounters an end step, then Workflow Monitor Agent does not exit with error.
Defining an End Step

You define an end step in the Process Designer in Siebel Tools.
To define an end step 1

Add an end step to a workflow process. For more information, see Adding a Step to a Workflow Process on page 66.
2 3
Make sure the step you added in Step 1 is still chosen in the Process Designer. Define output arguments for the step in the MVPW. For more information, see About the Process Property on page 47.
About the Workflow Connector

You can define properties for the connector in a workflow process by using the Properties window from within the Process Designer. For information about the properties of a connector, see Table 86 on page 459. For information about defining a run-time event on a connector, see Starting a Workflow Process from a Run-Time Event on page 144.
91
Steps and Connectors of a Workflow Process Defining a Decision Condition
Defining a Decision Condition

This topic includes the following topics: Defining a Branch Connector on page 92 Defining a Decision Condition on a Branch Connector on page 95
Conditional logic for a workflow process is implemented by defining conditions and values that affect the flow of the workflow. Different actions can occur depending on which path is followed. For example, you can define a decision condition that is based on the value of a priority field so that if the priority is equal to high, then the workflow pursues a branch that leads to an action that sends an email to a vice president. However, if the priority is equal to medium, then the email is sent to an engineer. Steps of a workflow where a decision condition can be defined include: Start step Decision point Wait step User interact step
Table 15 describes example workflow processes you can view that use a decision condition.
Table 15.
Examples of Workflow Processes that Use a Decision Condition Work Performed Insert an activity for the parent opportunity. Location Defining a Decision Condition for the Decision Point on page 259
Conditional Logic An IF/THEN decision condition, where flow is determined by the Revenue field in the Opportunity business component being greater than $10,000. A CASE statement, where one of several different branches is pursued, depending on the value of the Priority field in the Service Request business component.
Insert an activity with a value of a commit time that is based on the result of the CASE statement.
Example of Defining a Workflow Process That Manages Creation of a Service Request on page 292
Defining a Branch Connector

A branch connector is a type of connector in a workflow process that can contain a decision condition. Conditional logic is defined on a connector that emanates out of the step, and not on the step itself. Typically, a branch connector emanates from a start step, decision point, wait step, or user interact step.
92
To define a branch connector 1

Drag, then drop a connector from the palette to the canvas, connecting the decision point with the new next step. Make sure that the connector is correctly attached. For more information, see Diagramming a Workflow Process on page 122.
2 3
Make sure the connector you added in Step 1 is still chosen in the Process Designer. In the Properties window, enter or modify the connector name. The connector name must be unique to the workflow process. If it is not unique, then you cannot commit the record.
Choose a connector Type. In most cases, this value is Condition or Default. If you define a decision condition on the connector, then choose Condition. If the connector is used as an exit route, then choose Default. Other values can also be set. For more information, see Table 86 on page 459. If you define multiple branches on this step, then, for caution information, see Defining Multiple Branches on a Single Step on page 93.
5 6
Enter comments. Define the decision condition, if necessary. If the connector is used to incorporate conditional logic, then use the Compose Condition Criteria dialog box. For more information, see Defining a Decision Condition on a Branch Connector on page 95.
Defining Multiple Branches on a Single Step

A start step, decision point, wait step, or user interact step can each reference multiple branch connectors. CAUTION: If you define multiple branch connectors, then make sure to define at least one connector with the Type property set to Default, thereby providing an exit route in case a work item does not meet any of the decision conditions.
To define multiple branches for a single step in a workflow process

Perform the procedure described in Defining a Branch Connector on page 92 for each branch that you must define for the step. Each branch can contain a separate decision condition.
Comparison of Branching Declaratively to Programming with a Script

You can implement branching declaratively, as in multiple branches that emanate from a single step in a workflow process. In some cases, you can achieve the same result through a script, as in scripting on a business service.
93
For example, assume a STATUS field references a List of Values (LOV), and this LOV itself contains 120 values. If the user updates the STATUS field, then a workflow process performs 100 different updates in three related business components. This workflow contains a start step that checks for 120 decision conditions, then uses 100 different branches that, in turn, update the relevant business component. As an alternative, you can define a workflow process that contains a scripted business service. In this workflow, the STATUS is sent to the business service. The business service computes, then propagates the outcome to the business components either through the same business service or through a separate Siebel operation step in the workflow process. Conclusions that can be drawn from this example include: Effectively, there are no limitations on the number of outgoing branches on a start step or a decision step. One hundred and twenty steps with 120 branches in a workflow process can provide the same performance as implementing the same logic through eScript on a business service. For this kind of programmatically intense operation, eScript is probably a better choice. A workflow process with 120 branches is cluttered, while the implementation would be cleaner and easier to maintain in eScript. Conversely, it is recommended to use a declarative technique to address more common requirements.
Branching and Parallel Processing

Parallel processing is not supported with Siebel Workflow. Make sure you define decision conditions so that the workflow can only proceed along one connector. If conditions are defined in such a way that flow can proceed simultaneously along multiple connectors, then the exact run-time behavior of the Workflow Engine cannot be accurately predicted.
94
Defining a Decision Condition on a Branch Connector

You define a decision condition on a branch connector by using the Compose Condition Criteria dialog box. A branch connector can be a connector that emanates from a start step, decision point, wait step, or user interact step. Values listed in the Compose Condition Criteria dialog box are constrained by the value that is defined in the Business Object property for the workflow process. For an example that uses conditional logic on a connector, see Defining a Decision Condition for the Decision Point on page 259.
To define a decision condition on a branch connector 1 2 3

In the Process Designer, right-click the connector on which you must define a decision condition. Choose Edit Conditions. The Compose Condition Criteria dialog box displays. Compose a condition. For more information, see Decision Conditions for a Workflow Process on page 188.
Click OK.
95
96
Developing a Workflow Process
This chapter describes how to develop a workflow process. It includes the following topics: Roadmap for Developing a Workflow Process on page 97 Process of Analyzing Business Requirements on page 99 Process of Planning a Workflow Process on page 104 Job Roles That Are Involved in Developing a Workflow Process on page 114
Roadmap for Developing a Workflow Process

Figure 17 illustrates the lifecycle for planning and developing a workflow process.
Figure 17. Lifecycle for Planning and Developing a Workflow Process The steps for developing a workflow process include:
97
Developing a Workflow Process Roadmap for Developing a Workflow Process
1 2 3 4
Analyze. Analyze your business requirements and the business rules and processes to be automated. Plan. Plan for building the workflow process. Build. Build the workflow process by defining workflow objects in Siebel Tools. Example objects include the object definition for the workflow process, process properties, and workflow steps. Test. Test your workflow process to make sure the objects you defined meet the business requirements. Testing includes validating and simulating the workflow process, then verifying functionality. Deploy. Deploy your workflow process by publishing object definitions of the workflow from the repository tables to the run-time tables, then activating the workflow for use in the Siebel client. Migrate. Migrate the tested workflow process to the production environment. You can use a utility, such as ADM, REPIMEXP, or Import/Export. Administer. Administer, monitor and troubleshoot the migrated workflow process in the production environment.
5 6 7
The lifecycle illustrated uses a linear flow, whereas the typical development cycle of a workflow process is iterative.
Processes That Are Involved in Developing a Workflow Process

To develop a workflow process, perform the following processes:
1 2 3 4 5 6 7
Process of Analyzing Business Requirements on page 99 Process of Planning a Workflow Process on page 104 Process of Building a Workflow Process on page 115 Process of Testing a Workflow on page 202 Process of Deploying a Workflow Process on page 211 Process of Migrating a Workflow Process on page 218 Process of Administering a Workflow Process on page 227
98
Developing a Workflow Process Process of Analyzing Business Requirements
Process of Analyzing Business Requirements

This process is a step in Roadmap for Developing a Workflow Process on page 97. To analyze business requirements, perform the following tasks:
1 2 3
Gathering Information for Planning a Workflow Process on page 99 Identifying Actions That a Business Process Performs on page 100 Identifying an Automation Solution on page 101
The first step in developing a workflow process includes analyzing your business requirements, where you determine the business rules and business processes that are automated by a workflow process. An implementation project team typically spends a significant amount of time performing requirements analysis, with this step requiring as much as 30% of the of the total implementation effort. A business analyst uses the Siebel application to define the processes to be automated, then determines the most appropriate automation solution. The developer who defines the workflow process often participates as a technical consultant during this analysis.
Gathering Information for Planning a Workflow Process

This task is a step in Process of Analyzing Business Requirements on page 99. You can gather information for workflow process planning.
To gather information for planning a workflow process 1

Gather existing as is information about the business process by looking at how your organization currently handles business processes. For more information, see Analyzing Existing Performance of a Business Process on page 99.
Gather desired should be information about how the business process must operate. For more information, see Determining Areas for Improvement on page 100.
Analyzing Existing Performance of a Business Process

Current business processes provide the basis of what you define when you use Siebel Workflow. If you currently use an automated system, then you must gather information on the business processes that are handled by that system. It is also important to understand the limitations or problems of the current system that you must address with a workflow process.
To analyze existing performance of a business process

Research the following areas for your current business process:

Existing process information Measures for improvement or new process requirements
99
The following sources might contain existing process information: Current business processes that are automated Management guidelines Written guidelines for business process rules or approval paths Written or unwritten internal procedures
For example, assume you must document the lifecycle for a new work item, such as a service request, from the moment the service request is opened to the moment it is closed. Include information about decision points in the business process, such as when a service request must be escalated or which approval path an order pursues when it is high priority compared with low priority.
Determining Areas for Improvement

After you gather the required information about existing business processes, review the information to determine if there are areas for improvement in the business process or whether a new business process is required.
To determine areas for improvement

Consider each of the following areas for improvement:

New management guidelines or business requirements that must be addressed Current problems that must be solved Areas you must make more visible Customer satisfaction issues Workflow processes you must automate
Identifying Actions That a Business Process Performs

This task is a step in Process of Analyzing Business Requirements on page 99. A business process consists of various actions that must be performed in order to meet business requirements. Siebel CRM provides a number of predefined actions. Some example predefined actions include: Notifications. Send an email, page, or fax. Siebel Operations. Insert or update information in the Siebel database. Integration Messages. Request to send or receive data from an external system. Assignment. Request Assignment Manager to assign an object. Navigation. Navigate a user to a specific view through a user interact step or a call to Siebel Task UI. Server Request. Request the Siebel Server Request Broker to run a server process.
100
Except for Siebel operations, these actions are started by calling a method on a business service. A predefined business service can be used to implement an action in a variety of settings and technical configurations. You might identify a specialized action that you are interested in calling in your workflow process, such as calculate credit risk. A specialized action can be added by defining a custom business service. A workflow process can call both a predefined and a custom business service. For more information, see Integration Platform Technologies: Siebel Enterprise Application Integration.
To identify actions a business process performs

Map the requirements you identified in Gathering Information for Planning a Workflow Process on page 99 to potential predefined Siebel actions.
Identifying an Automation Solution

This task is a step in Process of Analyzing Business Requirements on page 99. After you determine business process requirements and the actions that must be performed to meet those requirements, you can identify an automation solution.
To identify an automation solution 1 2

Map the business process requirement to the advantages and limitations of each solution. For more information, see Comparison of a Workflow Process to Other Solutions on page 102. Determine whether the requirement can be addressed with a workflow process or a workflow policy. For more information, see Requirement Mapping to a Workflow Process or Workflow Policy on page 103.
10 1
Comparison of a Workflow Process to Other Solutions

Table 16 compares a workflow process to other Siebel automation solutions.
Table 16. Solution Workflow Process
Comparison of a Workflow Process to Other Siebel Automation Solutions Advantages Advantages include: Visual representation of business logic is relatively simple to understand and maintain Remote synchronous and asynchronous execution allows compatibility across Siebel Business Applications for scalability and longrunning transactions Limitations Limitations include: The semantics for control are not as rich as with scripting Limited control of flow for iteration through record sets Limited direct access to object methods
Workflow Policy
Advantages include: Responds to a database event regardless of whether it is initiated by an Object Manager component or by a non Object Manager component Can realize higher transaction throughput on a set of hardware for a simple transaction
Limitations include: Changes to a policy can require database downtime to implement More difficult to define than other alternatives Allows a limited range of executable actions
Siebel Script
Advantages include: Familiar to many developers Provides a set of semantics Is flexible
Limitations include: Ease of maintenance Ease of upgrade Performance
102
Requirement Mapping to a Workflow Process or Workflow Policy

Table 17 summarizes some common requirements and recommends a workflow process or a workflow policy. For more information, see Chapter 14, Defining a Custom Workflow Policy.
Table 17.
Requirement Mapping to a Workflow Process or Workflow Policy Possible Solution Workflow Process Workflow Policy Description Workflow Process Manager and run-time events capture business layer logic. Workflow Policy Manager captures data layer logic. Data coming into the Siebel application through the data layer, for example EIM or MQ channels, is not captured through the business layer. This requirement typically indicates a potential candidate for a workflow policy. Workflow Policy A workflow policy can support some features that are not available or would be more difficult to implement with a workflow process. For example, email consolidation, duration, and quantity. A workflow process can provide pause, stop, and error handling capabilities.
Requirement Capture business layer logic. Capture data layer logic.
Implement features supported by a workflow policy but not a workflow process. Implement features supported by a workflow process but not a workflow policy. Implement complex comparison logic, or flow management. Call a business service. Perform bulk data uploads. Perform data quality cleaning in the data layer. Use a repeating component request. Repetitive, manual processing. Process an event in a timely fashion. Perform escalations and notifications.
Workflow Process
Workflow Process
A workflow process provides a better platform for development and deployment, complex comparison logic, and flow management, such as IF, THEN, ELSE, or CASE. A workflow process can call a business service. Workflow Policy Manager is the better alternative when bulk data uploads occur through EIM. Workflow Policy Manager is the most appropriate solution for working at the data layer. You can setup a workflow process from a repeating component request but not from a workflow policy. The structure of a workflow process provides a superior solution for repetition, timeliness, and cross functional routing through a business process.
Workflow Process Workflow Policy Workflow Policy
Workflow Process Workflow Process Workflow Process Workflow Process
10 3
Developing a Workflow Process Process of Planning a Workflow Process
Process of Planning a Workflow Process

This process is a step in Roadmap for Developing a Workflow Process on page 97. To plan a workflow process, perform the following tasks:
1 2 3 4 5 6 7 8
Determining the Mode of the Workflow Process on page 104 Determining How the Workflow Process Is Started on page 105 Determining Decision Logic of a Workflow Process on page 107 Determining Actions of a Workflow Process on page 109 Determining Error Handling on page 111 Examining Seed Workflow Processes on page 111 Determining Requirements for Managing the Development of Objects on page 112 Addressing Other Business Requirements on page 113
If your work in Process of Analyzing Business Requirements on page 99 determined that the workflow process is the most appropriate automation solution, then you can continue planning the workflow process. When planning a workflow process you determine how the process is built, including making design decisions, such as which workflow mode to use, the events to define, the rules to define, actions that the workflow process executes, and so forth.
Determining the Mode of the Workflow Process

This task is a step in Process of Planning a Workflow Process on page 104. A workflow process can persist for just a few moments, such as aiding a user with generating an email, or it can span days and job functions, such as creating a quote to cash. This characterization is handled by the Workflow Mode property of the workflow process.
To determine the mode of the workflow process

Map the business requirements to the most appropriate workflow mode. For more information, see About the Workflow Mode Property on page 127.
104
Determining How the Workflow Process Is Started

This task is a step in Process of Planning a Workflow Process on page 104. During the planning phase of a development effort you can determine if the workflow process is started by a run-time event, user event, workflow policy, or a script. For more information, see Starting a Workflow Process on page 143.
To determine how the workflow process is started

Consider the advantages and limitations of each mechanism that is available for starting a workflow process that are described in this topic, then choose the mechanism that most closely matches the business requirements.
Using a a Workflow Policy to Start a Workflow Process

A workflow policy starts a workflow process after a database change. If the workflow policy conditions are met, then an action occurs. In some cases, the action calls the Workflow Process Manager server component to execute a workflow process. Processing that is started by a workflow policy does not occur in real time. Typical uses of a workflow policy include: EIM batch processing Siebel EAI inserts and updates Manual changes from the user interface Assignment Manager assignments Siebel Remote synchronization
Using an Event to Start a Workflow Process

Types of events used by a workflow process include: Run-time event. A run-time event is based in the Object Manager and occurs when a change is encountered by the user interface or in the business component layer. Processing that is started by a run-time event occurs in real time. User event. A user event is a unique event that is internal to Siebel Workflow that starts or resumes a long-running workflow process. A user event is generated by the User Event business service.
An event belongs to three object types: Application object, Applet object, and Business Component object. An event can be defined from the administrative interface.
10 5
Using a Script to Start a Workflow Process

A script can start a workflow process programmatically as a business service. Using a script, you can start a workflow from an external system. The Workflow Process Manager server component provides APIs for using programmatic techniques to start a workflow. A script is raised by the Object Manager. A script can be associated with one of the following objects: application, applet, business component, and business service.
Summary of Mechanisms for Starting a Workflow Process

Table 18 summarizes the main uses and limitations for each of the mechanisms that are available to start a workflow process.
Table 18.
Uses and Limitations of Mechanisms for Starting a Workflow Process Uses Uses include: You must detect and react to data changes made outside of the Object Manager. For example, by Siebel Remote or by Siebel EIM Limitations Limitations include: Making changes requires database downtime Relatively complex to define
Starting Mechanism Workflow Policy
Event
Uses include: You must implement a basic entry point for a workflow or a simple custom action You must avoid distributing the Siebel Repository File (SRF). For example, because of the burden created for mobile users
Limitations include: Cannot directly respond to an event by scripting against the event object Can be more difficult to pass the event context to business logic Does not trap data changes made by non Object Manager components
Script
Uses include: You require flexibility to write a script directly in response to an event You require access to an applet event that is only exposed in Siebel Tools
Limitations include: Changes must be distributed through a new Siebel Repository File (SRF) Does not detect data changes made by non Object Manager components. For a workflow, the script is implemented on a Siebel Tools Object Event.
106
Determining Decision Logic of a Workflow Process

This task is a step in Process of Planning a Workflow Process on page 104. When planning to build a workflow process, you can determine the decision logic that guides the flow of control within the process.
To determine decision logic of a workflow process 1

Examine the business analysis work conducted thus far to identify what decision conditions, if any, are inherent in the business process. For more information, see Overview of Objects That Are Used with a Workflow Process on page 18.
Map the requirements to the workflow process decision logic. For more information, see Ways to Implement Decision Logic in a Workflow Process on page 107.
Ways to Implement Decision Logic in a Workflow Process

Table 19 describes some ways to implement decision logic in a workflow process.
Table 19. Type
Ways to Implement Decision Logic in a Workflow Process Description A step in a workflow process that arbitrates between one or more alternative branches in the flow of the workflow. Each connector that emanates from a decision point can contain one or more decision conditions. If the conditions evaluate TRUE for the connector, then flow proceeds down the branch represented by the connector. Uses When you require a simple articulation of whether one or more alternative branches in the flow must be executed. Limitations Conditional expressions lack support for some key operators, including: AND operator OR operator Order of precedence control, as determined by parentheses
Workflow Decision Point
Scripted Business Service
A script within a business service action step that evaluates a potentially complex set of inputs and returns a simplified output that can be evaluated by a workflow decision point.
When decision point semantics for a workflow process are not sufficiently expressive to encapsulate the required decision logic.
Undermines the readability and simplicity of the workflow by hiding decision logic within a business service.
10 7
Table 19. Type Wait Step
Ways to Implement Decision Logic in a Workflow Process Description The wait step allows you to suspend the execution of a workflow process for a defined amount of time or until a specific event occurs. Uses When you must support a time based escalation or a longrunning workflow that can last for days or weeks. For example, waiting for a customer response. When it is deemed appropriate to use a specialized decision framework, such as when you must assign work to a person based on the workload for the person. Limitations The releasing event must be called through the Object Manager.
Other Specialized Decision Frameworks
Other decision frameworks can be used directly or indirectly by a workflow process, such as personalization rules, assignment rules, EAI Dispatch Service, or the Siebel rules engine. The Siebel rules engine allows you to maintain the logic of a business process declaratively and in a location that is external to your Siebel applications. For information, see Siebel Business Rules Administration Guide.
Limitations vary depending on the decision framework that is used.
Decision Conditions with the Decision Point A decision condition is used to evaluate the logical flow that must be taken on a branch in a workflow process. A decision point can exist with multiple connectors that represent logical branches. For each connector that provides branching, a decision condition is evaluated. A decision condition makes a comparison between two of the items in the following list: Process properties Business component fields Literal values
The terms of comparison include: Two values are equivalent. One value exists among a series of others. For example, child record values, One Must Match, or All Must Match. Greater than (>) or less than (<). Between or Not Between. Null or Not Null.
108
For an example of the Compose Condition Criteria dialog box that displays decision criteria, see Defining a Decision Condition for the Decision Point on page 259. For a description of properties in the Compose Condition Criteria dialog box, see Defining a Decision Condition on a Branch Connector on page 95.
Determining Actions of a Workflow Process

This task is a step in Process of Planning a Workflow Process on page 104. You can determine the actions that the workflow process must execute.
To determine actions of a workflow process

Identify the type of workflow actions that are required in order to meet the business requirements. For more information, see Overview of Objects That Are Used with a Workflow Process on page 18, and Data Manipulation in a Workflow Process on page 109.
Data Manipulation in a Workflow Process

A workflow process operates on business objects and business components. Typically, a workflow process is associated with a single business object. Within the context of these data layer objects, data is generated or updated as the workflow executes. The main types of data a workflow manipulates include: Business component data Process property data Siebel Common Object data
A process property can be thought of as a local variable that is active during execution of the instance of the workflow process. The process property can be used as input and output to the various steps in a workflow. A set of predefined process properties is automatically generated when you define the workflow. The Process Instance Id is one example of a predefined process property. For more information, see About the Process Property on page 47.
10 9
Uses and Limitations of an Action in a Workflow Process

Table 20 describes the uses and limitations of an action in a workflow process.
Table 20.
Uses and Limitations of an Action in a Workflow Process Description A workflow step that calls a method of a business service. The business service can be a prebuilt Siebel service or a scripted business service. Uses When you must execute a potentially complex, but reusable set of logic. Limitations Defining and destroying business services can be expensive. Overhead can be reduced through caching. Incorporating too much logic within a business service can limit reusability for the business service and the transparency of the workflow. When you must execute simple record operations within the workflow. While it is possible to update multiple records based on a search specification, it is not possible to retrieve and iterate through a set of records such that subsequent actions for the workflow process can execute for each record.
Action Type Business Service Step
Siebel Operation Step
A workflow step that performs inserts, updates, and queries against Siebel business components.
Actions with the Business Service Step

The business service step executes predefined or custom business service methods. Typical business services that are predefined include Assignment Manager requests, notification through the Communications Server, server requests, and integration requests from Siebel EAI. Custom business services can be written in Siebel VB or eScript. If defining a business service step, then you must define the business service, the business service method, and input arguments and output arguments. Input arguments are passed in a process property, business component data, or a literal value. The following list describes some business services that commonly used in a workflow process: Outbound Communications Manager Synchronous Assignment Manager Requests Server Requests Business Rule Service Report Business Service Audit Trail Engine EAI business services, such as EAI Siebel Adapter, EAI XML Converter, and so forth
110
FINS Data Transfer Utilities and FINS Validator
For more information, see About the Business Service Step on page 70, and Predefined Business Services on page 482. If you require specialized functionality, then you can define a custom business service for the specific activity. A business service can be defined in Siebel Tools or in the administration screens of the Siebel client. For more information, see Integration Platform Technologies: Siebel Enterprise Application Integration.
Actions with the Siebel Operation Step

The Siebel operation step allows you to perform database operations, such as Insert, Update, Upsert, Query, Delete, NextRecord, PreviousRecord, and QueryBiDirectional. The Siebel operation step is based on a single business component. After you define the Siebel operation step, you can use the Search Specification to locate the records that you must manipulate. Examples of a Siebel operation step include generating an activity when a new SR is created, or updating a comment field if an SR is open too long. For more information, see About the Siebel Operation Step on page 75.
Determining Error Handling

This task is a step in Process of Planning a Workflow Process on page 104. Error handling options range from a simple solution of using a stop step in a workflow process, to defining a separate error-workflow process. The planning phase is an appropriate time to plan for how to recover from a failed workflow. For more information, seeHandling Errors on page 164.
To determine error handling 1 2

Determine what, if any, error handling is necessary to meet the business requirements. Identify the error handling action that is required to meet the business requirements.
Examining Seed Workflow Processes

This task is a step in Process of Planning a Workflow Process on page 104. A seed workflow process is a workflow process that comes predefined with the product. Before building a new workflow, you can determine whether a seed workflow already exists that meets your business requirements.
11 1
To examine seed workflow processes 1 2

In Siebel Tools, click Workflow Process in the Object Explorer. Scroll through the Workflow Processes OBLE, scanning the Process Name property for a potential candidate. Seed workflow processes include workflows that appear in the Workflow Processes OBLE immediately after Tools is installed but prior to new workflow processes being defined.
Use the Process Designer in Siebel Tools to further examine potential candidates that you identify in Step 2. To determine whether or not it is appropriate to use a copy of the seed workflow process, consider the level of modification that is necessary to meet the business requirements.
If you identify a candidate workflow process, then make a copy of it and modify the copy. Because seed workflow processes are used to execute some of the base functionality of the Siebel application, they must not be edited. Instead, create a copy of the seed workflow, then edit the copy. For more information, see Copying a Workflow Process on page 118.
Determining Requirements for Managing the Development of Objects

This task is a step in Process of Planning a Workflow Process on page 104. When planning a workflow process, you can determine requirements for managing the development of objects, such as whether there are special requirements for merging, archiving, and importing data maps, or copying message tables. If a team of developers is involved in the development environment, then you can consider how project check in and check out can be used.
To determine requirements for managing the development of objects 1 2

Consider the number of developers that are involved in the project and the requirements of their development environments. Choose a mechanism for managing objects. For more information, see Object Management in Siebel Tools on page 112.
Object Management in Siebel Tools

When you develop a workflow process in Siebel Tools, you work on a local database where Siebel Workflow is a repository object, and where a workflow belongs to a project. Though compiling a Siebel Repository File is a standard practice for other repository objects, a workflow process uses a different deployment mechanism. You do not compile an SRF after you develop a workflow. For more information, see Process of Deploying a Workflow Process on page 211.
112
Although these behaviors are standard for other repository objects, the behaviors that a workflow process does not participate in include: Merge. A workflow process does not participate in three way merge. If a workflow is imported into the repository, then it maintains versioning provided by the workflow. Object Comparison. The object comparison mechanism is disabled in Siebel CRM version 8.0. Archive. A workflow process does not participate in the usage of sif files for archiving. Instead, a workflow can be archived as an XML file using the Siebel Workflow export utility.
Typically, a developer uses a local database to develop a workflow process. If you are using a local database, then you must check out the workflow from the master repository. If you are developing a workflow process on a local database, then the local database must contain the referenced data objects. For those data objects that are not docked and hence not packaged as part of the database extract, the developer must import them into the local database. Objects not docked or referenced by Siebel Workflow include: Data maps. To import a data map to the local database, you use the Siebel Developer Web Client connected to the local database, and the import utility on the client. Message tables. You can copy a message table to the local database. Alternatively, you can define a message using the unbounded picklist. While this mechanism allows for the creation of messages, it does not check the validity of the message at definition time.
By locking the project in the master repository, you can also develop or modify a workflow process by using Siebel Tools that is connected to the development database. This way, it is not necessary for you to make sure lists of values are made available to the local database.
Addressing Other Business Requirements

This task is a step in Process of Planning a Workflow Process on page 104. Consider your development and implementation environment in order to determine whether you must address other business requirements.
To address other business requirements

Consider some of the other business requirements you can address during the planning phase:
Use the Workflow Process Batch Manager to run a workflow process against records in a business component at a predetermined interval. For more information, see Using Batch Processing on page 172.
If the workflow process is implemented in a multilingual environment, then address globalization. For more information, see Defining a Workflow Process for a Multilingual Environment on page 175.
11 3
Developing a Workflow Process Job Roles That Are Involved in Developing a Workflow Process
Job Roles That Are Involved in Developing a Workflow Process

Job roles are presented in this topic in order to assist with describing the design and development efforts that required to implement a workflow process . Job roles, job titles, and division of labor might vary significantly for your organization. The following job roles are associated with developing a workflow process: The business analyst considers business requirements for your organization and determines the processes to be automated. The workflow configurator uses Siebel Tools to build a workflow process and to define objects, business services, and programs. Your organization can use the predefined objects, business services, or programs that are provided in the application. The workflow configurator can also define custom objects, business services, and programs in Siebel Tools. A business service can also be defined in the Siebel client. For more information, see Integration Platform Technologies: Siebel Enterprise Application Integration. The workflow administrator monitors a workflow process in the Siebel client by using Siebel Workflow. The Workflow Administrator also activates a workflow policy by generating database triggers in a script and defining them in the Siebel database. The Workflow Administrator then starts the Siebel server processes that execute the workflow and policy. This person is typically a system administrator, database administrator, or someone from the Information Services department. The end user uses the Siebel client and causes the workflow process and policy to execute. This person is typically an employee of your organization, and can also be a customer.
114
Process of Building a Workflow Process
This chapter describes the process you must perform to build a workflow process. This process is a step in Roadmap for Developing a Workflow Process on page 97. To build a workflow process, perform the following tasks:
1 2 3 4 5
Preparing Siebel Tools to Develop a Workflow Process on page 115 Defining a Workflow Process on page 117 Diagramming a Workflow Process on page 122 Defining a Process Property for a Workflow Process on page 124 Defining a Property for the Step of a Workflow Process on page 126
For an example that details how these steps are performed, see Example of Defining a Workflow Process That Creates an Activity for a Sales Representative on page 255.
Preparing Siebel Tools to Develop a Workflow Process

To develop a workflow process, you begin by preparing Siebel tools.
To prepare Siebel Tools to develop a workflow process 1

Set the following parameter in the [Workflow] section of the configuration file of the application: VerCheckTime = -1 Setting VerCheckTime to -1 allows you to use the Publish/Activate button. The configuration file is typically in the language directory for the client. For example: Siebel\81\21031\MWC\BIN\ENU\uagent.cfg where:

ENU is the language directory uagent.cfg is the configuration file
For more information, see Buttons on the WF/Task Editor Toolbar on page 62.
2 3 4
Log in to Siebel Tools. From the application-level menu, choose the View menu, Toolbars, then the WF/Task Editor Toolbar menu item. From the application-level menu, choose the View menu, Toolbars, then the Simulate menu item.
11 5
Process of Building a Workflow Process Preparing Siebel Tools to Develop a Workflow Process
Expose the object types that are used to develop a workflow process. For more information, see Exposing Object Types That Are Used to Develop a Workflow Process on page 116.
If necessary, expose business service objects. A business service object can contain hidden properties. In order for a business service, business service method, or business service method argument to be displayed on a dropdown list in Siebel Tools, the Hidden property for the object must be set to FALSE.
Exposing Object Types That Are Used to Develop a Workflow Process

This topic describes how to expose object types in the Object Explorer that are used to develop a workflow process.
To expose object types that are used to develop a workflow process 1 2 3 4

Log in to Siebel Tools. From the application-level menu, choose the View menu, then the Options menu item. Click the Object Explorer tab. Scroll down through the Object Explorer Hierarchy window to locate the Workflow Process object type, then expose it by making sure the Workflow Process object and all child objects for it contain a checkmark. Repeat Step 4 for the Workflow Policy Object object type. Repeat Step 4 for the Workflow Policy Program object type. Make sure the Workflow Policy Column object contains a checkmark. (Optional) Expose other object types that might be used to develop a workflow process:

5 6 7 8
Expose the Command object type. Expose the Toolbars object type. Repeat Step 4 for the Business Object object type.
Click OK.
116
Process of Building a Workflow Process Defining a Workflow Process
Defining a Workflow Process

This task is a step in Process of Building a Workflow Process on page 115. The first part of building a workflow process is to define the top level object definition for the workflow. This topic includes the following topics, each of which describes a possible option for defining a workflow: Reviewing Workflow Processes on page 117 Copying a Workflow Process on page 118 Modifying a Workflow Process on page 118 Revising a Workflow Process on page 119 Defining a New Workflow Process on page 120
This topic also includes the following related topics: Naming a Workflow Process on page 120 Externalizing Workflow Properties on page 120 Making a Workflow Process Editable on page 120 Deleting a Workflow Process on page 121
For more information, see About the Object Hierarchy of a Workflow Process on page 39.
Reviewing Workflow Processes

Review existing workflow processes to determine if the workflow you require is already available, or if a similar workflow exists that you can copy and modify in order to meet your requirements. The Object List Editor (OBLE) for Workflow Processes displays a list of object definitions for workflows. You can access the Workflow Processes OBLE in Siebel Tools.
To review existing workflow processes 1

In Siebel Tools, in the Object Explorer, click Workflow Process. The right pane displays the Workflow Processes OBLE, which lists object definitions for the workflow processes.
2 3
Examine the list of existing workflow processes, perusing the Process Name, Business Object and Workflow Mode properties for a combination of properties that meet your business requirements. If you find a workflow process that is a potential candidate, then right-click the workflow in the Workflow Processes OBLE, choose Edit Workflow Process, then use the Process Designer to examine the flow of steps as well as process and step properties. If you find a workflow process that you must copy as the basis for a new workflow, then rightclick the workflow, and then choose Copy Record. For more information, see Copying a Workflow Process on page 118.
11 7
Copying a Workflow Process

If your intent is to define a different workflow process, with a different name and a different purpose, then you can copy an existing workflow. The copied workflow does not replace the original workflow. In contrast to revising a workflow, when you copy a workflow, you define a new workflow that is identical to the original one, except that a unique name, such as 04-K88GQ, is generated for it. The version of a new, copied workflow is 0. If you revise a workflow, then the version is the next integer that is subsequent to the version number of the original workflow that is being revised.
To copy a workflow process 1

Locate the workflow process you must copy. For more information, see Locating a Workflow Process in the Workflow Processes Object List Editor on page 43.
Right-click the workflow process in the Workflow Processes OBLE, then chose Copy Record. A new copy of the workflow process is generated and displayed in the Workflow Processes OBLE and a unique numeric identifier appears in the Process Name property.
3 4
Update the Process Name property so it is meaningful. Modify the other properties, as necessary, for the new workflow process.
Modifying a Workflow Process

You can modify an existing workflow process without restarting the Workflow Process Manager. A workflow is refreshed in the process memory as soon as it is activated. If a new workflow is deployed, then the cache is refreshed, so a new instance picks up the newly deployed workflow. To modify a workflow process, you must make it editable. For more information, see Making a Workflow Process Editable on page 120.
Cache Refresh for a Workflow Process

The timing of when a workflow process is activated affects the process cache: The caches of threads in the same workflow process are refreshed and these threads get the updated workflow immediately. The caches of threads in other workflow processes are not refreshed until the interval defined by the server parameter named VerCheckTime expires.
For a mobile client and a development client, the server parameter named Workflow Version Checking Interval (VerCheckTime) controls how often the server component checks for new active versions of each workflow process. If a new workflow is activated, then an incoming workflow instance that is created during the interval that is determined by Workflow Version Checking Interval uses the new definition for the workflow. An instance of the workflow is initiated before the interval uses the previous definition for the workflow.
118
Scenarios to consider include: Activation in a thin client. If a workflow process is activated from a thin client, such as the Call Center application, then user sessions in the same Call Center application server process get the updated workflow immediately. However, user sessions in other server processes must wait for the VerCheckTime interval that is defined in the server process configuration before they receive the updated workflow. Activation in a mobile or development client. Each mobile or development client constitutes a separate process. The particular mobile or development client receives the updated workflow process immediately. Other mobile or development clients must wait for the VerCheckTime interval that is defined in their configuration files before they can receive the updated workflow. Publish/Activate in Siebel Tools. The Siebel Tools application constitutes a separate process. A thin client and mobile or development client must wait for the VerCheckTime interval before the client can receive the updated workflow process.
Reloading Run-Time Events

Refreshing the workflow process cache is necessary but not sufficient for running the updated workflow process correctly. If the workflow contains a run-time event, then the run-time event cache must also be refreshed.
To reload run-time events for a thin client 1 2

In the Siebel client, navigate to the Administration-Runtime Events view. Right-click the context menu, then choose Reload Runtime Events.
To reload run-time events for a mobile client

Log out of, then log back in to, the mobile client. This guarantees that the cache of the workflow process is refreshed.
Revising a Workflow Process

To revise a workflow process, you modify the existing object definition for the workflow. If you revise a workflow, then the new workflow that is generated is the same as the original, with the same name, except that the version for the workflow is incremented by one, the Status is In Progress rather than Completed, and the workflow is editable. The revised workflow replaces the original workflow.
To revise a workflow process 1

Locate the workflow process you must modify. For more information, see Locating a Workflow Process in the Workflow Processes Object List Editor on page 43.
11 9
In the WF/Task Editor toolbar, click Revise. For more information, see About the Process Property on page 47.
3 4
Right-click the new workflow process, then choose Edit Workflow Process. Modify this new version, as necessary.
Defining a New Workflow Process

If you cannot locate an existing workflow process that meets your requirements, then you can define a new one. For an example, see Defining the New Workflow Process on page 256.
Naming a Workflow Process

When naming a workflow process, the combination of workflow process name and version must be unique. That is, two workflow processes can contain the same name as long as their version numbers are unique.
Externalizing Workflow Properties

When developing a workflow process, it is recommended that you define properties for the workflow that are externalized and that are not hard coded. Hard coding a property in a workflow requires you to change the definitions when the workflow is deployed between environments. For example, if a workflow sends an email to a list of customers and the property is hard coded with the customer list, then the workflow does not execute correctly in the production environment. You must make sure such input arguments are read dynamically. For more information, see Example of Externalizing Properties when Using a Business Service on page 316.
Making a Workflow Process Editable

The canvas color in the Process Designer indicates whether the workflow process is editable. For more information, see About the Process Designer on page 44.
To make a workflow process editable 1 2 3

Make sure the workflow process is either checked out or is locked by the developer who is currently attempting to edit the workflow process. Make sure the project that is defined in the Project property for the workflow process is locked. If the workflow process is a seed workflow, then make a copy of the workflow and edit the copy. For more information, see Examining Seed Workflow Processes on page 111.
120
If you still cannot edit an existing workflow process, then export the workflow to your desktop, and then import the workflow. The Version property for the editable version increments by 1. For more information, see Importing and Exporting a Workflow Process on page 224.
Deleting a Workflow Process

You can delete a workflow process in the Object List Editor in Siebel Tools.
To delete a workflow process 1

Locate the workflow process you must delete. For more information, see Locating a Workflow Process in the Workflow Processes Object List Editor on page 43.
Right-click the workflow process, then choose Delete Record. You cannot delete a seed workflow process. For more information, see Examining Seed Workflow Processes on page 111.
12 1
Process of Building a Workflow Process Diagramming a Workflow Process
Diagramming a Workflow Process

This task is a step in Process of Building a Workflow Process on page 115. Diagramming process steps is an important part of defining a functioning workflow process. The flowchart interface of the Process Designer allows you to build a visual representation of the entire flow, including decision points and conditional logic. You can choose to define the details for each step as you define each step in the Workflow Designer, or you can define the entire flow, then enter details for each step. For more information, see About the Process Designer on page 44.
To diagram a workflow process 1

Drag, then drop a Start step from the palette to the canvas. A workflow process must contain only one Start step. For more information, see About the Start Step on page 69.
Drag, then drop one or more middle steps from the palette to the canvas. A workflow process can contain one or more steps that perform an action, such as a business service, decision point, sub process, task, stop, wait, or Siebel operation. There can be more than one of each type of step in a workflow. For more information, see Types of Steps of a Workflow Process on page 69.
Drag, then drop an end step from the palette to the canvas. A workflow process must contain at least one end step. For more information, see About the End Step on page 90.
Define the flow and path of the workflow process by dragging and dropping a connector from the palette to the canvas. Position one end of the connector on one side of a step, then drag the connector handle to connect the other end of the connector to the next step in the flow. NOTE: A connector end point that is colored white is not connected correctly to a step. A red end point indicates that the connector is correctly connected. Make sure both ends of every connector in the workflow process is colored red.
Repeat Step 4 until every step in the workflow process is connected correctly.
A connector that emanates from certain step types can provide conditional logic for the workflow process. For more information, see Defining a Branch Connector on page 92.
Displaying the Label for a Connector

You can hide or display the text that is displayed as a label on a connector. In some cases, you might prefer to suppress this text. For example, you can hide the text label for the connector that emanates from the Start step, which defaults to Connector 0.
122
Process of Building a Workflow Process Diagramming a Workflow Process
To display the label for a connector 1 2

In the Process Designer, right-click the connector on which you must display or hide the label. From the pop-up menu, choose the Edit menu, then the Hide Text menu item. The label for the connector is hidden.
To display the label, repeat Step 2.
Adding or Removing a Point in a Connector

You can add or remove a point in a connector.
To add or remove a point in a connector 1 2

Click the connector or error exception connector. Right-click, then choose one of the following options:

Choose the Edit menu, then the Add Point menu item Choose the Edit menu, then the Remove Point menu item
12 3
Process of Building a Workflow Process Defining a Process Property for a Workflow Process
Defining a Process Property for a Workflow Process

This task is a step in Process of Building a Workflow Process on page 115. You can define a process properties in either the Multi Value Property Window (MVPW) or in the WF Process Props OBLE. You can define process properties as you diagram a workflow process, or you can diagram the entire workflow, then define properties for individual steps. However, it is recommended that you define process properties before defining an input or output argument on an individual step because some of those arguments can reference a process property. For more information, see About the Process Property on page 47.
To define a process property for a workflow process 1

2 3
Right-click the workflow process, then choose Edit Workflow Process. From the application-level menu, choose the View menu, Windows, then the Multi Value Property Window menu item. For more information, see Multi Value Property Window on page 50.
4 5 6 7
Click the canvas, making sure no workflow process step or connector is chosen. In the MVPW, make sure the Process Properties tab is chosen. In the MVPW, right-click in the window that is located below the Process Properties tab, then choose New Record. Enter a name for the process property. For more information, see Name of a Step in a Workflow Process or a Process Property on page 67.
124
Process of Building a Workflow Process Defining a Process Property for a Workflow Process
Define the Data Type field, using values from the following table. Data Type String Number Date Hierarchy Binary Type of Data the Process Property Holds Character value. Numeric value. Date value. Hierarchical data, as in a property set. Binary value. Binary data is encoded in the original character set in which it was entered. This data type code is appropriate for data that is self describing , such as XML. Integration Object Strongly Typed Integration Obj Alias Integration object. The Siebel SRF uses the integration object definition for this object.. Strongly typed integration object. XPath notation for pointing to a child in a hierarchical process property.
The String data type code is appropriate for strings, text data, and non XML data, even though XML data can also be stored as string data. It is assumed that string data in a workflow process is UTF 16 String encoded. Literal or Expression data types are UTF 16 String. NOTE: After a data type is chosen, it cannot be modified.
Define the Default String, Default Date, or Default Number property, if applicable. The value you define in one of these properties is the value that is used at the beginning of execution for a workflow process. If the corresponding data type for the value is chosen, then you only define one of these default values. For example, if you define the Date data type, then you can define a Default Date.
10 Repeat Step 5 through Step 9 to define more process properties, as necessary.
12 5
Process of Building a Workflow Process Defining a Property for the Step of a Workflow Process
Defining a Property for the Step of a Workflow Process

This task is a step in Process of Building a Workflow Process on page 115. The properties of a step in a workflow process can include input and output arguments, search specifications, operations, and so forth. You can use the WF Steps OBLE to define some of these properties. You can also use the Properties window and the MVPW from within the Process Designer to define the properties for a step. Properties of a step must be defined one step at a time.
To define a property for the step of a workflow process 1 2

With the Process Designer open, click the step whose properties must be defined. Use the Properties window to define properties for the step. If the Properties window is not displayed, then right-click and choose View Properties Window. For more information, see Overview of Workflow Process Steps on page 65.
Use the MVPW to define input arguments, output arguments, and search specifications. For more information, see Multi Value Property Window on page 50.
126
Options for Developing a Workflow Process
This chapter describes options for developing a workflow process. It includes the following topics: About the Workflow Mode Property on page 127 Starting a Workflow Process on page 143 About Events on page 157 Handling Errors on page 164 Using Batch Processing on page 172 Defining a Workflow Process for a Multilingual Environment on page 175
For other related topics, see Chapter 9, Manipulating Data.
About the Workflow Mode Property

This topic includes the following topics: Types of Modes for a Workflow Process on page 127 Options for the Workflow Mode Property on page 129 Options for an Interactive Workflow Process on page 130 Options for a Long-Running Workflow Process on page 139 Workflow Persistence on page 141
Types of Modes for a Workflow Process

This topic includes the following topics: About the Service Workflow Process on page 128 About the Interactive Workflow Process on page 128 About the Long-Running Workflow Process on page 129 About the 7.0 Workflow Process on page 129
There are four modes that can be used to characterize the run-time behavior of a workflow process. The mode is set by modifying the Workflow Mode property in the Workflow Processes Object List Editor (OBLE).
12 7
Options for Developing a Workflow Process About the Workflow Mode Property
The types of modes for a workflow process that are described in this topic include: Service Flow Interactive Flow Long Running Flow 7.0 Flow
About the Service Workflow Process

The service workflow process is a type of workflow process that executes a set of operations, performing a unit of work from beginning to end. A service workflow is a transient workflow, which is a workflow that runs to completion in a short amount of time without stopping or pausing for an event or activity. A service workflow is the lowest common denominator of the types of modes for a workflow in that no special behavior is associated with it, and it can be a subprocess in another service workflow, an interactive workflow, or a long-running workflow, but not a 7.0 workflow. The service workflow mode simply executes a set of operations upon calling an event. Restrictions when using a service workflow process include: A service workflow process cannot wait for a run-time event or pause for a time. A service workflow process cannot contain a user interact step or a wait step. The Process Designer does not allow you to add a user interact step or a wait step to a service workflow process.
For an example service workflow process, see Example of Defining a Workflow Process That Creates an Activity for a Sales Representative on page 255.
About the Interactive Workflow Process

The interactive workflow process is a type of workflow process that assists and controls navigation for an end user across Siebel views and screens. An interactive workflow includes one or more user interact steps, and usually includes a run-time event. For an example, see Example of Defining a Workflow Process That Manages Creation of a Service Request then Navigates the User on page 301. For more information, see Options for an Interactive Workflow Process on page 130.
Interactive Workflow Process in a UI Context An interactive workflow process can run only in the context of an end user session. An interactive workflow cannot run in the Workflow Process Manager server component, nor in other server components that do not contain a UI context, such as Business Integration Manager. To run in the context of a session for an end user means the workflow must run within an Application Object Manager that contains UI context, such as Siebel Call Center, Siebel Service, Siebel eSales, or Siebel eService. These applications support view navigation, view display, and so forth, which is necessary when using an interactive workflow because they perform view display through the user interact step, and they require interaction with the end user for clicking buttons and hyperlinks.
128
About the Long-Running Workflow Process

The long-running workflow process is a type of workflow process that is persistent and that can last for hours, days, or months. One example of a long-running workflow is Send Order to External. In this example, the workflow sends an order to an external system, then waits for a response. You can use the Long Running Flow mode to define a single workflow process in order to handle an entire business process transaction to coordinate between multiple subprocesses. The Quote to Cash business process is an example transaction where a long-running workflow is useful. You can build a long-running workflow process that is collaborative by assigning a subprocess to an end user. You do this by employing the Workflow User Event Service business service, which generates a user event that can span from one user or session to another user or session. For more information, see Workflow User Event Service Business Service on page 486. You cannot use a user interact step in a long-running workflow process. However, you can add an interactive workflow as a sub process step in a long-running workflow. Also, you cannot use the Process Simulator in Siebel Tools to simulate a long-running workflow. For more information, see Options for a Long-Running Workflow Process on page 139 and Defining a Subprocess that Assigns a Long-Running Workflow Process on page 140.
About the 7.0 Workflow Process

The 7.0 workflow process is a type of workflow process that provides backward compatibility for an existing workflow that was defined in a Siebel release earlier than Siebel CRM version 7.7. If an existing workflow was defined earlier than version 7.7, and you upgrade to version 7.7, then the existing workflow becomes a 7.0 Flow by default. For a new workflow that you define, you must use the service, interactive, or long-running workflow mode. If you must upgrade a workflow process that was defined earlier than Siebel CRM version 7.7 to version 8.0, then the workflow must first be defined as a 7.0 workflow because a pre 7.7 workflow must first be upgraded to version 7.7 before the upgrade to version 8.0. NOTE: It is strongly recommended that you do not use the 7.0 Flow workflow mode when you define a new workflow process. Earlier than Siebel CRM version 8.1, if you do not define a workflow mode, then the mode is assumed to be 7.0 Flow. When you define a new workflow process, be sure to define a Workflow Mode other than 7.0 Flow so that 7.0 Flow is not assumed as the default mode. In Siebel version 8.1, when you define a new workflow process, the Workflow Mode defaults to Service Flow.
Options for the Workflow Mode Property

This topic describes how the workflow mode determines the types of steps a workflow process can contain.
Workflow Mode Usage with the Wait Step and the User Interact Step
The mode property for a workflow process must be set to Interactive Flow when the workflow includes a user interact step. Such a workflow can contain a wait step that waits for an event. In some cases, a wait is not required. For example, a dummy wait step is used to assign values for process properties.
12 9
A workflow process with a wait step is a long-running workflow only when the wait step waits for a amount of time, after which the workflow must be resumed from the Workflow Process Manager. In other cases, if the wait step waits for a run-time event in the same session for an end user, then the workflow is not a long-running workflow. This type of workflow can contain end user interact steps, which make it an interactive workflow.
Workflow Mode Usage with the Sub Process Step

A workflow process can call multiple subprocesses, but the workflow mode of the calling workflow process must be consistent with the workflow mode for the subprocess. Table 21 describes the allowed pairings between the calling workflow process and the subprocess.
Table 21.
Workflow Modes That Are Allowed Between the Calling Workflow Process and the Subprocess Mode That is Allowed For the Subprocess Service Flow Any of the following modes can be used: Service Flow Interactive Flow
Mode of the Calling Workflow Process Workflow Service Flow Interactive Flow
Long Running Flow
Any of the following modes can be used: Service Flow Interactive Flow Long Running Flow
7.0 Flow
7.0 Flow
Options for an Interactive Workflow Process

This topic includes the following topics: About the Synthetic Event on page 131 Suspension and Resumption of an Interactive Workflow Process on page 137
For examples of an interactive workflow processes, see: Example of Defining a Workflow Process That Attaches an Activity Plan to an Opportunity on page 281 Example of Defining a Workflow Process That Manages Creation of a Service Request then Navigates the User on page 301
130
About the Synthetic Event

A synthetic event is a specialized run-time event that is dedicated to controlling navigation for a workflow process. Examples of synthetic events include Suspend, Resume, Next, and Back. Associated with buttons on the user interface, these synthetic events are interpreted by the Workflow Engine to control workflow navigation by navigating the end user back or forward, and by suspending or resuming a workflow process. For example, assume the Siebel application contains an Account Note view with an Account Entry Applet that includes Back, Next, and SaveWorkflow synthetic events. These buttons allow the end user to move forward or backward from the Account Note view, or to suspend an interactive workflow process, then return later to resume the workflow. After you define the buttons, you associate methods within the interactive workflow process. For example, with Back and Next synthetic events, you associate methods to outgoing connectors on the user interact step. You set the method name for the synthetic event in the MethodInvoked property of the button controls.
Comparison of a Synthetic Event to a User Event A synthetic event differs from a user event. A user event is an event that is internal to Siebel Workflow which is used purely to resume a workflow process from the Workflow Process Manager server process. A user event can be used only in a long-running workflow. A synthetic event is a run-time event and is used to resume a workflow process from the application object manager where the synthetic events are generated. Therefore, a synthetic event can only be used with an interactive workflow and a 7.0 workflow.
Forward and Backward Navigation Between Views You can use a synthetic event to define an interactive workflow process so that when the user clicks Next or Back, the user is navigated to the next or previous view in the sequence without losing the context of the instance of the workflow. NOTE: Use a synthetic event to allow the user to navigate backward through views. A run-time event allows forward navigation, but not backward navigation. Requirements that must be met in order for a workflow process to navigate back and forth include: The resumed workflow process must be an interactive workflow or a 7.0 workflow. The calling event must be a navigation event of a workflow process. That is, an event with a name such as InvokeMethod, and a sub event with a name such as FrameEventMethodWFBFxxxx or EventMethodWFBFxxxx, where xxxx is the name of the event, such as Next.
13 1
Table 22 describes backward and forward navigation that is available for workflow modes.
Table 22.
Backward and Forward Navigation with Workflow Modes Workflow Mode Not Supported Modes that are not supported with backward and forward navigation include: Service Flow Long Running Flow
Workflow Mode Supported Modes that are supported with backward and forward navigation include: Interactive Flow 7.0 Flow
Guidelines for Backward Navigation Guidelines for deciding whether to allow backward navigation in your workflow process include: The backward navigation feature does not undo the effect of the workflow process. Backward navigation only modifies the current step counter to point to a previous step. The workflow configuration must make sure the segment of the workflow process that can be repeated by the backward navigation feature is idempotent. That is, acts as if used only one time, even if it is used multiple times.
Methods of a Synthetic Event Table 23 describes methods of a synthetic event.
Table 23.
Methods of a Synthetic Event Description Moves the end user forward in the interactive workflow process by using an applet. You can also give the method name a prefix of BF, as in FrameEventMethodWFBFxxxx. Use this optional BF prefix to define backward and forward behavior of the synthetic event. A synthetic event with this prefix can be used to resume a workflow process from a step that is different from the current step at which the workflow is waiting.
Synthetic Event Method FrameEventMethodWFNext
EventMethodWFNext FrameEventMethodWFBack EventMethodWFBack
Operates the same as FrameEventMethodWFNext, except navigation is through the business component. Moves the user backward in the interactive workflow process.
132
Table 23.
Methods of a Synthetic Event Description Suspends and saves the interactive workflow process and makes it appear in the Inbox for the end user. Resumes the last executed interactive workflow process. ResumeLastIntFlow is different from the other events in that it is not tied to a specific workflow process and can be called from elsewhere in the Siebel application. That is, the button corresponding to this event can be put in an applet, including the task bar where the Site Map icon is located, which is the recommended location for this button.
Synthetic Event Method SaveWorkflow ResumeLastIntFlow
Defining a Synthetic Event Button for Next and Back Events This topic describes how to define a synthetic event button for next and back events.
To define a synthetic event button for next and back events 1 2

In Siebel Tools, identify a view to which a user interact step must navigate the end user. Define a Next button or a Back button on an applet where the event is called. The button must be exposed in the applet that is based on the primary business component that is associated with the business object defined for the workflow process. For example, if the workflow process is based on the Service Request business object, and if the view displays activities associated with a service request, then the button must be exposed in the applet that is based on the Service Request business component. In this example, if the button is exposed in the applet that is based on the Activities business component, then the synthetic event button does not work. For more information, see Using Siebel Tools.
Define the MethodInvoked property of the button control as the name of the associated event. For example, FrameEventMethodWFBack for backward navigation.
13 3
In the Process Designer, associate the applet type run-time event. For example, assign FrameEventMethodWFBack to the outgoing connectors of the user interact step in the workflow process that receives the event. Assign the event using values from the following table. Property Event Type Event Obj Event Sub Event Value Applet AppletName InvokeMethod [Method Name] For example, FrameEventMethodWFBack.
TIP: It is not necessary for you to manually define buttons for each applet. You can copy a button that you define to other applets by using the Applet Comparison feature in Siebel Tools. Also, if you add the applet button controls to the HTML Model Controls applet, then when you define a new applet with the New Applet Wizard you can choose the method buttons that are related to a workflow process.
Defining a Synthetic Event Button for the SaveWorkflow Event This topic describes how to define a synthetic event button for the saveworkflow event.
To define a synthetic event button for the saveworkflow event 1 2

In Siebel Tools, identify a view to which a user interact step must navigate the end user. Define a Save button on an applet where the event is called. For more information, see Using Siebel Tools.
3 4
Define the MethodInvoked property of the button control as the name of the associated event, SaveWorkflow. Use the following script to call the event handler for Siebel Workflow to handle the button click event. The script also passes to the Siebel Workflow event handler the contextual information for the event, which is the name of the view where the event occurs. It is not necessary for you to define the event in the workflow process. function WebApplet_InvokeMethod (MethodName) { return (ContinueOperation); }
function WebApplet_PreCanInvokeMethod (MethodName, &CanInvoke) {
134
// Recognize SaveWorkflow event, which is // used to save Interactive flow if (MethodName == "SaveWorkflow") { CanInvoke = "TRUE"; return (CancelOperation); }
return (ContinueOperation); }
function WebApplet_PreInvokeMethod (MethodName) { // Handle SaveWorkflow event. // Call Workflow Process Manager to save the interactive // flow(s) that is waiting in the current view. if (MethodName == "SaveWorkflow") { var Inputs= TheApplication().NewPropertySet(); var Outputs = TheApplication().NewPropertySet();
// Event name ("SaveWorkflow"), view name, and the rowId // of the active row of the underlying buscomp are // three required parameters for handling the event Inputs.SetProperty("Event Name", MethodName); var viewName= TheApplication().ActiveViewName(); Inputs.SetProperty("Sub Event", viewName); var bc = BusComp (); var bcId = bc.GetFieldValue ("Id"); Inputs.SetProperty("RowId", bcId);
13 5
var workflowSvc= TheApplication().GetService("Workflow Process Manager"); workflowSvc.InvokeMethod("_HandleSpecialEvent", Inputs, Outputs);
return (CancelOperation);
return (ContinueOperation); } Defining a Synthetic Event Button for the Resumelastintflow Event This topic describes how to define a synthetic event button for the resumelastintflow event.
To define a synthetic event button for the resumelastintflow event 1 2

In Siebel Tools, identify a view to which a user interact step must navigate the end user. Define a Resume button on the applet where the event is called. For more information, see Using Siebel Tools.
3 4
Define the MethodInvoked property of the button control as the name of the associated event, ResumeLastIntFlow. Use the following script to call the event handler for Siebel Workflow in order to handle the button click event. The script also passes to the event handler the contextual information for the event, which is the name of the view where the event occurs. It is not necessary for you to define the event in the workflow process. function WebApplet_InvokeMethod (MethodName) { return (ContinueOperation); }
function WebApplet_PreCanInvokeMethod (MethodName, &CanInvoke) {
if (MethodName == "ResumeLastIntFlow")
136
{ CanInvoke = "TRUE"; return (CancelOperation); }
return (ContinueOperation); }
function WebApplet_PreInvokeMethod (MethodName) { // Call Workflow Process Manager to resume the last-executed interactive flow if (MethodName == "ResumeLastIntFlow") { var Inputs= TheApplication().NewPropertySet(); var Outputs = TheApplication().NewPropertySet(); var workflowSvc= TheApplication().GetService("Workflow Process Manager"); workflowSvc.InvokeMethod("_ResumeLastInteractFlow", Inputs, Outputs);
return (CancelOperation);
return (ContinueOperation);
Suspension and Resumption of an Interactive Workflow Process

An interactive workflow process that is suspended can be resumed from within the Inbox for the end user. The user can navigate out of an interactive workflow, then navigate back into the workflow and continue where the user suspended the workflow.
13 7
For example, assume a transaction that involves the end user, an insurance agent, cannot be finished because some information is missing, such as the social security number for a spouse that is required for an insurance policy quote to be considered finished. In this example, when the insurance agent eventually obtains the social security number after suspending the interactive workflow process, the insurance agent can resume the workflow from within the Inbox, then enter the social security number to finish the entry of the quote. After the workflow is finished, the Workflow Engine removes the interactive workflow from the Inbox. An interactive workflow process that is suspended is placed in the Inbox in order to allow the owner of the workflow to track and explicitly resume the workflow. Table 24 describes work that is performed when a workflow process is suspended.
Table 24.
Work That Is Performed When a Workflow Process Is Suspended Description The user clicks Suspend. The user leaves a view that is part of the workflow process. Result The workflow process is saved to the database and placed in the Inbox. If the workflow process must be removed from the in-memory cache, then: The workflow is placed in the Inbox The workflow is saved to the database
Suspension Explicit suspension. Implicit suspension.
Examples of when the workflow must be removed from the in-memory cache is when the cache is full, or when the end user logs out. Items to consider include: To realize the behavior described in Table 24, the Auto Persist flag for the suspended workflow process must contain a check mark. An interactive workflow process that is suspended in the Inbox is removed from the Inbox after the workflow finishes, then terminates.
Comparison of Suspension to Persistence of a Workflow Process There is a difference between suspending a workflow process and persisting a workflow process. If a workflow is suspended, and if the Auto Persist flag for the workflow is set to TRUE, then the workflow can be persistent. For example, with implicit suspension, if an end user leaves a view that the workflow process navigated the user to, then the instance of the workflow is saved in the in-memory cache. In this case, no Inbox item is generated. If the user logs out, and if the Auto Persist flag set to TRUE, then an Inbox item is generated in the cache for the workflow. Therefore, the Inbox item is visible only when the user logs out, then logs back in.
138
In-Memory Cache of an Interactive Workflow Process That Is Suspended An end user often navigates out of an interactive workflow process because the workflow is set up to address a specific business requirement. If the user navigates in this way, then the interactive workflow remains in memory so it can be resumed later in the same user session. As it is uncommon for a user to possess a large number of unfinished work items, there can be a maximum of eight instances of an interactive workflow that is suspended in the memory cache. This limit applies to an individual user session. The limit is eight instances total for interactive workflows that are initiated from within the user session, not eight instances for each interactive workflow. This eight instance limit is not configurable. The user session is one connection on the Application Object Manager component, regardless of whether this thread is logged as a single user. If the eight instance limit is reached, then a new interactive workflow process is not prevented from running. Instead, if the user initiates another interactive workflow after eight instances are already cached in memory, and if this ninth instance must be saved to the cache, and if the AutoPersist flag for the workflow is set, then the oldest instance is either pushed into the database or it is dropped if the memory cache reaches the cache limit.
Event Handling with an Interactive Workflow Process That Is Suspended Siebel Workflow handles events in the following sequence:
1 2 3
Checks the in-memory cache to determine if there are instances for a workflow process in the cache that can receive an event, using the matching criteria defined by the event. Checks the database to determine if there are persistent instances for a workflow process that can receive an event. Resumes instances found in Step 1 and Step 2.
Handling the User Logout Event for an Interactive Workflow Process That Is Suspended Upon receiving the event for the user logout , the Workflow Engine proceeds through the interactive workflow processes that are suspended in the in-memory cache. Each workflow with the Auto Persist flag checked is saved as an Inbox item. Other workflows are deleted.
Options for a Long-Running Workflow Process

This topic includes the following topics: Defining a Subprocess that Assigns a Long-Running Workflow Process on page 140 Defining a Long-Running Workflow Process to Assign a Siebel Task UI to an End User on page 140
A long-running workflow process is a persistent workflow that can last for hours, days, or months. An example of a long-running workflow is an approval process that sends an order to an external system, then waits for a response. For more information, see About the Long-Running Workflow Process on page 129. NOTE: If building a long-running workflow process, then use a user event and not a run-time event to start the workflow process and to resume the instance of the workflow.
13 9
Defining a Subprocess that Assigns a Long-Running Workflow Process

You can define a workflow process that assigns an interactive subprocess to an end user of a collaborative workflow. An example of a collaborative workflow is one that includes a requirement for approvals. The path that the workflow pursues as it moves through the logic of the workflow is a path across multiple users who work in collaboration in order to finish the work that is required by the workflow. You use the Recipients properties on a sub process step in order to define a collaborative workflow process. Assignment occurs based on the login name, not on the Position or User ID. This login name can be a literal value, it can be held in a process property or a field of a business component, or it can be the result of an expression. NOTE: The Process Designer cannot validate the data that is supplied to make sure it represents a valid login name at design time.
To define a subprocess that assigns a long-running workflow process 1 2

Define a sub process step. For more information, see About the Sub Process Step on page 73. In the Recipients tab of the MVPW, set the Recipient Name field to the login name of the user who is assigned to the subprocess. For more information, see About the Process Property on page 47, and Fields of a Recipient Argument of a Process Property on page 468.
Defining a Long-Running Workflow Process to Assign a Siebel Task UI to an End User

You can use a long-running workflow process to assign a task UI to an end user, then generate an inbox item for the task UI and push it to the Inbox for the user. The user can then click the inbox item in order to create a new instance of the task UI and run it. For example, in an Expense Report Approval long-running workflow, after the employee submits an expense report, a new task UI named Review Expense Report is generated and assigned to the manager for the employee. Because this case is a one-to-one assignment, the assignment can be made simply by looking up the ID for the manager from the business component for the user. After the ID for the manager is retrieved, a new item is generated in the Inbox for the manager that references the Review Expense Report task UI.
140
To define a long-running workflow process to assign a task UI to an end user 1

In the long-running workflow process, at the point where the task UI must be called, determine the ID of the end user to whom the new task UI instance is to be assigned. This logic is dependent on your business requirements, and it can be implemented as a Siebel operation if the ID is already present in a business component. The logic can also be implemented as a call to a business service. If the assignment logic implies application of assignment rules, then a business service interface to Siebel Assignment Manager can be used. The input to the service is variable, depending on the context that is required for the assignment. The output, however, is simply the ID of the end user to whom the task UI is assigned.
2 3
Use the Owner Id input argument in order to define a task step that generates a new item in the Inbox for the user to which the task UI is assigned. Add a task step to the workflow process. If you add a task step to a workflow process, then the workflow generates a new instance of the task UI and assigns it to an end user. For more information, see Defining a Task Step on page 84.
Workflow Persistence
Workflow persistence is a property of a workflow process that is used to store the state of an instance of a workflow and the steps and process properties for the workflow. Thus, supporting, within a single workflow, transactions that are long lived. By using workflow persistence to store the state of a workflow, you can build an end-to-end workflow that includes a wait step, sub process step, and other interruptions. Persistence also maintains the active state of a workflow over short or long periods of time, with activity occurring in various parts of your enterprise. The state of the workflow process and process properties are saved in the S_WFA_INSTANCE and S_WFA_INST_PROP tables.
How Workflow Persistence Can be Used to Resume a Workflow Process

Workflow persistence allows resumption of a workflow process after a pause or a server failure. Workflow persistence saves and restores data when the workflow is resumed. If persistence is set to TRUE, then a user can continue a workflow that is suspended. The suspended workflow displays in the Inbox for the user. For example, with persistence set on an interactive workflow process, a user of the workflow can take a work break. If the workflow persistence parameter times out, then the workflow displays in the Inbox for the user and is ready for resumption when the user returns. The workflow persistence setting applies to the long-running workflow process, interactive workflow process, and 7.0 workflow process. You cannot use workflow persistence with a service workflow. The persistence property uses a YES or NO setting. For a long-running workflow, persistence is automatically set by the server at execution time. For an interactive workflow, you set the persistence property by using the Auto Persist flag in the Workflow Processes OBLE in Siebel Tools.
14 1
How Workflow Persistence Functions with Different Workflow Process Modes

Behavior for persistence includes: A long-running workflow process is automatically persistent. If the Auto Persist flag is set, then an interactive workflow process is persistent on suspension. You control workflow persistence by setting the Auto Persist flag. If the Auto Persist flag is set to YES, and if a session times out or if an end user logs out of a Web session, then a workflow process is persistent and can be resumed from the Universal Inbox. A 7.0 workflow process with persistence marked as Auto Persist and is persistent.
NOTE: In some releases earlier than Siebel CRM version 8.0, workflow persistence was used for monitoring a workflow process, and persistence was controlled by adjusting two settings that can apply to individual steps of a workflow: frequency and level. With version 8.0 and higher, process monitoring is separate from workflow persistence, and it is not necessary for persistence to be set for a long-running workflow because the long-running workflow is set by default. For a 7.0 workflow that had persistence set, the Auto Persist flag is automatically set to YES during upgrade and import. A persistent workflow process is automatically purged after it finishes running.
Defining Persistence for a Workflow Process

For a long-running workflow process, persistence occurs by default. For an interactive workflow process, you set the Auto Persist flag in the Process Designer. CAUTION: Defining Workflow Persistence for a large number of workflow processes can result in the creation of a large number of records in the S_WF_PROP_VAL table. For more information, see Avoiding Excessive Records in the S_WF_PROP_VAL Table on page 242.
To define persistence for a workflow process 1

In the Auto Persist property, choose YES by using the drop down picklist.
142
Options for Developing a Workflow Process Starting a Workflow Process
Starting a Workflow Process

This topic describes different ways to start a workflow process. It includes the following topics: Starting a Workflow Process from a Workflow Policy on page 143 Starting a Workflow Process from a Run-Time Event on page 144 Starting a Workflow Process from a Business Service on page 147 Starting a Workflow Process from Another Workflow Process on page 149 Starting a Workflow Process Through the Workflow Process Manager on page 150 Starting a Workflow Process Through the Application Object Manager on page 152 Starting a Workflow Process Through a Script on page 152 Example of Starting a Workflow Process from a Custom Toolbar on page 154 Other Techniques for Starting a Workflow Process on page 156
Starting a Workflow Process from a Workflow Policy

To start a workflow process from a workflow policy, you define a workflow policy action that uses the Run Workflow Process workflow policy program. Alternatively, you can define a custom workflow policy program by copying Run Workflow Process, then adding program arguments that correspond to workflow process properties. This way, you can use the policy program to pass data to the workflow process properties. For more information, see Chapter 14, Defining a Custom Workflow Policy.
To start a workflow process from a workflow policy 1 2 3 4 5 6 7 8 9

In the Siebel client, navigate to the Administration-Business Process screen, then the Actions view. In the Actions list, click New to define a new action. In the Program field, use the picklist to choose the Run Workflow Process program. In the Arguments list, click New to define a new Argument. In the Argument field, choose ProcessName from the picklist. In the Value property, enter the name of the workflow process you must start. Navigate to the Administration-Business Process screen, then the Policy Groups view. In the Policy Groups list, click New to define a new group, then name it. Navigate to the Administration-Business Process screen, then the Policies view.
10 In the list for the Policies List, click New to define a new policy. 11 In the Conditions list, click New to define a workflow policy condition for the policy that must be
met to start the workflow process.
14 3
12 In the Actions list, click New to define a new action, then enter the name of the action you defined
in Step 2.
13 Run the Generate Triggers server component.

For more information, see Overview of Generating Database Triggers on page 403.
14 If you are using the Run Workflow Process program, then make sure the Workflow Process
Manager server component is online.
15 Run Workflow Monitor Agent.

For more information, see Executing a Workflow Policy with Workflow Monitor Agent on page 417.
16 Violate the policy.

The violation starts the workflow process.
Starting a Workflow Process from a Run-Time Event

This topic describes how to use a run-time event to start a workflow process. For more information, see Run-Time Event on page 157.
How a Run-Time Event Starts a Workflow Process

This topic describes an overview of the process that the Siebel application uses in order to start a workflow process by using a run-time event. For this example, assume the PreWriteRecord event is used to start the workflow. The steps that occur when a run-time event starts a workflow process include:
1 2 3 4 5
The PreWriteRecord run-time event is detected by components of the Application Object Manager. Because the PreWriteRecord run-time event is defined on the connector that emanates out of the start step, the workflow process is started. The object manager internally calls the Workflow Engine. At the time of the call, the business object that caused the run-time event is passed to the Workflow Engine. The Workflow Engine uses the active rows on the business object for data operations. If the rows are not already active, then the Workflow Engine sets up the rows, which is applicable for an object manager that generates run-time events. Siebel Workflow runs with the local thread, and if SWE is present, then user interacts are allowed. The parameters used include:

Context, a CSV string that is internally registered by Siebel Workflow The business component that causes the run-time event
144
Choosing Between a Run-Time Event and a Workflow Policy

In cases where it is necessary to detect a database event, use a workflow policy, not a run-time event. For example, if using the UI, then use a run-time event in order to start a workflow process. If using the Siebel EAI Adapter or the EAI UI Data Adapter, which performs numerous WriteRecord events, then use a workflow policy. For more information, see Starting a Workflow Process from a Workflow Policy on page 143.
Comparison of Using a Run-Time Event to a Using a Workflow Policy Table 25 describes two different requirements for using a run-time event compared to a workflow policy.
Table 25.
Examples of Requirements for Using a Run-Time Event Compared to a Workflow Policy Recommended Technique Using a workflow policy is a more appropriate way to detect the database event. Using a run-time event is more appropriate. Define a workflow process with the InvokeMethod runtime event defined on the start step that detects when the Entry Applet is viewed. Use a business service step in this workflow process to generate the text file.
Requirement Set the priority to ASAP and send a notification email when a new service request is created. Generate a text file with some information when a particular entry applet is viewed.
Defining a Button That Starts a Workflow Process

You can use Siebel Tools to define a button on an applet that calls the run-time event that starts a workflow process.
To define a button that starts a workflow process 1 2 3

From Siebel Tools, define a button on an applet and define the MethodInvoked property. For more information, see Using Siebel Tools. Override the PreCanInvokeMethod property. Edit the server script and compile your changes.
14 5
The following example is specific to Siebel VB: Function WebApplet_PreCanInvokeMethod (MethodName As String, CanInvoke As String) As Integer If MethodName = "<Name>" Then CanInvoke = "True" WebApplet_PreCanInvokeMethod = CancelOperation Else WebApplet_PreCanInvokeMethod = ContinueOperation End If End Function
4 5
Define a workflow process. Choose a mechanism to start the workflow process. To start this workflow process from a button click, you must define a run-time event on a connector. Choose from one of the following mechanisms to start the workflow:

To start this workflow process, define the run-time event on the connector that emanates from the start step. To resume this workflow process if it is paused as the result of a button click, define the runtime event in a user interact step or a wait step.
Define the run-time event using values from the following table. Property Event Event Cancel Flag Value PreInvokeMethod True. If this flag is not checked, then an error results when the workflow process is run. Event Object Event Object Type Sub Event Name of the business component on which the applet that contains the button is based. BusComp Name of the method you set in step Step 1. The Sub Event name must be unique. Type (Required) Condition
7 8
Activate the workflow process. In the Siebel client, navigate to the Administration-Runtime Events screen, then the Events view.
146
Click Menu on the Events applet, then choose Reload Runtime Events. order for the change to take effect, you must reload personalization after a workflow process is activated that registers a run-time event.
Avoiding the Cannot Resume Workflow Process Error If all of the following situations exist, then an error occurs when a user clicks a button that starts a workflow process: The workflow process is an interactive flow The workflow process is started at least one time in the current user session An event is fired and there is no instance of a workflow process that is waiting to handle the event
The event is discarded and the end user receives an error message.
To avoid the cannot resume workflow process error

Require the end user to run a workflow process in order to access this view. For example, you can define a workflow process that includes the user interact step. You can handle the error by defining an error exception connector or error process.
Identifying A Predefined Workflow Process That Is Started by a RunTime Event

For your implementation, it is possible that some predefined workflow processes are started by a run-time event. You can use the Action Set Name field of the Runtime Events administration screen in the Siebel client to identify a predefined workflow process that is started by a run-time event.
To identify a predefined workflow process that is started by a run-time event 1 2

In the Siebel client, navigate to the Administration-Runtime Events screen, then the Events view. Note the value of the row ID in the Action Set Name field. For example, if Workflow_1-2APXH is displayed in the Action Set Name field, then 1-2APXH is the row ID of the workflow process that is referenced.
3 4
Navigate to the Administration-Business Process screen, then the Workflow Processes view. Query the Name field for the row ID of the workflow process you noted in Step 2. For example, [Id]='1-2APXH'. The query returns the record for the workflow process.
Starting a Workflow Process from a Business Service

You can start a workflow process from a business service. Items to consider include:
14 7
With a business service, such as Workflow Process Manager (Server Request), it is not necessary for you to define parameters for the Server Request Broker (SRBroker). If you call the server requests directly, then you must define parameters for the Server Request Broker. Server Request Broker and Server Request Processor (SRProc) are required in order to run a business service that calls a server component. To use Workflow Process Manager (Server Request), Server Request Processor and Server Request Broker must be running.
For more information, see Siebel System Administration Guide. For more information on calling a business service, see Siebel Object Interfaces Reference.
To start a workflow process from a business service 1 2

In Siebel Tools, in the Object Explorer, click Business Service. In the Business Services OBLE, add a new business service using values from the following table. Property Name Class Display Name Value (This is the name that you can reference in scripting.) CSSSrmService (This is the name that you see in workflow views.)
3 4
In the Object Explorer, expand the Business Service tree, then click Business Service User Prop. In the Business Service User Props OBLE, add two new objects using values from the following table. Property Component Mode Value (Short name of the server component. For example, WfProcMgr.) (Mode of the server request. For example, Async.)
5 6 7
(Optional) Enter more user properties pertaining to Server Request Broker. For more information, see Server Request Broker on page 36. In the Object Explorer, click Business Service Method. In the Business Service Methods OBLE, add a new object using values from the following table. Property Name Display Name Value (This is the name that you can reference in scripting.) (This is the name that you see in workflow views.)
148
8 9
In the Object Explorer, expand the Business Service Method tree, then click Business Service Method Arg. In the Business Service Method Arguments OBLE, add records that are specific to the component that is called. For example, ProcessName for WfProcMgr. The name is the short name of the server component parameter.
Starting a Workflow Process from Another Workflow Process

You can define a workflow process so that it asynchronously starts another workflow directly. You start a workflow, which calls a custom business service, which in turn starts the second workflow by using the Asynchronous Server Requests business service.
To start a workflow process from another workflow process 1 2 3

In Siebel Tools, in the Process Designer, add a business service step to your workflow process. Make sure the new business service step is chosen. Use the properties window to set values described in the following table. Property Business Service Method Value Asynchronous Server Requests SubmitRequest
In the MVPW, click the Input Arguments tab, then add three new input arguments using values from the following table. Input Argument Component WfProcMgr.ProcessName WfProcMgr.RowId Type Literal Literal Process Property Value WfProcMgr AG Simple Test (leave empty) Property Name (leave empty) (leave empty) Siebel Operation Object Id
For more information, see Arguments of the Step of a Workflow Process on page 49.
To set component parameters, such as Workflow Process Name, define the Input Argument Name as [ComponentAlias].[Business Service Method Arg Name].
If the workflow process is executed in the Process Simulator, then a request is inserted into the S_SRM_REQUEST table and a Workflow Process Manager task is started on the server.
14 9
Starting a Workflow Process Through the Workflow Process Manager

A workflow process can be run within the Workflow Process Manager server component. The ways in which a workflow process can be started on the server include: From a workflow policy that executes on the server. For more information, see Starting a Workflow Process from a Workflow Policy on page 143. From a script that specifies the Server Request parameter. For more information, see Starting a Workflow Process Through a Script on page 152. From a run-time event with the Processing Mode property set to Remote Synchronous or Remote Asynchronous. For more information, see Starting a Workflow Process from a Run-Time Event on page 144.
If you compiled a custom SRF file by using Siebel Tools, then this file must be added to the Objects directory on the Siebel Server. In addition, you must update the siebel.cfg file that is referenced in the Server parameters in order to reflect the custom SRF file. The siebel.cfg file is the default configuration file for Workflow Process Manager server components. Items to consider include: A workflow process that is started from a script is performed in synchronous mode. A business service that calls a UI element, including navigation functionality, such as the user interact step, is not supported when the workflow process runs on the server.
For more information, see Workflow Process Manager on page 32.
Remote Synchronous Processing

If an end user starts a workflow process that runs on the server within the Workflow Process Manager server component, then the workflow executes only if the user is connected to the server. If the user is not connected to the server, then the request is queued and executes when the user synchronizes or when the server is available. For more information, see Server Requests Business Service on page 482.
Key Based Routing with Workflow Process Manager

A server key map is a map that defines the rule groups that load and process for each server. You can configure a server to load multiple rule groups. If you define a server key map, then you are dividing the rules among the different servers. A server key map is defined in the Server Key Map view in the Assignment Administration screen. You submit an assignment request by defining the AsgnKey parameter, where the AsgnKey parameter is the row ID of the assignment rule group that is associated with the rules you must evaluate. If using AsgnSrvr, then the AsgnKey parameter must be the row ID of one of the rule groups that is defined for the server in the Server Key Mappings view. The Assignment Server (AsgnSrvr) first looks for entries in the server key map for a specific server, then loads rules for only those rule groups that are associated with that server key map. Assignment Manager uses key based routing in order to route the request to a particular instance of Assignment Manager where the rules are loaded for that rule group.
150
You can define multiple servers to load the same rule group. Assignment Manager routes requests to one of the servers where that rule group is based on load balancing metrics Environments in which the server key mapping feature is supported include: Where there is an interactive and dynamic assignment Where a script or workflow process calls a business service
Reasons for using Key Based Enabled include: Routing. You can setup the RequestKey parameter on the Workflow Process Manager so that when Siebel Workflow comes up, it registers this key. This way, you can control the routing of Workflow Process Manager requests. Recovery. To target the ping messages, each Workflow Process Manager registers a unique key. The recovery manager uses these keys to keep track of which Workflow Process Manager is alive and what Workflow Process Manager is processing.
In general, if Recovery Manager is activated, then the Key Based Enabled parameter for Workflow Process Manager must be set to true. For more information on key based routing, see Siebel Assignment Manager Administration Guide.
Workflow Process Manager and Automatic Record Insertion

If the Workflow Process Manager inserts a record, then, by default, the system generated CREATED_BY field is set to 0-1, which is the ROW_ID for employee SADMIN. In some cases, it can be desirable to set the CREATED_BY field to a value other than the Id for SADMIN. For example, assume a workflow process inserts an activity when an end user performs an action in the Siebel client. Because this workflow is started by the Asynchronous Server Requests business service, the workflow is executed by the Workflow Process Manager on the server, and CREATED_BY is set to SADMIN, although the business requirement is to set CREATED_BY to the user who caused the workflow to start. In this situation, work you can perform includes: Instead of starting the workflow process on the server by using Workflow Process Manager, start the workflow so that it runs locally. As a result, the session for the end user creates the record and CREATED_BY is set to the Id for the user. In this case, the workflow is executed synchronously. If the requirement is to record which end user caused a record to be inserted, then you can pass the Login Id or Login Name of the user to the workflow process on the server, then write it to an extension field in the business component. You can obtain the Login Id or Login Name for the user in a script by using the standard LoginId () or LoginName () functions. For information about how to pass data to a custom process property of a workflow when a server request is submitted, see Server Requests Business Service on page 482.
15 1
Starting a Workflow Process Through the Application Object Manager

Running a workflow process in the Application Object Manager can be useful for enforcing a business process with a mobile user or for defining a business process that involves navigation by the end user.
To start a workflow process that runs in the application object manager

Start the workflow process in one of the following ways:

From the Process Simulator From a script that is defined to run locally in the application object manager From a run-time event with the Processing Mode defined as local synchronous
Starting a Workflow Process Through a Script

A workflow process can be started from a script by using Siebel VB or Siebel eScript. By using a script, a workflow can be started from most locations in the Siebel application or from an external program. If a workflow is started from a script, then you can define the workflow to run on the server or in the object manager. A workflow that is started from a script is executed in Synchronous mode.
To run a workflow process on the server

Call the Workflow Process Manager (Server Request) service.
To run a workflow process in the application object manager

Call the Workflow Process Manager service.
Example of Starting a Workflow Process from a Script in the Object Manager

This topic gives one example of starting a workflow process from a script in the object manager. You might use this feature differently, depending on your business model.
152
The following is an example of a script that starts a workflow process named My Account Process. In this example, the process is started in the object manager. / Example: Starting a Workflow Process through scripting function Invoke_Process() { var svc = TheApplication().GetService("Workflow Process Manager"); var Input = TheApplication().NewPropertySet(); var Output = TheApplication().NewPropertySet(); var bo = TheApplication().ActiveBusObject(); var bc = bo.GetBusComp("Account"); var rowId = bc.GetFieldValue("Id"); Input.SetProperty("ProcessName", "My Account Process"); Input.SetProperty("Object Id", rowId); svc.InvokeMethod("RunProcess", Input, Output); }
Example of Starting a Workflow Process from a Script to Pass Field Values to Process Properties
This topic gives one example of starting a workflow process from a script in order to pass field values to process properties. You might use this feature differently, depending on your business model. The following script starts a workflow process that is named My Opportunity Process. In this example, the workflow process is started in the object manager. Field values are passed to process properties that are defined in the workflow. //Example: Passing Field Values to Process Properties function Invoke_Process() { var svc = TheApplication().GetService("Workflow Process Manager"); var Input = TheApplication().NewPropertySet(); var Output = TheApplication().NewPropertySet(); var bo = TheApplication().ActiveBusObject(); var bc = bo.GetBusComp("Opportunity"); var rowId = bc.GetFieldValue("Id"); var accountId = bc.GetFieldValue("Account Id"); Input.SetProperty("ProcessName", "My Opportunity Process"); Input.SetProperty("Object Id", rowId); // Pass the value of the Account Id field to the Account Id process property Input.SetProperty("Account Id", accountId); svc.InvokeMethod("RunProcess", Input, Output);
15 3
Starting a Workflow Process from a Script by Using the Server Requests Business Service
You can asynchronously start a workflow process from a script by using the Server Requests business service. For more information, see Example of Using the Server Requests Business Service to Start a Workflow Process from a Script on page 305.
Example of Starting a Workflow Process from a Custom Toolbar

This topic gives one example of starting a workflow process from a custom toolbar. You might use this feature differently, depending on your business model.
To start a workflow process from a custom toolbar 1

In Siebel Tools, navigate to the Business Services OBLE, then define a new business service using values from the following table. Property Name Server Enabled Value TestTBItem TRUE
Navigate to the Commands OBLE, then define a new command using values from the following table. Property Name Business Service Method Target Value TestTBItem TestTBItem TestTBItem Server
If necessary, expose the Command object in the Object Explorer. For more information, see Exposing Object Types That Are Used to Develop a Workflow Process on page 116.
In the Object Explorer, click Toolbar, then query the Name property in the Toolbars OBLE for HIMain. If necessary, expose the Toolbars object. For more information, see Exposing Object Types That Are Used to Develop a Workflow Process on page 116.
In the Object Explorer, expand the Toolbar tree, then click Toolbar Item.
154
In the Toolbar Items OBLE, add a new record using values from the following table. Property Name Command DisplayName Type HTML Type Position Value TestTBItem TestTBItem TestTB Item Button Button 20
In the Siebel client, define a workflow process and make sure it can be run successfully from the process simulator. For more information, see Preparing to Use the Process Simulator on page 203.
Add the following server script to the business service that you defined in Step 1. NOTE: The name of the workflow process that you used in Step 6 must be used in the script. function Service_PreCanInvokeMethod (MethodName, &CanInvoke) { if ( MethodName == "TestTBItem" ) { CanInvoke = "TRUE"; return( CancelOperation ); } return (ContinueOperation); }
function Service_PreInvokeMethod (MethodName, Inputs, Outputs) { if ( MethodName == "TestTBItem" ) { var input = TheApplication().NewPropertySet(); var output = TheApplication().NewPropertySet(); var svc = TheApplication().GetService( "Workflow Process Manager" );
15 5
input.SetProperty("ProcessName", "<WF Process Name Created in Step 4>"); svc.InvokeMethod("RunProcess", input, output); input = null; output = null; svc = null; return (CancelOperation); } return (ContinueOperation); }
Compile the changes, then log in to the Siebel client.
Your new custom button displays in the custom toolbar. If you click it, then the corresponding workflow process is started.
Other Techniques for Starting a Workflow Process

Information sources for other techniques that can be used to start a workflow process include: For starting from a synthetic event, see About the Synthetic Event on page 131 For starting from a user event, see About the User Event on page 161 For starting from the Process Simulator, see About the Testing Tools on page 197 For starting from a server component, see Overview: Siebel Enterprise Application Integration and Siebel eMail Response Administration Guide
You can use these techniques in order to test a workflow process in your test environment before you deploy it to the production environment. When testing, being able to start a workflow from a workflow policy is important because it tests starting a workflow on the server. You can also use these techniques to start a workflow in your production environment.
Business Integration Manager

It is recommended that you do not use Business Integration Manager or Business Integration Batch Manager: If you are using Business Integration Manager, then you must replace it with Workflow Process Manager If you are using Business Integration Batch Manager, then you must replace it with Workflow Process Batch Manager
156
Options for Developing a Workflow Process About Events
About Events
This topic describes run-time events and user events that can be used with a workflow process. It includes the following topics: Run-Time Event on page 157 About the User Event on page 161
Run-Time Event
A workflow process can integrate with the run-time events engine in order to provide a simplified way to automate a business process. Benefits provided by this technique include: Allows real time monitoring of events Minimizes scripting and calling for a workflow policy
The types of events that can be used include: Application Business Component Applet
A run-time event allows the Siebel application to respond in real time to an interaction that is initiated by an end user. A run-time event can be defined on a connector that emanates from a start, wait, or user interact step in order to start or resume a workflow process. The properties of the WF Step Branch that are used to define a run-time event include: Event Object Type Event Object Event Sub Event Event Cancel Flag
For more information, see Starting a Workflow Process on page 143, and Siebel Personalization Administration Guide.
Run-Time Event Usage with a Long-Running Workflow Process

NOTE: It is recommended that a run-time event not be used to start a long-running workflow process because a run-time event is specifically attached to a single user and a single session. A run-time event is only for a single, distinct end user because it originates from Personalization functionality. Instead, use an interactive workflow or a service workflow to handle the run-time event. Then, after processing and validating the workflow, generate a user event in order to notify a long-running workflow.
15 7
Run-Time Event Usage with the User Interact Step

Events not supported with the user interact step include: The DisplayRecord event The DisplayApplet event The Login event. Use the WebSessionStart event instead
The event supported with the user interact step includes: The SetFieldValue event for a field with the Immediate Post Changes property set to TRUE. Immediate Post Changes is a property on a business component field that causes an immediate roundtrip to the server if a change is made to the field, which results in an immediate calculation of the field or a refresh of the view. If Immediate Post Changes is set to True, then the PreSetFieldValue event in the browser script is bypassed. For more information, see Configuring Siebel Business Applications.
Run-Time Event Usage within a Business Object Context

A workflow process that references a run-time event is only started when the run-time event is detected from within the same Business Object context in which the workflow process is based. For example, assume a workflow process is started by the WriteRecord run-time event and the Business Object property for the workflow is set to Service Request. To update the record, the user clicks the Service Requests List screen tab, updates the Status field, then steps off the record. In this case, the record is written in the context of the Service Request business object, and the run-time event that is defined on the workflow fires. However, if the Status field is updated within a non service request business object context, then the run-time event does not fire. For example, assume the user drills down on a Contact, clicks the Service Requests view tab, updates the Status field, then steps off the record. In this case, the service request record is written in the context of the Contact Business Object, and the run-time event does not fire.
Defining a Run-Time Event within a Many to One Relationship

If defining a run-time event to start a workflow process based on a modification made to a record that contains a many to one relationship with a parent, then you must start the workflow based on the ROW_ID for the child. For example, assume you must start a workflow process when a field in the activity for a service request is updated. Because a service request can contain one or many activities, you must start the workflow based on the ROW_ID for the activity, not the service request. If you start the workflow based on the ROW_ID of the service request, then a change that is made in the form applet for the service request starts the workflow, but a change made in the activities list applet does not.
To examine a one to many relationship 1 2

In the Siebel client, navigate to the Service Request screen, then the Service Request List view. Create a new service request.
158
3 4 5
Drill down by clicking the SR# field. Use the Activities list to create two new activities. In the Activities list view, the top service request form displays fields for the parent service request, while the bottom activities list displays multiple activities for the parent.
To define a run-time event within a many to one relationship 1

In Siebel Tools, in the Workflow Processes OBLE, define a new workflow process using values in the following table. Property Process Name Business Object Workflow Mode Value Update Service Request Service Request Interactive Flow
The workflow process is based on the Service Request business object. The run-time event that is used in this workflow occurs on the start step and is based on the Action business component, which is a child of the Service Request business object. The wait step, used in this workflow for testing purposes, requires an Interactive Flow. For more information, see About the Wait Step on page 87. For an example, see Defining the New Workflow Process on page 256.
Open the Process Designer for the workflow process you defined in Step 1, then define a workflow that resembles the workflow in the following figure.
Click the Id Triggered connector, then use the Properties window to define values described in the following table. Property Value
Event Object Type Event Event Object 4
BusComp WriteRecord Action
15 9
In the MVPW, right-click, then add a new process property using values from the following table. Field Name In/Out Business Object Value ActionBCRowId% In/Out Service Request
For more information, see About the Process Property on page 47. To capture the ROW_ID of the activity, you define a process property, then use a wait step which can read a field from the child business component into the process property in the output argument for the wait step without modifying the underlying data.
6 7
Click the Get Activity Id step, then click the Output Arguments tab in the MVPW. Right-click, choose New Record, then define a new record using values from the following table. Field Property Name Type Value Business Component Name Value ActionBCRowId% Expression Id Action
For testing purposes, this step reads the ROW_ID of the activity, which is the Id field, into the ActionBCRowId% process property. No input arguments are defined for the wait step.
Validate, then simulate the workflow process. For more information, see Process of Testing a Workflow on page 202.
Implement this technique in your production workflow. This example demonstrates how you can start a workflow process based on changes made to a child in a many to one relationship. It includes steps to test the technique. In a production environment, if it is not necessary to capture the ROW_ID of the child, then you can simply define the trigger of the run-time event on the connector that emanates from the start step, as described in Step 3.
Run-Time Event Usage with the Updated By Field

If a step in a workflow process contains a run-time event with a processing mode that is defined to run locally to either start or resume a workflow, then the value in the Updated By field describes the end user who is currently logged into the application.
160
Run-Time Events That Cannot Be Used to Start a Workflow Process

Because a workflow process can be started only within the context of a record for a business component, if there is no business component record context, then it is not possible to start the workflow, and attempting to start the workflow using the BusComp Query event fails. Therefore, a run-time event with the possibility of returning no results cannot be used to start a workflow.
Repeat Usage of a Run-time Event

You cannot use the same run-time event more than one time within a given workflow process.
About the User Event

While a run-time event acts on a workflow process from within the application object manager, a user event is internal to the workflow. A user event initiates and resumes a long-running workflow process in the Workflow Process Manager (WFProcMgr) server component. NOTE: A user event can be used only in a long-running workflow process. A long-running workflow resumes on Workflow Process Manager. The behavior cannot be modified in order to cause a longrunning workflow to resume on a custom workflow server component. While a run-time event can be used in a workflow process that runs within a single user session, a user event is for use in a long-running workflow that spans multiple users. A user event can be used to start a workflow when the user event is attached to a start step, or to resume an instance of workflow that is waiting when the user event is attached to a step that can receive an input argument. A user event can also bring data into the instance of a workflow which can contain user data. This data comes in the form of the payload for the user event.
User Event Generation with the Workflow User Event Service Business Service
A user event requires use of the Workflow User Event Service business service in order to communicate with the Workflow Process Manager. A user event is an event that is internal to Siebel Workflow which is used to resume a long-running workflow process from the Workflow Process Manager. To generate a user event, you call the Workflow User Event Service business service. NOTE: A long-running workflow process must use only a user event, and not a run-time event. The Workflow User Event Service business service is a standard Siebel business service that can be used wherever a Siebel business service can be used. You call the Workflow User Event Service business service by defining a business service step that calls it. The User Event business service can be called by supported techniques, such as scripting, COM interfaces, and Java interfaces, which is the recommended way to communicate externally with a workflow process.
16 1
A typical example occurs when a 7.0 workflow, an interactive workflow, or a service workflow initiates a user event. A business service step calls the Workflow User Event Service business service to communicate to a long-running workflow that is running in the background. NOTE: While most types of workflow processes or business services can generate a user event, it is recommended that only a long-running workflow process be defined to receive a user event. For more information, see Workflow User Event Service Business Service on page 486.
Starting the Workflow User Event Service Business Service This topic describes how to call the Workflow User Event Service business service in order to generate a user event.
To call the Workflow User Event Service business service 1 2

Add a business service step to a workflow process, Click the business service step you added in Step 1, then use the Properties window to define values described in the following table. Property Business Service Name Business Service Method Value Workflow User Event Service GenerateEvent
3 4 5 6
In the MVPW, define a new input argument for the step. For more information, see Arguments of the Step of a Workflow Process on page 49. In the Input Argument field, choose Payload from the picklist, then define the other fields, as appropriate. Repeat Step 3 and Step 4, choosing Correlator Value from the picklist. Repeat Step 3 and Step 4 again, choosing User Event Name from the picklist.
Defining a Long-Running Workflow Process to Wait for a User Event

If using a user event in your workflow process, then keep in mind that only a long-running workflow process can wait for a user event. Other types of workflows cannot wait for a user event, though they can generate a user event. A long-running workflow must be defined with a user event only, not a run-time event.
To define a long-running workflow process to wait for a user event 1 2

Open the Process Designer for the workflow process in which you must define a user event. In the MVPW, establish one of the process properties for the workflow process as the correlator by setting the Correlator Flag for the property to TRUE. For more information, see About the Process Property on page 47.
162
On the branch of the step that handles the event, such as a start step or a wait step, use the Properties window to define values described in the following table. Property Type Value Condition If Type is set to Default rather than to Condition, then the user event is never called. User Event Name User Event Timeout (The name of the workflow you defined for the Value property in Step 6 on page 162.) (The timeout period for the user event.) User Event Timeout works in a way that is similar to the timeout setting for a run-time event. If no user event is received during the timeout period, then the workflow process is resumed after the timeout period. User Event Storage (The name of the process property that holds the payload that is passed in from the user event.)
NOTE: A user event is not queued. If no recipient is waiting to accept the user event with the defined correlator, then the event is discarded.
16 3
Options for Developing a Workflow Process Handling Errors
Handling Errors
This topic includes the following topics: Using an Error Exception Connector to Handle Errors on page 164 Using a Stop Step to Handle Errors on page 168 Error Handling with an Error-Workflow Process on page 168 Recovery for a Workflow Process That Has Failed on page 171
An error is a deviation from the normal or expected flow of a workflow process. An error can be generated by the system or by an end user. You can use error handling to notify the end user of an error and terminate the instance of a workflow. For information about using a process property when handling errors, see Passing a Process Property to an Error-Workflow Process on page 58.
Using an Error Exception Connector to Handle Errors

An error exception connector is a type of connector that is designed to handle system and user generated errors. An example of an error that is generated by the system is a failure that occurs when an email notification is sent. An example of an error that is generated by an end user is an attempt to submit an order that is not complete. You can use an error exception connector to programmatically handle errors and change the flow that is pursued in a workflow process, depending on whether an error is encountered. This technique provides a granular approach to handling an exception at each step. If an error occurs, then the error code and error message are automatically populated in the Error Code and Error Message process properties. An error exception connector allows you to set up a decision condition by using values in these properties. In the Process Designer, an error exception connector is displayed as a red connector between two steps. If you click an error exception connector, then the Properties window displays the WF Step Branch properties for the connector. Similar to other cases where a decision condition is used in a workflow process, exception logic for a step is evaluated after the step finishes. If you must evaluate an exception before execution of a step, then you must attach the error exception connector to the prior step in the workflow.
Example of Error Exception Handling

This topic gives one example of defining error exception handling. You might use this feature differently, depending on your business model.
164
In the example displayed in Figure 18, If the Get Organization ID step is unable to get data, then the workflow process continues to the Lookup Sender by Org step. If Lookup Sender by Org fails, then the workflow pursues the red exception connector, and sends an email by using the Send Lookup Error Email step.
Figure 18. Example of a Workflow That Uses Error Exception Connectors to Programmatically Handle Exceptions
Defining an Error Exception Connector

An error exception connector is defined in the Process Designer.
To define an error exception connector 1

2 3
Right-click the workflow process, then choose Edit Workflow Process. In the Process Designer, drag, then drop an error exception connector from the palette to the canvas, attaching one end of the connector to an existing step for which you must trap errors. Some example step types where you might trap for an error decision condition includes the business service step and the Siebel operation step.
16 5
4 5 6 7 8 9
Make sure that the end of the connector is attached to the step. Drag, then drop a stop step from the palette to the canvas. Attach the unconnected end of the error exception connector to the stop step. Make sure the error exception connector is chosen in the Process Designer. Enter a value in the Name property in the Properties window. In the Type property, choose Error Exception or User Defined Exception. Condition Criteria dialog box.
10 In the Process Designer, double click the error exception connector to access the Compose 11 Define decision conditions that apply for the exception.
For more information, see Defining a Decision Condition on a Branch Connector on page 95.
Defining an Error Exception Connector to Handle an Update Conflict

You can define an error exception connector to handle an update conflict that occurs when multiple attempts are made to write to the same record at the same time. If the Workflow Monitor Agent (WMA) is used to start a workflow process, which in turn updates a record, then the WMA can fail if a workflow attempts to update a record that is updated by another user or by a WMA task since it was initially retrieved by the workflow. In this case, an error message, such as The selected record has been modified by another user since it was retrieved, is displayed. To prevent the WMA task from failing, you can define an error exception connector to handle an update conflict that occurs while the workflow is running.
To define an error exception connector to handle an update conflict 1

In Siebel Tools, define a new workflow process using values from the following table. Property Process Name Workflow Mode Business Object Value Error Exception Example Service Flow Opportunity
166
Add steps and connectors until your workflow process resembles the workflow illustrated in the following figure.
Click the Update Opportunity business service step, then use the Properties window to define properties described in the following table. Property Business Service Name Business Service Method Value ABC Update Opty Update Opty
4 5
Make sure the Update Opportunity business service step is still chosen in the Process Designer. Define an input argument in the MVPW using values from the following table. Field Input Argument Type Property Name Property Data Type Value Opportunity Id Process Property Object Id String
16 7
Define a decision condition on the error exception connector named Interim Write Error using values from the following table. Property Value
Compare to Operation Object Values
Process Property One Must Match (Ignore Case) Error Code 0x8137 -- 0x6f74
0x8137 -- 0x6f74 is the error code that is returned with the following error message: The selected record has been modified by another user since it was retrieved For more information, see Defining a Decision Condition on a Branch Connector on page 95.
7 8
Define the Update Opportunity Again business service step, using the same values you used in Step 3 and Step 4. For the Name property, use Update Opportunity Again. Validate, then simulate the workflow process. For more information, see Process of Testing a Workflow on page 202.
Implement this technique in your production workflow process.
The Update Opportunity Again step provides a way to write to the opportunity again in the case where the first attempt to update the opportunity fails due to the update conflict error. This example uses a business service step that updates opportunities. The same technique can be used with other step types that update a record, such as a Siebel operation or a sub process step, and with other types of records, such as accounts or contacts.
Using a Stop Step to Handle Errors

A stop step is used to display a particular error message while processing. Example usage includes real-time processing for credit card authorization or for order validation. This type of exception handler provides customizable error messages including expressions. For more information, see About the Stop Step on page 88.
Error Handling with an Error-Workflow Process

You can use an error-workflow process to handle errors. An error-workflow process is a standard workflow that becomes an error workflow when you associate it to another, main workflow. The association is established by defining the Error Process Name property in the Workflow Processes OBLE for the main workflow. If an error occurs in the main workflow, then the error exception connector calls the error workflow.
168
The workflow process that is defined in the Error Process Name property is called when the main workflow reaches an error state. Execution of the main workflow stops, the main workflow passes system defined process properties to the error workflow, then the error workflow commences. Restrictions when using an error-workflow process include: An error-workflow process does not return values back to the originating workflow that failed. If you require that the state of the main workflow be changed by the error handling actions, then use an error exception connector. An error-workflow process can be associated with a workflow that is a subprocess. However, an error workflow cannot itself contain a subprocess.
Benefits of Using an Error-Workflow Process A universal exception handler is an error-workflow process that is used when you must handle errors across multiple steps in a workflow or across multiple workflows. This type of exception handling can be used to reduce clutter in the workflow diagram, and to reduce the requirement to define a large number of error workflows by reusing a single or a small set of error workflows.
How Errors Are Handled

This topic describes how error handling varies for a workflow process and how errors are handled for a subprocess.
How Errors Are Handled for a Workflow Process If an error is encountered in a workflow process that does not contain an error workflow that is defined in the Error Process Name property, then the workflow remains in the In Error state. The original error code is returned to the caller of the workflow.
16 9
If the main workflow process encounters an error and there is an error workflow defined for the main workflow process in the Error Process Name property, then the error workflow finishes with one of the outcomes described in Table 26.
Table 26. Situation
Error Handling When an Error-Workflow Process Is Defined for a Workflow Process Error Process State Completed Error Code No error code is returned to the caller of the workflow process. Result If the error-workflow process arrives at an end step, then error handling is considered successful. The error-workflow process terminates immediately with a Completed state. Error A new error code, which you defined in the stop step, is returned to the caller of the error-workflow process. The original error code is returned to the caller of the workflow process. If the error-workflow process arrives at a stop step, then error handling is considered failed. The workflow process remains in the In Error state. If no start decision conditions are satisfied, then the error-workflow process ends immediately. The workflow process remains in the In Error state.
The errorworkflow process handles the error successfully.
The errorworkflow process tries to handle the error, but fails with a different error. The errorworkflow process cannot handle the error.
Error
170
How Errors Are Handled for a Subprocess If a subprocess encounters an error, and if there is an error-workflow process defined for the subprocess in the Error Process Name property, then the error-workflow process finishes with one of the outcomes described in Table 27.
Table 27. Situation
Error Handling When an Error-Workflow Process Is Defined for a Subprocess Error Process State Completed Error Code Not applicable Result If the error-workflow process arrives at an end step, then error handling is considered successful. The subprocess also terminates with a Completed state, then control returns to the main workflow process. The main workflow process continues to execute from the next step.
The errorworkflow process handles the error successfully.
The errorworkflow process tries to handle the error, but fails with a different error.
In Error
The new error code, which you defined in the stop step, is returned to the subprocess.
If the error-workflow process arrives at a stop step, then error handling is considered failed. Both the error-workflow process and the main workflow terminate with the In Error state.
Recovery for a Workflow Process That Has Failed

For information about how to define recovery for a failed workflow process, see About the Workflow Recovery Manager on page 246.
17 1
Options for Developing a Workflow Process Using Batch Processing
Using Batch Processing

A workflow process can be run in batch by running the Workflow Process Batch Manager (WfProcBatchMgr) server component. Executing a workflow in batch allows you to execute the actions in a workflow for multiple records. If using the Workflow Process Batch Manager, then be sure to define the business object with which the workflow process is associated. You must also use a search specification in order to locate the business component records that are referenced or manipulated. NOTE: It is recommended that only a service workflow process or a 7.0 workflow process be run in batch mode. Table 28 describes parameters for the Workflow Process Batch Manager.
Table 28.
Parameters of the Workflow Process Batch Manager Description Required. Name of the workflow process to execute. Search specification that identifies the work items to process. The Search Specification parameter is a generic parameter that is shared by Workflow Management server components. However, this parameter is only used by the Workflow Process Batch Manager component. A Search Specification parameter that is defined for a component other than Workflow Process Batch Manager is not used.
Display Name Workflow Process Name Search Specification
For more information on running a workflow process in batch, see Siebel System Administration Guide.
Issuing a Component Request to Schedule a Batch Workflow

You can set up a batch to run a workflow process at a defined interval. For example, a workflow that runs at 7 A.M. every Monday. A component request is issued in order to schedule a batch workflow.
To issue a component request to schedule a batch workflow 1 2 3

In the Siebel client, navigate to the Administration-Server Configuration screen, Enterprises, then the Component Definitions view. In the Component Request form, click New. In the Component/Job field, click the selection button. The Component/Jobs dialog box displays.
4 5 6
Choose Workflow Process Batch Manager. In the Component Request Parameters form, click New. In the Name field, click the selection button, then choose Workflow Process Name from the dialog box.
172
7 8 9
In the Value field, type in the name of the workflow process to execute. Click New to add another parameter. In the Name field, click the selection button.
10 Choose Search Specification. 11 In the Value field, provide a search specification.
Usage of the Repeating Component Request

You can use the Repeating Component Request feature in conjunction with the workflow process to schedule the workflow component to be executed at a predetermined time. For an example workflow that benefits from a repeating component request, see Example of Defining a Workflow Process That Traverses a Record Set to Close Service Requests That Are Obsolete on page 264. For more information, see Siebel Server Administration Guide.
Usage of the Search Specification Parameter

You can define a search specification to limit the number of records that are evaluated when a workflow process is run in batch. If you do not define a search specification, then the Workflow Process Batch Manager executes the workflow for each record of a particular type in the Siebel application. For example, if there are 100 SRs, then the Workflow Process Batch Manager executes the workflow 100 times, one time against each SR. The Search Specification parameter on the Workflow Process Batch Manager is used to execute the search specification on the primary business component of the business object that is defined in the Business Object property of the workflow process. For each fetched record, the Workflow Process Batch Manager starts the workflow and sets the Object Id process property as the current active row.
Usage of the Workflow Process Batch Manager with Primary and Nonprimary Business Components
If running Workflow Process Batch Manager, and if the Link Specification property is set to TRUE on a field of the primary business component, then the number of records returned can be more than expected. This situation can affect performance, which is due to the fact that the value for the field is passed as a default value to a field in the nonprimary business component through a link. This situation occurs when the primary business component contains a link relationship with one or more nonprimary business components, as established through a Link on the current business object. Therefore, it is important to be careful when the business component is accessed by querying records in a custom business service or when running Workflow Process Batch Manager.
17 3
Comparison of Workflow Process Batch Manager to Workflow Process Manager

Use the Workflow Process Batch Manager server component when you must run the workflow process for every record of a particular business component. Workflow Process Batch Manager considers the primary business component that is associated with the business object property on the workflow. Workflow Process Batch Manager then runs the workflow on every record within that primary business component.
Considerations When Using a Custom Business Service The situation can change when the workflow process involves a custom business service. For example, assume the custom business service contains a loop that processes every record and executes the business service code on each record that is returned from the code itself. Table 29 compares how the two process managers compare in this situation.
Table 29.
Comparison of Using Workflow Process Manager to Workflow Process Batch Manager Description The business service, and the loop, handle every record at one time. This technique is the recommended way to execute this business service and workflow process. Because the business service for the workflow process already contains a loop, using Workflow Process Batch Manager causes the business service loop to execute for every record in the primary business component. This situation leads to undesirable duplicate and repeated execution.
Manager Used Workflow Process Manager
Workflow Process Batch Manager
174
Options for Developing a Workflow Process Defining a Workflow Process for a Multilingual Environment
Defining a Workflow Process for a Multilingual Environment

This topic describes how to define a workflow process to function correctly in a multilingual environment. It includes the following topics: Defining a Workflow Process to Function in a Multilingual Environment on page 175 Expressions in a Multilingual Environment on page 176 Wait Step and Global Time Calculations on page 176 Local Code Parameter and Data Format on page 177
For more information, see Siebel Global Deployment Guide.
Defining a Workflow Process to Function in a Multilingual Environment

To define a workflow process to function correctly in a language other than the base language, be sure your database is capable of handling Multilingual Lists Of Values (MLOV) for the type of non base language. For example, if you must modify a workflow to use FRA and the base language is ENU, then be sure that List of Values entries exist for the FRA language type.
Defining a workflow to function in a multilingual environment 1 2 3

In the Siebel client, navigate to the Administration-Data screen, then the List of Values view. Run the following query: Type = "WF_*". Run the MLOV upgrade utility to make sure the database is capable of handling a multilingual list of values. For more information, see Configuring Siebel Business Applications.
In the List of Values list, make sure the Active flag is set.
Literal Values in a Dynamic Picklist

Because a literal value is language dependent, a workflow process that references a literal value becomes language dependent and cannot be run in a multilingual environment. A literal value in a dynamic picklist potentially contains content that is created by the end user at run-time. Because these values are content based rather than metadata or LOV based, the makeup of this content is variable and, therefore, cannot be predictably interpreted by the workflow. For more information, see Deployment of a Workflow Process in a Multilingual Environment on page 214 and Siebel Global Deployment Guide.
17 5
Expressions in a Multilingual Environment

A workflow process uses the Display value to fetch records from tables. In a multilingual deployment, data in the tables is stored in Language Independent Code (LIC). To run a workflow in a multilingual environment, use the LookupValue function to fetch the LIC based on the Display value.
Decision Point Example

Assume a decision point compares Account Status to Active. The Account Status field is bounded by the Account Status picklist. You can set the Compare To property to Expression, and set the Expression property to the following code: [Account Status] = LookupValue ("ACCOUNT_STATUS", "Active")
Business Service Example

Assume a business service step calls the Outbound Communications Manager to send an email message to Expense Approver. The Recipient Group argument is bounded by the Comm Recipient Group picklist. You can set the Type property to Expression, and set the Value property to the following code: LookupValue ("COMM_RECIP_SRC", "Comm Employee") For more information on globalization, see Siebel Global Deployment Guide. For more information on defining Siebel Workflow to use MLOV capable fields, see Configuring Siebel Business Applications.
Wait Step and Global Time Calculations

Types of wait steps include: An absolute wait, which is a wait period governed solely by the duration that is defined. For example, an absolute wait that is set for 30 minutes waits 30 minutes from the time the wait is initiated by a wait step. A service calendar wait, which is not absolute. For example, a service calendar wait can be set to begin at 6 P.M., but if the service hours for the organization are 9 A.M. to 6 P.M., then the wait does not initiate until 9 A.M. the next morning. Therefore, it runs from 9 to 9:30 instead of 6 to 6:30.
Time Zone Setting with a Wait Step

If a workflow process is executing as a server task, then you must shut down, and then restart the Workflow Process Manager after making changes to the Time Zone user preference for the SADMIN user. The changes only go into effect after the Workflow Process Manager is restarted, which is important if you are implementing UTC, because it can be necessary for you to set the Time Zone user preference. Relations between the type of wait step and time zone settings include:
176
An absolute wait is not affected by time zone settings, including server and user time zone preferences. Use UTC with the database server. For more information, see Siebel Global Deployment Guide. A service calendar wait step requires a time zone for delay computations. In this case, the time zone for the current user is used.
Local Code Parameter and Data Format

The Workflow Process Manager (WfProcMgr) server component, similar to other server components, contains a parameter named Local Code which defines formats for data, such as dates, times, numbers, and currency. Note the following logic: If a workflow process runs within the Workflow Process Manager, then the Workflow Process Manager respects the Local Code setting and formats the data appropriately. If the workflow process communicates with an external application or writes data to a file, then date, time, number, and currency data is passed according to the format that is defined in Local Code.
17 7
178
Manipulating Data
This chapter describes reference information for manipulating and processing data with a workflow process. It includes the following topics: Accessing Data From a Run-Time Event From a Workflow Process on page 179 Passing Data to and from a Workflow Process on page 182 Timestamp Usage on page 188 Decision Conditions for a Workflow Process on page 188
For information on manipulating data validation rules, see Siebel Order Management Infrastructure Guide.
Accessing Data From a Run-Time Event From a Workflow Process

This topic explains how to access run-time event data from a workflow process.
To access data from a run-time event from a workflow process 1

If necessary, expose the WF Step Branch object type in the Object Explorer. For more information, see Exposing Object Types That Are Used to Develop a Workflow Process on page 116.
In the WF Step Branch OBLE, define the properties for a WF Step Branch using values described in the following table. Property Name Type Event Object Type Event Event Object Sub Event Comments Event Cancel Flag Value Enter a name for the branch. Condition Applet InvokeMethod Choose the name of the event object that starts the workflow process. NewRecord Optional The default is blank.
17 9
Manipulating Data Accessing Data From a Run-Time Event From a Workflow Process
Set up process properties in the Process Designer. For information, see About the Process Property on page 47.
Click the first step in your workflow process, then add a new output argument for each process property you must populate that references the run-time event. To add a new output argument, enter values into the fields that are displayed under the Output Arguments tab in the MVPW. Use the example values described in the following table. Field Property Name Type Value Value Enter a name for the property. Expression GetProfileAttr("RestrucOut") When you define the Profile Attribute field, note the name you give to each of the property values for the Profile Attributes. These are used in Step 9. Output Argument Business Component Name Business Component Field Comments Leave default value. Leave default value. Leave default value. Optional
Activate the workflow process. For more information, see Process of Deploying a Workflow Process on page 211.
Because the workflow process references run-time events, you must load the run-time events:
a b 7 8 9
Navigate to the Administration-Runtime Events screen, then the Events view. On the Events list, click Menu, then choose Reload Runtime Events.
Query the Event field for the run-time event you defined in Step 4. Drill down on the Action Set Name field. Add a new Action for each process property that is populated by using the run-time event. For example, you can define a new action to set the ACU Transaction ID and name it Set ACU Trans ID. Work you must perform for each new action includes:

Set the Action Type property to Attribute Set. Set the Profile Attribute to match the value you used in the GetProfileAttr call in the Process Designer in Step 4, such as TransType. Set the Set Operator value to Set. Use the expression builder to assign the Value field an appropriate value, such as the literal string FA-0001.
180
Manipulating Data Accessing Data From a Run-Time Event From a Workflow Process
Set the Sequence for the action to be less than the default sequence for the Workflow_XXXXXXX Action. Make sure the Sequence setting of the Workflow_XXXXXXX Action is the highest number so that this action happens after every other action. NOTE: If you modify the workflow process, then you must repeat this step because when a workflow is modified the sequence for the workflow action is reset to 1.
10 From the applet menu, choose Reload Runtime Events.
18 1
Manipulating Data Passing Data to and from a Workflow Process
Passing Data to and from a Workflow Process

This topic describes information about passing data to a workflow process and obtaining data from a workflow process. It includes the following topics: Passing an Input to a Workflow Process on page 182 Passing an Output From a Workflow Process on page 183 Passing a Parameter from a Workflow Process to a Global Variable on page 183 Passing a Constant from a Workflow Policy Action into a Workflow Process on page 183 Examples of Scripts That Pass Data to and from a Workflow Process on page 184
The Workflow Engine can be started by calling a business service. The Workflow Process Manager business service is a standard business service that is used for this purpose. If you run a workflow process by calling the Workflow Process Manager business service, then you can pass inputs to Siebel Workflow, and in some cases, obtain outputs from Siebel Workflow. While this topic discusses passing data to and from a business service step, keep in mind that the sub process step uses the same conventions for passing a property set. For more information, see In/Out Process Property on page 56.
Passing an Input to a Workflow Process

The input property set is required in order to contain the property named ProcessName, which specifies the name of the workflow process to be run. In addition to the ProcessName property, you can put other values, such as strings, numbers, and property sets, into the property set. These values are passed to the workflow process by the Workflow Process Manager business service. If the input property set contains a property in the top level property set with a name that matches the name of the property for the workflow process, then simple data type process properties, such as String, Number, and DateTime, that are marked In or In/Out, are initialized. The value of such a property in the input property set initializes the value of the matching process property for the workflow. If the input property set contains a child whose property set Type field contains a string that matches the name of the hierarchical process property for the workflow process, then hierarchical data type process properties that are marked In or In/Out are initialized. If such a match is found, then the matching child and everything below the child in the input property set is copied into the process property. Multiple variables can be passed into SQL Program Arguments. For more information, see Passing Multiple Variables to SQL Program Arguments on page 479.
182
Passing an Output From a Workflow Process

It is possible that a workflow process that is started programmatically does not return an output. For example, an interactive workflow can be started programmatically, but because it can pause, the output from the call to start the workflow might reflect the state at an intermediate point. For this reason, only a workflow that is guaranteed to run to completion in one call, that is, a service workflow, can be expected to provide output in the output arguments of the call into the Workflow Process Manager business service. An output argument uses the same convention as an input argument. Simple workflow process properties, such as String, Number, and DateTime, that are marked Out or In/Out, appear as properties on the top level property set. Hierarchical process properties appear as children of the output property set. Hierarchical process properties can be located by examining the Type field of the child, which matches the name for the process property.
Passing a Parameter from a Workflow Process to a Global Variable

You can use a business service to access and pass a parameter from a workflow process to a global variable. If an update is made to a global variable by using a Batch Manager task, then each Batch Manager task is, in essence, a separate user session. Therefore, an update that is made to a global variable by using a Batch Manager task might not be visible to a subsequent Workflow Process Batch Manager task. For more information, see Example of a Script That Accesses Parameters for a Workflow Process on page 186.
Passing a Constant from a Workflow Policy Action into a Workflow Process

You can use the Run Workflow Process program to pass a constant from a workflow policy action into a workflow process.
To pass a constant from a workflow policy action into a workflow process 1 2 3 4

In Siebel Tools, navigate to the Workflow Policy Program OBLE, then query the Name property for Run Workflow Process. Navigate to the Workflow Policy Program Arguments OBLE. Add a new argument. From the application-level menu, choose the File menu, then the Save menu item. For example, add a new argument with the Name property set to IOName. Make sure the Visible property contains a check mark.
5 6
In the Workflow Policy Program OBLE, click the Run Workflow Process object. From the application-level menu, choose the Tools menu, then the Compile Selected Object menu item.
18 3
Click Compile in the Object Compiler dialog. In the Siebel client, this argument is displayed in the Arguments list in the Workflow Policy Actions view.
Set the default value. The default value varies according to IOName.
Open the Process Designer for the workflow to which the constant is passed. argument in Step 3. For example, Name must be the same as IOName. For more information, see About the Process Property on page 47.
10 In the MVPW, define a new record with the Name argument set to the same name defined in the
11 Call the workflow policy.

For more information, see Starting a Workflow Process from a Workflow Policy on page 143.
Examples of Scripts That Pass Data to and from a Workflow Process

This topic describes examples of using a script to start a workflow process and for passing parameters.
Example of a Script That Starts a Workflow Process and Builds an Input Property Set
This topic gives one example of using a script to start a workflow process and to build an input property set. You might use this feature differently, depending on your business model. The following is an example script that calls the Workflow Process Manager business service that builds an input property set, psInputs, for the business service. This script defines strings that are put into the input property set as properties: var msgName = "Siebel Agent Authorization Retrieval"; var reqSubType = "CICS Services Request"; var reqType = "AgentAuthorizationReq"; var CICSServiceName = "Consumer Auto Agent Authorization Retrieval"; var processName = "Consumer Auto VBC VBC Template"; var reqFileName = "C:\\sea752\\XMLMessages\\AgentAuthorizationVBCReq-final.xml" var resFileName = "C:\\sea752\\XMLMessages\\AgentAuthorizationVBCResponsefinal.xml"
184
Example of a Script That Defines Property Sets for the Input Property Set
This topic gives one example of using a script to define property sets for the input property set. You might use this feature differently, depending on your business model. The following is an example script that defines property sets, which are put into the input property set as child property sets: //Request PS var psRequest = app.NewPropertySet(); var psAgentNumTag = app.NewPropertySet(); var psType = app.NewPropertySet(); var sAgentID;
Example of a Script That Builds Property Sets

This topic gives one example of using a script to build property sets. You might use this feature differently, depending on your business model. The following is an example script that builds property sets: //Build property set hierarchy sAgentID = app.LoginName(); psRequest.SetType("XMLHierarchy"); psAgentNumTag.SetType("DataAgentNumber"); psAgentNumTag.SetValue(sAgentID); psRequest.AddChild(psAgentNumTag);
Example of a Script That Assembles Properties and Child Property Sets into the Input Property Set
This topic gives one example of using a script to assemble properties and child property sets in the input property set. You might use this feature differently, depending on your business model. The following is an example script that assembles properties and child property sets into the input property set: psInputs.AddChild(psRequest);//Pass in Property Set psInputs.SetProperty("RequestURLTemplate", requestURLTemplate);//Pass in string psInputs.SetProperty("RequestSubType", reqSubType); psInputs.SetProperty("ReqType", reqType); psInputs.SetProperty("MessageName", msgName);
18 5
psInputs.SetProperty("CICSServiceName", CICSServiceName); psInputs.SetProperty("ProcessName", processName); psInputs.SetProperty("Request File Name", reqFileName); psInputs.SetProperty("Response File Name", resFileName);
Example of a Script That Calls the Workflow Process Manager Business Service and Passes the Input Property Set
This topic gives one example of using a script to call the workflow process manager business service and pass the input property set. You might use this feature differently, depending on your business model. The following is an example script that calls the Workflow Process Manager business service and passes the input property set to the Workflow Process Manager business service: var svc = TheApplication(). GetService(Workflow Process Manager); svc.InvokeMethod("RunProcess", psInputs, psOutputs);//Call the Workflow var sErr = psOutputs.GetProperty("sErr");//Check the Workflow status
Example of a Script That Accesses Parameters for a Workflow Process

This topic describes how to use a script to access workflow parameters for a running workflow process.
To define a script that accesses parameters for a workflow process 1 2 3

Define a business service that includes the relevant methods and parameters. Access the business service from the workflow process. In the business service step in the workflow process, pass the workflow process properties to the business service method arguments. For more information, see Passing a Process Property In and Out of a Step of a Workflow Process on page 57.
Use the following script to use the values of the business service argument and assign them to Profile Attributes: function Service_PreInvokeMethod (MethodName, Inputs, Outputs) { if( MethodName == "XXX" ) { var isWorkflowRunning, viewValidCurrent, viewValidNext; // read the input arguments into profile attributes isWorkflowRunning = Inputs.GetProperty("Workflow Running");
186
viewValidCurrent = Inputs.GetProperty("Valid View Current"); viewValidNext = Inputs.GetProperty("Valid View Next"); TheApplication().SetProfileAttr("WFRunning", isWorkflowRunning); TheApplication().SetProfileAttr("WFViewCurrent", viewValidCurrent); TheApplication().SetProfileAttr("WFViewNext", viewValidNext); }
Use the profile attributes for more processing. The necessary information is put into the profile attributes of the application. You can use the standard procedures for accessing the profile attributes to extract this information. For more information, see Siebel Personalization Administration Guide.
18 7
Manipulating Data Timestamp Usage
Timestamp Usage
You can use the timestamp to get the current system time and to do time arithmetic based on the current time. The arithmetic that involves time information for a workflow process is different from that for a workflow policy program. The second operand of the Timestamp () function must be provided in a scale of minutes, that is, as a fraction of the whole day. For example, if the intended result of an arithmetic operation is 30 minutes, then the argument is displayed according to the following syntax: Timestamp()+0.021 The operation is explained as follows: 0.021 is equal to 30 divided by (24 multiplied by 60) 24 multiplied by 60 represents a whole day in minutes 30 represents the required number of minutes
For more information, see Date Calculations in the Conditions List on page 375.
Decision Conditions for a Workflow Process

This topic describes information about using the Compose Condition Criteria dialog box in order to define decision conditions for a workflow process. It includes the following topics: Fields in the Compose Condition Criteria Dialog Box on page 189 Expressions in the Expression Builder on page 190
188
Manipulating Data Decision Conditions for a Workflow Process
Fields in the Compose Condition Criteria Dialog Box

Table 30 describes fields you set in the Compose Condition Criteria dialog box in order to define a decision condition. For more information, see Expressions in the Expression Builder on page 190.
Table 30. Field Compare To
Fields in the Compose Condition Criteria Dialog Box Description Indicates where the comparison value is coming from. Possible Value (Required). The following choices are available: Business Component Process Property Expression Applet
Operation
Identifies the comparison operation.
The following choices are available: This Must Match. The current value must match exactly, including case. One Must Match. One or more values must match exactly, including case. All Must Match. All of the values must match exactly, including case. None Can Match. None of the values can match exactly, including case. This Must Match (ignore case). The current value must match without regard to case. One Must Match (ignore case). One or more values must match without regard to case. All Must Match (ignore case). All of the values must match without regard to case. None Can Match (ignore case). None of the values can match without regard to case. Greater Than. Value must be greater than the comparison value. Less Than. Value must be less than the comparison value. Between. Value must be between a range of values. Not Between. Value cannot be between a range of values. Is Null. Value must be null. Is Not Null. Value cannot be null.
18 9
Table 30. Field Object
Fields in the Compose Condition Criteria Dialog Box Description The name of the associated business object. A required value when Applet is the Compare To value. Not applicable Possible Value This value is chosen from a picklist of business objects.
Field
The name of the field within the named applet.
Values
The Values property is dynamic based on the Compare To property. The Values property is used for storing data to be used in evaluating the decision condition.
Expressions in the Expression Builder

The Compose Condition Criteria dialog box uses the Expression Builder to define a decision condition. This topic describes parts of the Expression Builder, including Compare To options, operations, and patterns.
Compare To Options
Table 31 describes Compare To options and their required and optional values.
Table 31.
Compare To Options in the Compose Condition Criteria Dialog Box Operation Comparison operation. All operations are allowed. Comparison operation. All operations are allowed. Object The name of the applet. Field The column in the applet. Value One or more literals for comparison. One or more literals for comparison.
Compare To Applet. Compare the run-time value of an applet column to a literal. Business Component. Compare the runtime value of a buscomp field to a literal.
The name of the business component.
The field in the business component.
190
Table 31.
Compare To Options in the Compose Condition Criteria Dialog Box Operation Specifies how effects of multiple expressions stack. Only applicable when multiple values are defined in the Values property. The following choices are available: All Must Match None Can Match One Must Match This Must Match Object (Optional) If the field of a business component is referenced in the expression, then the object is the name of a business component. Fields of at most one business component can be referenced in the expressions. Field Not applicable Value One or more expressions.
Compare To Expression. Evaluate expressions and determine whether they return true.
For more information, see Simple Comparison Operation on page 192 and Substitution Variables That Are Commonly Used in an Expression on page 194. Process Property. Compare the runtime value of a process property to a literal. Comparison operation. All operations are allowed. The name of the process property. Not applicable One or more literals for comparison.
19 1
Simple Comparison Operation

A simple comparison operation involves a comparison that can be expressed in a simple expression without the requirement for an iterative operation. Table 32 describes values for a simple comparison operation.
Table 32.
Values for Simple Comparison Operations Run-Time Value That Results in a Successful Comparison Between two predefined literal values. Not between two predefined literal values. Greater than a predefined literal value. Less than a predefined literal value. Null or empty. Not null or empty.
Comparison Between
Description This comparison requires two values in the Values property, which is enforced by the Process Designer. This comparison requires two values in the Values property, which is enforced by the Process Designer. Logically, only one value is required in the Values property. Logically, only one value is required in the Values property. No value is required in the Values property. No value is required in the Values property.
Not Between
Greater Than Less Than Is Null Is Not Null
Iterative Comparison Operation

An iterative comparison operation involves multiple iterations on the literal values or expressions in the Values property, or iterations on child business component records, in order to derive a Boolean result. The following ways can be defined that result in different iterative behavior: When multiple values are defined in the Values property. When multiple records of the child business component exist in the current workset. A child business component is a business component that is not the primary business component in the current business object on which the workflow process is working. If the Compare To option is set to Business Component or Expression, and the Object field is defined as the name of a child business component, then a child business component is involved in the comparison. If multiple records were returned when the child business component was last executed, then multiple records can exist in the current workset of the child business component.
192
All Must Match Operation The following options are available for the All Must Match operation: Multiple value behavior. If the Compare To option is something other than Expression, and if at least one value matches, then a literal is defined and this comparison succeeds. If the Compare To option is Expression, and if each expression evaluates to true, then this comparison succeeds. Multiple child buscomp record behavior. If the comparison succeeds for every one of the records, then child business component records are used for comparison and the overall comparison succeeds. Consider an example where All Must Match and multiple child business components are used. In this example, Account is the business object, and the decision condition is described in the following table. Compare To Operation Object Field Values
Business Component
All Must Match
Contact
First Name
Jane, Julie
In this example, records for the Contact business component in the current workset must contain a first name of Jane or Julie in order for the comparison to succeed. In this example, the workset is the child contact record for the particular account record that the workflow process is processing.
This Must Match Operation For the comparison to succeed, field values of the active row of the current instance of the child business component must match the values for the decision condition that is defined for the connector. If Remote Asynchronous is used, then the workflow process is resumed from the Workflow Process Manager. Because the instance of the child business component is not preserved in the Workflow Process Manager, the active row for the child business component is lost. For this reason, the branch connector stops working. If you must use Remote Asynchronous, then use an operation other than This Must Match. Otherwise, use Local Synchronous. Options for the This Must Match operation include: Multiple value behavior. If the values involved are literal values, and at least one value matches, then the comparison succeeds. If the values involved are expressions, and if at least one expression is evaluated to true, then the comparison succeeds. Multiple child buscomp record behavior. If the comparison succeeds for the current record, then only the current record of the child business component is used for comparison and the overall comparison succeeds.
19 3
None Can Match Operation Options for the None Can Match operation include: Multiple value behavior. If the values involved are literal values, and if none of the values match, then the comparison succeeds. If the values involved are expressions, and if none of the expressions evaluate to true, then the comparison succeeds. Multiple child buscomp record behavior. If the comparison fails for every one of the records, then records of the child business component are used for the comparison and the overall comparison succeeds.
One Must Match Operation Options for the One Must Match operation include: Multiple value behavior. If the values involved are literal values, and if at least one value matches, then the comparison succeeds. If the values involved are expressions, and if at least one expression is evaluated to true, which is the same as This Must Match, then the comparison succeeds. Multiple child buscomp record behavior. If the comparison succeeds for at least one of the records, then records of the child business component are used for comparison and the overall comparison succeeds.
Other Iterative Comparison Operators Other iterative comparison operators include: All Must Match (Ignore Case) Same as All Must Match except string comparisons are case insensitive. This Must Match (Ignore Case) Same as This Must Match except string comparisons are case insensitive. None Can Match (Ignore Case) Same as None Can Match except string comparisons are case insensitive. One Must Match (Ignore Case) Same as One Must Match except string comparisons are case insensitive.
Substitution Variables That Are Commonly Used in an Expression

A process property or a field in a business component is often used as a substitution variable in an expression. For more information see Referencing a Process Property on page 60 and Referencing a Field in a Business Component on page 195. For more information about the operators, expressions, and decision conditions that can be used in a workflow process, see Siebel Developers Reference.
194
Referencing a Field in a Business Component The syntax is [FieldName]. For example, the following syntax is used for the business component named Contact: [First Name] like 'Jane' where: First Name is the name of the field
The business component itself is defined in the Object field of the Expression Builder.
Example of Using an Expression to Compare Values An expression can be used to compare the value of a process property Object Id to that of the Contact business component and Account Id field, as described in the following table. Compare To Expression Operation This Must Match Object Contact Values [Account Id] like [&Object Id]
19 5
196
10 Testing a Workflow Process

This chapter describes how to test your workflow process. It includes the following topics: About the Testing Tools on page 197 Process of Testing a Workflow on page 202 Troubleshooting Validation and Simulation Problems on page 208
For more information about developing planning strategies for testing the Siebel application, see Testing Siebel Business Applications.
About the Testing Tools

This topic describes tools you can use to test a workflow process. It includes the following topics: Validate Tool on page 197 Process Simulator on page 198 Business Service Simulator on page 201 Event Logs on page 201
Validate Tool
The Validate Tool is an error correction tool you can use before you simulate and deploy a workflow process. Validation enforces the semantic consistency of a workflow that otherwise cannot be readily enforced by structural constraints. For example, by using validation, you can make sure an errorworkflow process does not itself contain an error-workflow process. When you validate a workflow, warnings are displayed that describe errors that the workflow contains. You can then correct the errors before running the Process Simulator. If there are validation errors, then a dialog box displays, which provides you an opportunity to correct errors before publishing. This dialog box is modeless, meaning that you can keep it open to view the error messages while using the Process Designer to correct the problems reported. You can proceed with deployment despite validation errors if you choose to do so. The ways that you can launch the validate tool for a workflow process include: Use the context sensitive right-click menu in either the Process Designer or the Workflow Processes Object List Editor (OBLE) Use the Publish or Publish/Activate buttons on the WF/Task Editor Toolbar
19 7
Testing a Workflow Process About the Testing Tools
For more information, see: Validating the Workflow Process on page 202 Troubleshooting Problems That Occur During Validation on page 208
Process Simulator
The Process Simulator is a simulation tool that allows you to step through a workflow process while you view the results of each step. Simulating your workflow process before deploying it to your production environment helps to verify that the workflow produces the expected results. For more information about: How the Process Simulator works, see Simulation Architecture of a Workflow Process on page 28 How to use the Process Simulator, see Preparing to Use the Process Simulator on page 203 Using the Business Service Simulator in cases where the process simulator cannot be used, see Business Service Simulator on page 201
Workflow Mode and the Process Simulator

Most workflow processes can be tested and debugged using the Process Simulator, which is hosted in Siebel Tools. You can use the Process Simulator to test a workflow that runs in the Siebel client, including a service workflow, a 7.0 workflow, an interactive workflow, and a workflow that is based on a run-time event. You cannot use the Process Simulator to test a long-running workflow or a workflow that involves a server component.
Workflow Process Testing with a Server Component

You cannot use the Process Simulator to test a workflow process that involves a server component, such as Workflow Process Manager, Server Request Broker, Assignment Manager, or Communications Server. If a workflow process that involves a server component is run in the Process Simulator, then incorrect behavior results. To test a workflow that involves a server component, the workflow must be deployed to the run-time environment and tested by using the application server. For example, if you must test a workflow process that calls Siebel Assignment Manager, then deploy the workflow to the run-time environment. You export the workflow from Siebel Tools and import it to the Siebel client. Then you test the workflow in real time with the working server components.
Starting a Workflow Process with the Process Simulator

Of the various ways to start a workflow process, starting a workflow from the Process Simulator is an easy way to test and debug a workflow. You can debug steps of the workflow as you define them in Siebel Tools, where the Process Designer and the Process Simulator both reside.
198
When the workflow process is run from the Process Simulator, it runs in the Application Object Manager (AOM). The workflow can be started in the Application Object Manager or in the Workflow Process Manager server session, depending on specific parameters. Because some workflows that can run in the Workflow Process Manager server session might not be able to run in the application object manager, it is possible that every workflow cannot be simulated. Other ways to start a workflow process involve starting the workflow outside of Siebel Workflow. For more information, see Starting a Workflow Process on page 143. For information about starting a workflow from a server component, see Overview: Siebel Enterprise Application Integration and Siebel eMail Response Administration Guide.
Preparing the Simulator for Use with a Script

You can use the Process Simulator with a workflow process that references a business service or business component that contains a script. However, if that script contains a breakpoint, and if the Arguments field in the Siebel Tools debug configuration contains /h, then the Simulator might not perform as expected. A breakpoint is a marker on a line of Basic code that tells Basic to suspend execution at that line so that the state of the program can be examined by using the Siebel Debugger. The /h argument directs the Siebel debugger to open the Watch window.
To prepare the simulator for use with a script 1 2

Remove every breakpoint from the script on a business service or a business component that is referenced by the workflow process. Remove the /h argument from the Siebel Tools debug configuration:
a b c
From the Tools application-level menu, choose the View menu, then the Options menu item. Click the Debug tab. Remove the /h argument from the Argument field.
For more information, see Using Siebel Tools.
Using the Watch Window

The Process Simulator includes a Watch window that dynamically displays values for the business component and process property of the workflow process. These values are associated with and are manipulated by the workflow that is simulated. For more information about: An example that uses the watch window, see Testing the Workflow Process on page 274 Using the watch window in conjunction with the Workflow Utilities business service, see Workflow Utilities Business Service on page 487
19 9
To use the watch window 1 2 3

From within the Process Designer for the workflow process you must simulate, right-click the canvas, then choose Simulate. Click Start Simulation, then wait for the Siebel client to launch and return control to Siebel Tools. Right-click the canvas of the Process Simulator, then choose Watch Window. In the Watch window, the left column displays the name of the property set type. The right column displays the current value for the property. The Watch window is not available until after you perform Step 2. You must start the simulation and wait for control to return to Tools prior to opening the Watch window.
Guidelines for Using the Watch Window Guidelines when using the Watch window include: You can hide the Watch window by right-clicking, then choosing Hide Watch Window. If the Watch window is empty, then right-click the canvas of the Process Simulator, and then choose Watch Window, thus refreshing the display. In addition to opening the Watch window from within the Process Simulator, you can also open the Watch window by choosing, from application-level menu, the View menu, Debug Windows, then the Watch menu item.
Property Set of the Watch Window A value that is manipulated by the simulation is dynamically updated and displayed in the Watch window as each step finishes during the simulation. Table 33 describes information that is available in the Watch window.
Table 33.
Property Set of the Watch Window Description Displays real-time status information for the simulation. For example, Step Completed, or Simulation Ended Successfully.
PropertySet Simulator Status
Process Properties
Displays the current value for each process property that is defined for the workflow process. For example, the value 7-4HWSV displays for the Object Id process property.
BusComp
Displays business component user data for fields in the business component for the record that is currently processed by the simulator. For example, the value 40000 displays for the Revenue field.
200
Business Service Simulator

A workflow process can be run as a business service from the Business Service Simulator in the Siebel client. Use the Business Service Simulator when you must debug a script in conjunction with a workflow. You can set breakpoints in the script, then execute the workflow in the Siebel Mobile Web Client. If the workflow executes a service for which a breakpoint is set, then control is returned to the Script Debugger in Siebel Tools. The workflow process must be published and activated before the workflow can be tested with the Business Service Simulator. The requirements to use the simulator include: The Siebel Mobile Web Client must be installed The workflow process must be exported from Siebel Tools The workflow process must be imported to the Siebel client
TIP: Alternatively, you can publish and activate the workflow process to the Siebel Mobile Web Client directly from Siebel Tools. For more information about using the Business Service Simulator, see Diagnosing a Workflow Process That Has Failed on page 240.
Event Logs
You can set monitoring levels for event logs so that you can view detailed information about the execution of a workflow process. This technique is useful if you cannot perform real-time debugging or if the Process Simulator is not readily available. However, using this technique can result in large log files that must be analyzed. For more information, see Setting Monitoring Levels for Tracing and the Event Log on page 236. For information on using the Log File Analyzer, see Siebel System Monitoring and Diagnostics Guide.
20 1
Testing a Workflow Process Process of Testing a Workflow
Process of Testing a Workflow

This process is a step in Roadmap for Developing a Workflow Process on page 97. To test a workflow process, perform the following tasks:
1 2 3 4
Validating the Workflow Process on page 202 Preparing to Use the Process Simulator on page 203 Using the Process Simulator on page 204 Verifying Functionality on page 206
Before you deploy a workflow process, you must test it in a test environment. Testing a workflow verifies that the workflow you release into the production environment executes properly and does not cause conflicts with another workflow. Guidelines for setting up your test environment include: Make sure your test environment and production environment contain identical versions of the software Use realistic data by using a partial or full copy of the production database
For more information about: Validation and simulation tools, see About the Testing Tools on page 197 Example that includes detailed instructions, see Testing the Workflow Process on page 274
Validating the Workflow Process

This task is a step in Process of Testing a Workflow on page 202. You can validate a workflow process.
To validate a workflow process 1

Right-click the workflow process, then choose Validate. The Validate dialog box displays.
Click Start.
Starting validation displays in the bottom left corner of the Validate dialog box.
If the validation is successful, then there are no errors to report and a message displays in the bottom left corner of the dialog box, Total tests failed: 0.
202
If the validation is not successful, then a list of errors are displayed along with the rules that each error violates. In this case, perform one of the following actions:
a b
Click the error to view the message in the Details window of the dialog box. Save the errors to a log file by clicking Save As at the bottom of the validation panel.
Every error is not fatal. Some errors are only warnings. For more information, see Troubleshooting Problems That Occur During Validation on page 208.
Preparing to Use the Process Simulator

This task is a step in Process of Testing a Workflow on page 202. In this task, you prepare to use the process simulator.
To prepare to use the process simulator 1

Make sure the Siebel Mobile Web Client is installed. The Siebel Mobile Web Client can connect to a development or local database that contains the test data that is required to debug a workflow.
If necessary, publish subprocesses that are called by the workflow process you are simulating. To avoid a validation error, you must publish and activate subprocesses that are called by the workflow process you are simulating prior to calling the simulator. For more information, see Publishing a Workflow Process on page 216.
If necessary, expose the simulate toolbar. For more information, see Preparing Siebel Tools to Develop a Workflow Process on page 115.
4 5 6
From the application-level menu, choose the View menu, then the Options menu item. Click the Debug tab. Define the fields in the Debug tab using values from the following table, where $ represents settings that are specific to your setup. Field Executable Value $SiebelClient\BIN\siebel.exe Make sure you enter the full path for the siebel.exe executable file. CFG file $SiebelClient\BIN\ENU\uagent.cfg Make sure you enter the full path for the uagent.cfg configuration file. Browser Working directory Arguments $\Program Files\Internet Explorer\iexplore.exe $SiebelClient\BIN /h
20 3
Field User name Password Data source
Value $username $password $datasource
Click OK.
Using the Process Simulator

This task is a step in Process of Testing a Workflow on page 202. In this task, you run the Process Simulator on a workflow process. For more information about: Usage guidelines, see Guidelines for Using the Process Simulator on page 206 Examples that use the simulator, see Testing the Workflow Process on page 274, and Testing the Workflow Process on page 283
CAUTION: If testing a workflow process by using the Process Simulator, then it is important to note that the workflow runs just as if it were called in a production environment. For instance, if the workflow includes a Siebel operation, such as update or add, then records in the database are modified when you run the Process Simulator. Also, your test environment and production environment must contain identical software versions.
To use the process simulator 1

Close every Siebel client session. To avoid encountering a multiple client session error, you must close every client session prior to launching the Process Simulator. If a Siebel client session is running, then you cannot start the Process Simulator.
2 3
Make sure there are no Siebel client icons in the Task Bar. Locate the workflow process you must modify. For more information, see Locating a Workflow Process in the Workflow Processes Object List Editor on page 43.
Right-click the Workflow Process. As an alternative, you can launch the simulator from within the Process Designer. To do so, launch the Process Designer for the workflow process you must simulate, right-click the canvas of the Process Designer, then choose Simulate.
204
Choose Simulate Workflow Process. The Process Simulator opens. A read only version of the workflow process displays with a pale yellow canvas, the start step is highlighted, and the Start Simulation button on the Simulate toolbar is active.
In the Simulate toolbar, click Start Simulation to begin the simulation. The Simulation In Progress dialog box displays momentarily.
Observe the Siebel client launch, then wait for control to return to Tools. A new instance of the Siebel client launches according to the debug settings you entered in Preparing to Use the Process Simulator on page 203. You use this Siebel client instance as the run-time environment for the simulation. There is no other work you must perform in this Siebel client instance unless the simulated workflow process is an interactive workflow. For more information, see Simulating an Interactive Workflow Process on page 206 After the Siebel client initializes, the Simulation In Progress dialog box disappears, control passes back to Siebel Tools, the start step executes, then control pauses at the next step in the workflow process. If the first step executes as expected, then the next step of the workflow is highlighted in the Process Simulator view.
8 9
In the Simulate toolbar, click Simulate Next to execute the highlighted step. Continue clicking Simulate Next until the last step finishes. As you step through the workflow process, examine results of each step in the Watch window until the workflow process finishes. For more information, see Using the Watch Window on page 199.
10 If the workflow process does not execute as expected, then correct the problem, and then restart
the simulation at Step 6. For more information, see Troubleshooting Problems That Occur During Simulation on page 209.
11 (Optional) Examine test results in the Siebel client.

If your workflow process manipulates record data, you might be able to examine test results in the Siebel client. For an example, see Testing the Workflow Process on page 262.
12 Close the Simulator window.

After the last step of the workflow process executes, the simulation automatically ends. You can also use the Stop Simulation button to halt the simulation before the last step executes.
20 5
Guidelines for Using the Process Simulator

Guidelines when using the Process Simulator include: In the Siebel client, if the workflow process does not contain a user interact step, then do not navigate or click UI elements while using the Process Simulator. If you must navigate in the Siebel client, then it might be necessary to close the Siebel client and Siebel Tools, then open Siebel Tools to rerun the Simulator. In Siebel Tools, do not navigate outside of the Process Designer while the Process Simulator is running. After the Siebel client launches, it might be necessary to ALT+TAB back to Siebel Tools to proceed with the simulation. You can use the Process Designer to make changes to step properties, then return to the Process Simulator to test the workflow process. To make changes to step properties, first stop the Process Simulator, then restart the simulation after changes are made. You can hide the Object Explorer and the Properties window to better view your work in Siebel Tools. You can also resize the Siebel Tools window so that it covers only a part of the visible display area. If a wait step is defined in seconds, then the Workflow Process Simulator simulates a wait period. However, if the unit of time is defined in minutes or greater, then the Simulator simply moves on to the next step. It is not necessary for a workflow process to be active in order to run it in the Process Simulator. The simulator ignores activation date, expiration date, and status.
Simulating an Interactive Workflow Process

If using the process simulator with an interactive workflow process, then you must perform some actions in the Siebel client while the simulator is running.
To simulate an interactive workflow process 1

While running the process simulator, when the highlighted step is a user interact step, click Simulate Next. The corresponding view that is defined for the step displays in the Siebel client.
Switch to the Siebel client, then make sure the run-time event is executed in the client according to the definition for the user interact step. After the user interact step is executed successfully in the Siebel client, control is passed back to Siebel Tools, and the highlight moves to the next step in the workflow process.
Verifying Functionality
This task is a step in Process of Testing a Workflow on page 202.
206
To finish testing a workflow process, you can verify that the workflow implements the functionality that is necessary to meet your business requirements. Verification is often performed by manipulating data in the Siebel client, then verifying that execution of the workflow matches the functionality that was defined during the planning phase. For an example, see Verifying Functionality of the Workflow Process on page 303.
20 7
Testing a Workflow Process Troubleshooting Validation and Simulation Problems
Troubleshooting Validation and Simulation Problems

This topic describes guidelines for resolving validation and simulation problems with a workflow process.
Troubleshooting Problems That Occur During Validation

To resolve a problem that is detected by the Validate tool, look for it in the list of Symptoms/Error messages in Table 34.
Table 34.
Problems That Occur During Validation Diagnostic Steps or Cause Not applicable Solution Make sure connectors for the workflow process are connected correctly. Make sure you define at least one conditional branch that emanates from each Decision point in the workflow process. Make sure each business service step in the workflow process is not missing a business service or a business service method. Make sure you define the business component upon which each Siebel operation step acts. Make sure each sub process step specifies the appropriate subprocess that is called by the workflow process.
Symptom or Error Message Connector is not attached correctly. Conditional branch not is defined for a Decision point.
Not applicable
Business service and business service method are not defined for a business service step. Business component is missing from a Siebel Operation step. Name of the subprocess is not defined for a sub process step.
Not applicable
Not applicable
Not applicable
208
Troubleshooting Problems That Occur During Simulation

To resolve a problem that is detected by the Simulation tool, look for it in the list of Symptoms/Error messages in Table 34.
Table 35.
Problems That Occur During Simulation Diagnostic Steps or Cause If a run-time event is defined on the connector that emanates from a start step, then the simulator waits for the event and never reaches the next step. Solution Choose one of the following: Remove the run-time event from the simulation. Add a Default branch. NOTE: It is recommended you define two branches: one with Type set to Condition, to wait for the run-time event, and the other with Type set to Default. Do not navigate in the Siebel client while the process simulator is running or after the simulation ends. For more information, see Guidelines for Using the Process Simulator on page 206. Make sure the branches out of the user interact step contain the respective run-time events that are associated with actions performed on the user interact step. Restart processes that are currently running. For more information, see Restarting the dbeng9.exe and siebel.exe Processes on page 210.
Symptom or Error Message When attempting to simulate a workflow process, upon starting the workflow process, the process simulator does not run.
When attempting to rerun the process simulator, an error dialog displays Still waiting on Workflow Process Simulator, or The run-time client is not responding. After completing the user interact step, the process simulator fails to proceed down the workflow process.
Navigating in the Siebel client during or after running the process simulator can cause a failure during subsequent attempts at running the simulator. A branch out of a user interact step might be missing an associated runtime event.
After the Siebel client launches, control does not return to Siebel Tools, or a dialog in Siebel Tools indicates that the client is still launching, even after a long wait. An error message displays while the simulation is executing, similar to Error loading siebel operation step definition [step name]. The defined step definition is not valid.
Not applicable
Errors in the configuration of the workflow process are revealed during the simulation, which can include errors in how objects are defined or how objects are used by the workflow.
Close the process simulator, correct the configuration errors, then run the simulation again.
20 9
Restarting the dbeng9.exe and siebel.exe Processes

This topic describes how to restart the dbeng9.exe and siebel.exe processes.
To restart the dbeng9.exe and siebel.exe processes 1 2 3 4 5

Log out of the Siebel client session and close Siebel Tools. Open Windows task manager. Click the Processes tab, right-click the dbeng9.exe Image Name, choose End Process, then click Yes. Right-click the siebel.exe Image Name, choose End Process, then click Yes. Restart Siebel Tools, then run the simulation again.
210
11 Administering a Workflow Process

This chapter describes how to administer a workflow process. It includes the following topics: Process of Deploying a Workflow Process on page 211 Process of Migrating a Workflow Process on page 218 Process of Administering a Workflow Process on page 227 Monitoring a Workflow Process on page 233 Diagnosing a Workflow Process That Has Failed on page 240 About Upgrading a Workflow Process on page 253
Process of Deploying a Workflow Process

This process is a step in Roadmap for Developing a Workflow Process on page 97. To deploy a workflow process, perform the following tasks:
1 2 3
Preparing the Run-Time Environment on page 212 Publishing a Workflow Process on page 216 Activating a Workflow Process on page 216
Defining and deploying a workflow process can occur separately. After you define a workflow in the Process Designer in Siebel Tools, you deploy it by preparing the run-time environment, publishing it in Siebel Tools, then activating it in the Siebel client. When deploying, the workflow process is read from the repository, then Siebel Workflow writes it to the run-time environment as XML. You can use the Replication, Activation Date, Expiration Date, and Monitoring Level parameters during deployment. For more information, see Setting Monitoring Levels for a Workflow Process on page 233. For a conceptual overview of this topic, see Deployment Architecture of a Workflow Process on page 30.
21 1
Administering a Workflow Process Process of Deploying a Workflow Process
Preparing the Run-Time Environment

This task is a step in Process of Deploying a Workflow Process on page 211. This topic describes work you must perform in order to make sure the run-time environment is capable of running the workflow process. It includes the following topics: Making Sure an Object That Is Referenced by the Workflow Process Is Current on page 212 Activating a Field That Is Used by a Workflow Process on page 212 Deploying a Workflow Process to the Siebel Mobile Web Client on page 213 Deploying a Workflow Process on a Regional Node on page 214 Deployment of a Workflow Process in a Multilingual Environment on page 214 Deploying a Workflow Process as a Web Service on page 215
Although it is not required that you perform these topics in the order presented, you must consider each topic to determine if it applies to the workflow process you are deploying.
Making Sure an Object That Is Referenced by the Workflow Process Is Current

If the workflow process you are deploying contains a sub process step or references a new repository object, such as a business component, business service, or view, then you must make sure the subprocess or repository object is available to the workflow you are deploying.
To make sure an object that is referenced by the workflow process is current

Perform one of the following:

In the case of a sub process step, deploy the subprocess before you deploy the parent workflow process so that the subprocess is accessible to the parent. In the case of new repository objects, first compile the new repository objects so they are accessible to the workflow process you are deploying.
Activating a Field That Is Used by a Workflow Process

A field that is not activated by the Object Manager must be activated for Siebel Workflow in order to reference and use it. Note the following: If a field is exposed on the user interface, then it is activated by the Object Manager, and a workflow process that runs on the Object Manager that references this field can run properly. If a field is not exposed on the user interface, then it is not activated by the Object Manager. In this case, a workflow process that runs on the Object Manager cannot use the field, and an error is generated.
212
To activate a field that is used by a workflow process

Perform one of the following:

In Siebel Tools, in the Fields Object List Editor (OBLE), explicitly activate the field by setting the Force Active property of the field to TRUE. Expose the field on the user interface. Activate the field through a script, such as a business service that activates the field to be used before the workflow process uses it.
Deploying a Workflow Process to the Siebel Mobile Web Client

The Replication field in the Workflow Deployment view allows you to choose whether to route a workflow process to your Siebel Mobile Web Client (MWC). Routing only the workflow that your Siebel Mobile Web Client requires allows you to reduce the amount of data in the local database.
To deploy a workflow process to the Siebel mobile web client 1 2

Navigate to the Administration-Business Process screen, Workflow Deployment, then the Active Workflow Processes view. Define the Replication field using values from the following table. Value All Regional None Description The workflow process is routed to Siebel Mobile Web Clients and regional nodes. The workflow process is routed to the regional nodes only. (Default) The workflow process is not routed to the Siebel Mobile Web Client or the regional nodes.
For more information, see Deploying a Workflow Process on a Regional Node on page 214.
Restrictions for Routing with the Siebel Mobile Web Client If modifying the Replication field to choose whether to route a workflow process to your MWC, then keep in mind that changing the Replication field value from None to All adds the workflow process and related records to the MWC or regional node when it synchronizes with the server.
Testing Routing Behavior with Full Copy Nodes If you extract a regional node with the routing group set to FULL COPY, then a workflow process with Replication set to None is routed to the MWC.
21 3
To test routing behavior with full copy nodes 1 2 3

Modify two existing or define two new workflow processes, one with Replication set to All and the other with Replication set to None. Extract a regional node with the routing group set to FULL COPY. Examine the dx file in the outbox of the regional node to make sure that both workflow processes were routed.
Behavior When Using a Run-Time Event with a Mobile Client There is some variation in the way a run-time event performs in a mobile client when compared with other Siebel client types. NOTE: It is recommended that the processing mode be Local synchronous or remote asynchronous. If remote asynchronous is used for a mobile client, then the workflow process is started after you synchronize with the server. For more information, see Remote Synchronous Processing on page 150.
Notification to Mobile Users Who Are Not Synchronized You can define a workflow process to send a notification email to mobile users who are not synchronized. For more information, see 476188.1 (Doc ID) or 476275.1 (Doc ID) on OracleMetaLink 3.
Deploying a Workflow Process on a Regional Node

You can execute a workflow process on a regional node. The workflow can be called from a script or a run-time event.
To deploy a workflow process on a regional node

Make sure the workflow process resides on the regional node. The settings and environment must be replicated entirely on the node. The objects that the workflow references must be available on the regional node.
Deployment of a Workflow Process in a Multilingual Environment

A workflow process deployed from the object manager for a language is not available on the object manager for another language until after a restart is executed. If deploying a workflow process that is used in a multiple language deployment, then the object managers for each language must be restarted. For example, assume you define a workflow process that is called in the write record event for a business component through scripting. You publish and activate this workflow, then restart the servers. You see that the workflow is called both for callcenter_enu and callcenter_esn. Then you revise and publish this workflow from Siebel Tools. From within callcenter_enu, you activate the workflow. You see that callcenter_enu uses the revised workflow, but callcenter_esn does not. If you activate this workflow in callcenter_esn, then an error results. You must restart the callcenter_esn object manager to get the new workflow process to function correctly.
214
Deploying a Workflow Process as a Web Service

A workflow process can be deployed as a Web service.
To deploy a workflow process as a Web service 1

In Siebel Tools, in the Workflow Designer, examine definitions in the MVPW in order to determine if the Data Type field for a process property is set to Integration Object. If so, make sure a value is defined in the Integration Object field for each of those process properties. If hierarchical data in a business service is used by the workflow process, then you must set Data Type for the process property to Integration Object, then define an integration object in the Integration Object field. If no integration object is defined, then the following error occurs: The selected workflow process contains hierarchy type process properties without having the integration object name defined. For more information, see About the Process Property on page 47.
Make sure the workflow process you must deploy is published and activated. For more information, see Publishing a Workflow Process on page 216.
Locate the workflow process that you must modify. For more information, see Locating a Workflow Process in the Workflow Processes Object List Editor on page 43.
4 5
Right-click the workflow process, then choose Deploy as Web Service. The Expose Workflow Process as Web Service dialog displays. In the top window of the dialog, define the operation name for the new Web service. Typically, you define the underlying method name of the business service without spaces, such as CreateAccount. Use a method for a business service that is defined in the workflow process.
In the bottom window of the dialog, define the URL that identifies the address for the Web service. Replace [webserver] with a valid host name and [lang] with a valid language code, such as enu. (Optional) To generate a Web Services Description Language (WSDL) file, click the Generate WSDL checkbox, then define a location to save the WSDL file. Click Finish. The Web service is generated.
7 8
21 5
To view the Web service you just generated:
a b
In the Siebel client, navigate to the Administration-Web Services screen, then the Inbound Web Services view. Query the Name column in the Inbound Web Services list for the workflow process name you clicked in Step 4.
To display Web services that are generated from workflow processes and business services, query the Namespace column for http://siebel.com/CustomUI. For more information, see Integration Platform Technologies: Siebel Enterprise Application Integration.
Publishing a Workflow Process

This task is a step in Process of Deploying a Workflow Process on page 211.
To publish a workflow process 1

Locate the workflow process you must publish. For more information, see Locating a Workflow Process in the Workflow Processes Object List Editor on page 43.
In the WF/Task Editor toolbar, click Publish. For more information, see About the Process Property on page 47.
Next, activate a workflow process.
Activating a Workflow Process

This task is a step in Process of Deploying a Workflow Process on page 211. The first procedure in this topic describes how to activate a single workflow process. The second procedure describes how to activate workflow processes in batch. For more information, see Activate Button in the Siebel Client on page 63.
Activating a Single Workflow Process

You can activate a single workflow process.
To activate a single workflow process 1 2 3

Log in to the Siebel client with administrator privileges, connected to the appropriate database. Navigate to the Administration-Business Process screen, then the Workflow Deployment view. In the Repository Workflow Processes list, query the Name field for the workflow you published in Step 2 on page 216.
216
4 5 6
Make sure the workflow process is chosen. Click Activate. In the Active Workflow Processes list, set the deployment parameters for the workflow process:
a b c d
If necessary, query the Name field for the workflow you just activated. Set the activation date in the Activation Date/Time field. Set the expiration date in the Expiration Date/Time field. Make sure Replication is set to None, unless you are deploying the workflow process to the Siebel Mobile Web Client. If you are deploying the workflow process to the Siebel Mobile Web Client, then see Deploying a Workflow Process to the Siebel Mobile Web Client on page 213.
e 7
Set the monitoring level in the Monitoring Level field. For more information, see Setting Monitoring Levels for a Workflow Process on page 233.
If a run-time event is defined in the workflow process, then you must reload the run-time events:
a b
Navigate to Administration-Runtime Events. Click the applet menu, then choose Reload Runtime Events. This step reloads the run-time events in the current object manager session. For an example, see Deploying the Workflow Process on page 286. For more information, see Siebel Personalization Administration Guide.
Now you can start the workflow process through the Process Simulator, a script, or a workflow policy. For more information, see Starting a Workflow Process on page 143.
Activating a Batch of Workflow Processes

You can activate a batch of workflow process.
To activate a batch of workflow processes 1 2 3

In the Siebel client, navigate to the Administration-Business Process screen, then the Workflow Deployment view. In the Repository Workflow Processes list, query the Name field for the workflow processes you must activate. Choose the workflow processes you must activate, then click Activate. NOTE: It is recommended that you do not choose every workflow process in the list.
21 7
Administering a Workflow Process Process of Migrating a Workflow Process
Process of Migrating a Workflow Process

This process is a step in Roadmap for Developing a Workflow Process on page 97. To migrate a workflow process, perform the following tasks:
1 2
Developing a Migration Strategy on page 218 Migrating a Workflow Process on page 223
After you test and publish a workflow process in the development environment, you can migrate it to the production environment. NOTE: Before you migrate data, be sure the data that is required for the workflow process is also present in the target environment. For example, if your workflow requires custom entries in the List of values (LOV) table, then make sure these entries are present and active.
Developing a Migration Strategy

This task is a step in Process of Migrating a Workflow Process on page 218. After you deploy the workflow process, it is ready to be migrated. Migrating is the act of moving a workflow process from a development environment to a production environment. Migration also describes the act of moving a workflow process from a lower version repository to a higher version repository. One of three utilities can be used: ADM, REPIMEXP, and Import/Export.
To develop a migration strategy 1

Peruse the available migration options in order to determine which option is most appropriate for your implementation. For more information, see Comparison of Migration Options on page 219.
Consider the requirement to redeploy your workflow process after it is migrated. If you migrate workflow processes using ADM, then the workflows are activated automatically. If you use REPIMEXP or the Siebel Workflow Import/Export option, then you must redeploy the workflows manually. For more information, see Redeployment of a Workflow Process After it Is Migrated on page 223.
Choose one of the migration options.
218
Comparison of Migration Options

Table 36 provides a comparison of options for migrating workflow processes.
Table 36.
Comparison of Options for Migrating a Workflow Process When to Use Environments in which to use ADM include: When you are migrating customization data for your entire enterprise, including workflow process data. You must migrate more than 10 workflow processes at one time.
Migration Option ADM
For more information, see Migration with Application Deployment Manager on page 219. REPIMEXP Environments in which to use REPIMEXP include: When you are rolling out your release and most or every repository object must be migrated. REPIMEXP is the manual process for repository migration. If it is not necessary to use ADM, or you cannot use ADM, then use REPIMEXP. If you choose not to connect Siebel Tools to your production repository, then you must use REPIMEXP.
For more information, see Migration with REPIMEXP on page 220. Workflow Admin Service Business Service Environments in which to use the Workflow Admin Service business service include: When you can perform bulk or batch migration of workflow processes. As an alternative to using the Workflow Admin Service business service, you can perform client-side batch activation and expiration by way of the File menu in the application.
For more information, see Migration with the Workflow Admin Service Business Service on page 220. Import/Export Environments in which to use Import/Export include: When you can migrate workflow processes in increments of approximately 10 or less
For more information, see Migration with Import/Export on page 220.
Migration with Application Deployment Manager

Application Deployment Manager (ADM) is a deployment framework that automates the process of migrating enterprise customization data from one Siebel application environment to another, including from a development environment to a production environment. This customization data can include views, responsibilities, assignment rules, workflow processes, workflow policies, and so forth.
21 9
ADM is designed to provide a single deployment tool that covers various areas within the Siebel application. The objective is to reduce the potential manual setup and deployment work and to provide as much automation as possible in order to decrease the error rate. A deployment package for workflow processes in ADM includes the SRF, the workflow processes, their subprocesses, and their run-time settings, such as activation and expiration times, monitoring levels, and so forth. For information, see Siebel Application Deployment Manager Guide.
Migration with REPIMEXP

The REPIMEXP utility allows you to export and import repository objects. Because this utility migrates repository objects, including your workflow processes, it is most useful when your organization is ready to roll out an entire release. The Repository Import/Export utility is found in the siebel/bin directory. Use REPIMEXP for bulk migration of repository objects, including workflow processes. In the command line interface, type repimexp/help to view your usage options. When using REPIMEXP, you cannot pick and choose which workflow processes to migrate. To choose a single workflow or only certain workflows for migration, use the Import/Export migration option.
Migration with the Workflow Admin Service Business Service

The Workflow Admin Service business service allows you to import, export, deploy, and activate multiple workflow processes in bulk. Workflows are identified through a search specification. For more information see, Import and Export when Using Certain Features of Siebel Tools on page 222 and Workflow Admin Service Business Service on page 489.
Migration with Import/Export

You can use Import/Export for incremental migration of workflow processes. You use Siebel Tools to export workflows from one environment and to import workflows to another environment. The Import/Export feature for Siebel Workflow is designed only to migrate an individual workflow or a small set of workflows. For example, Siebel Workflow Import/Export cannot migrate 150 workflows at one time. To migrate large numbers of workflows with Import/Export, break them into sets of 10 workflows or less. For more information, see Importing and Exporting a Workflow Process on page 224.
Migration with Siebel Tools When using Siebel Tools, you import the workflow process into the repository of the target environment, then you click Publish to mark the workflow for migration. After this, the workflows are ready to be activated. This technique makes sure the versions of the workflows that exist in the repository tables and the run-time tables are the same.
220
Figure 19 illustrates an incremental migration using the Import/Export utility and Siebel Tools.
Figure 19. Incremental Migration Using Import/Export From within Siebel Tools Steps you perform when you use Siebel Tools to import a workflow process include:
1 2 3
Export the workflow process to XML by using the Import/Export Utility. Import the workflow process into the repository of the target environment. Activate the workflow process.
Migration with Siebel Tools In Conjunction with the Siebel Client You can import a workflow process directly into the run-time tables. This technique bypasses the requirement for you to write the workflows into the repository tables of the target environment and activation from the Siebel client, although these steps are still performed in the background by the Workflow Engine. This technique causes the latest version of the workflow process in the run-time tables, used by the Workflow Engine, to be different from the version that resides in the repository tables. NOTE: Importing directly to the run-time tables is an effective technique for testing a workflow process in a different environment. However, it is recommended that this technique not be used for general migration of workflows across environments.
22 1
Figure 20 illustrates an incremental migration using Import/Export to export from within Siebel Tools and import from within the Siebel client.
Figure 20. Incremental Migration Using Import/Export from within Siebel Tools and Import from within the Siebel Client Steps you perform when you use the Siebel Client to migrate a workflow process include:
1 2
Export the workflow process to XML by using the Export Utility. Import the workflow process into the repository of the target environment.
Import and Export when Using Certain Features of Siebel Tools Siebel Tools features that are not applicable to Siebel Workflow objects include: SIF export and import. Object Compare. Three way merge during upgrades. For more information, see Siebel Application Services Interface Reference.
Because Siebel Tools excludes Siebel Workflow objects from these features, it is important to use the Siebel Workflow import and export feature in order to back up and restore a workflow process. For example, if you archive a project in Siebel Tools, then the Siebel Workflow objects within that project are not archived. CAUTION: If you delete the objects from a project expecting that they can be restored from the SIF, then it is important to keep in mind that Siebel Workflow objects are an exception, and cannot be restored from the SIF. Use the Siebel Workflow import and export feature to back up and restore workflow processes.
Import and Export with a Subprocess If you import a workflow process that contains a sub process step, then you must import the subprocess, and then the parent workflow process. Import the parent only after the subprocess is successfully imported. This rule also applies for importing workflow processes in batch.
222
It is not necessary to export the subprocess first when exporting a workflow process. Name length must also be considered for a subprocess when importing a workflow process. A subprocess can contain a name that is to 100 characters in length. The name of a subprocess that exceeds this limit can generate an error during import.
Import and Export with Carriage Returns If a workflow process calls the SendMessage method of the Outbound Communications Manager business service to send email, and if carriage returns exist in the message body, then the workflow process can be exported. However, if the workflow is imported back into the database, then the imported workflow does not contain the carriage returns. Instead, the carriage returns appear as square characters, and the message body is treated as a single paragraph. To remedy this situation, you must edit the message body, replacing the square characters with carriage returns. A carriage return is entered by pressing the enter key.
Redeployment of a Workflow Process After it Is Migrated

When planning a migration strategy, it is important to consider potential redeployment work that must be performed after the workflow process is migrated. After migrating your workflow to a production environment, it might be necessary for you to redeploy the workflow before you can run it. Table 37 describes how redeployment requirements depend on the technique that is used to migrate the workflow process.
Table 37.
Comparison of Migrating with ADM to REPIMEXP or Import/Export Redeployment with REPIMEXP or Import/ Export You must manually redeploy workflow processes in the target environment.
Redeployment with ADM It is not necessary for you to manually redeploy workflow processes in the target environment.
Migrating a Workflow Process

This task is a step in Process of Migrating a Workflow Process on page 218. Use the tool that you identified in the migration strategy to perform the migration. This topic describes procedural information for using the Import/Export strategy or the business service strategy. For procedures for ADM, see Siebel Application Deployment Manager Guide. For procedures for REPIMEXP, see Going Live with Siebel Business Applications. If you are migrating a large number of workflow processes, then you can define a small group of workflows to migrate as a first phase of implementation. After you successfully migrate the first group, you can add more workflows in a systematic manner. For more information, see Migrating Workflow Policies to the Production Environment on page 443.
22 3
Importing and Exporting a Workflow Process

You can use the Import/Export feature both as a migration tool and as a way to back up an individual workflow process. Use a meaningful naming convention when choosing a filename for an exported workflow process in order to make it easy to understand the purpose of the process. Some prerequisites must be met when you use the import or export strategy. For more information, see Migration with Import/Export on page 220.
Importing a Workflow Process You can import a workflow process.
To import a workflow process 1 2 3 4

In Siebel Tools, navigate to the Workflow Processes OBLE. Right-click, then choose Import Workflow Process. The Open dialog box displays. Choose a path and filename of the workflow process to import, then click Open. Choose the project to which you must add the workflow process. The workflow process is imported with a status of In Progress. If a workflow process of the same name exists in the target environment, then the version number for the newly imported workflow is incremented by one.
Exporting a Workflow Process You can export a workflow process.
To export a workflow process 1

Locate the workflow process you must modify. For more information, see Locating a Workflow Process in the Workflow Processes Object List Editor on page 43. To choose more than one workflow process, press and hold the CTRL key while choosing the workflows.
Right-click, then choose Export Workflow Process. The Save As dialog box displays.
Enter the file path, filename, the .xml filename extension, then click Save. The workflow process is exported. If you chose more than one workflow to export, then the workflows you chose are saved to one XML file.
If you export a workflow process that contains a sub process step, then you must also export the sub process. A sub process is not automatically exported.
224
Migrating with the Workflow Admin Service Business Service

This topic gives one example of migrating with the Workflow Admin Service business service. You might use this feature differently, depending on your business model. For more information, see Workflow Admin Service Business Service on page 489.
To migrate with the Workflow Admin Service business service 1 2

In the Siebel client, navigate to the Administration-Business Service screen, then the Simulator view. In the Simulator list, click New, then define fields according to values described in the following table. Field Service Name Method Name Value Workflow Admin Service Activate
In the Input Arguments list, click New, then define fields according to values described in the following table. Field Test Case # Property Name Property Value Value 1 FlowSearchSpec [Process Name] like '*Pricing Procedure*' and [Status] = 'Completed'
Change the Process Name value that you enter for Property Value in order to meet the specific requirements of your implementation.
In the Simulator list, click Run. Upon completion, the simulator displays the results of the simulation in the Output Arguments list. In this example, the Property Value field in the Output Arguments list displays the number of workflow processes whose name begins with Pricing Procedure and whose status is completed. You can modify the Property Value in order to meet your specific business requirements.
To examine simulation output:
Navigate to the Administration-Business Process screen, then the Workflow Deployment view.
22 5
Issue a compound query using values from the following table. Value *Pricing Procedure* Active
Field Name Deployment Status
The query returns a list of workflow processes that are also represented in the Output Arguments list of the business service simulator. The total number of records returned in the query must match the number of records that are displayed in the Property Value field described in Step 4.
226
Administering a Workflow Process Process of Administering a Workflow Process
Process of Administering a Workflow Process

This process is a step in Roadmap for Developing a Workflow Process on page 97. You might use this process differently, depending on your business requirements. To administer the instances of a workflow process, perform the following tasks:
1 2 3 4 5 6
Viewing Run-Time Instances of a Workflow Process on page 227 Using the Workflow Instance Admin View on page 228 Monitoring a Workflow Process on page 233 Stopping an Instance of a Workflow Process on page 229 Deactivating the Instance of a Workflow Process on page 230 Removing a Workflow Process From the Run-Time Environment on page 231
Over the lifetime of a workflow process, you can perform the general sequence of steps described in this topic.
Viewing Run-Time Instances of a Workflow Process

The Workflow Deployment view allows you to view, deploy, and activate a workflow process. This view displays the parent and child relationship that exists between the workflow process and the runtime records for the workflow process.
To view run-time instances of a workflow process 1 2 3 4 5

Log in to the Siebel client. Navigate to the Administration-Business Process screen, then the Workflow Deployment view. In the Repository Workflow Processes list, query the Name field for the workflow process you must administer. Drill down on the Name field. Examine configuration for the workflow process, using values from the following table. List Name Active Workflow Processes Child Items Description Lists workflow processes that are deployed. Filters records to display only child items of the workflow process chosen in the parent list.
22 7
Where Information About the Instance of a Workflow Process Is Stored

Tables that include information about instances of a workflow process include: S_WFA_INSTANCE S_WFA_INST_PROP S_WFA_INST_WAIT
Tables that include information about instance monitoring of a workflow process include: S_WFA_INST_LOG S_WFA_INSTP_LOG S_WFA_STPRP_LOG
Viewing Pre 7.7 Workflow Processes

The Workflow Processes view allows you to view workflow processes that are defined earlier than Siebel CRM version 7.7. The Workflow Processes view and the child views for the workflow are read only views that are used specifically for viewing workflow processes defined earlier than version 7.7.
To view pre 7.7 workflow processes 1 2 3 4

Log in to the Siebel client. Navigate to the Administration-Business Process screen, then the Workflow Processes view. In the Workflow Processes list, query the Name field for the workflow process you must administer. Examine configuration for the workflow, using values from the following table. View Tab Process Definition Process Designer Process Properties Description Displays the definition of a workflow process that is defined earlier than version 7.7. Displays the flow diagram of a workflow process that is defined earlier than version 7.7. Displays properties of a workflow process that is defined earlier than version 7.7.
Using the Workflow Instance Admin View

The Workflow Instance Admin view displays workflow processes that have persistence set and that are in a run state, wait state, or error state. This view allows you to view, monitor and control a workflow process. For a chosen instance, you can change the value of the process properties before resuming the instance.
228
If a workflow process contains a wait step, or if the Auto Persist flag for a workflow is checked, then persistence for a 7.0 workflow process is set.
To use the workflow instance admin view 1 2 3 4

Log in to the Siebel client. Navigate to the Administration-Business Process screen, then the Workflow Instance Admin view. In the All Workflow Process Instances list, query the Process Name field for the workflow process you must administer. Administer the instances for the workflow process, using values from the following table. List Name All Workflow Process Instances Related Instances Process Properties Description Lists instances of a workflow process that are running, in an error state, or in a waiting state. Displays instances of the workflow process that are chosen in the All Workflow Process Instances list. Displays process properties of the instance of the workflow process that is chosen in the Related Instances list. You can change the value of these process properties before you resume an instance that is waiting or that is in an error state.
For more information, see Stopping an Instance of a Workflow Process on page 229 and Manually Recovering the Instance of a Workflow Process on page 251.
Stopping an Instance of a Workflow Process

If persistence is defined for a workflow process, then you can stop an instance of the workflow. After the instance of a workflow is stopped, it is removed. An instance that contains a status of Running, Waiting, or Error can be stopped. If you stop an instance that is running, then the execution of the instance is terminated, which is different from purging an instance. For more information, see Purging a Workflow Process from the Log File on page 231. CAUTION: A stopped instance of a workflow process cannot be resumed.
To stop an instance of a workflow process 1

In the All Workflow Process Instances list of the Workflow Instance Admin view, query the Process Name field for the workflow process you must stop. For more information, see Using the Workflow Instance Admin View on page 228.
2 3
In the Related Instances list, choose the instance you must stop. In the applet menu, choose Stop Instance.
22 9
Stopping an Instance of a Workflow Process Through a Script

By using the _StopInstance method, you can use a script to stop an instance of a workflow process. An example usage of this technique occurs when an interactive workflow must be cancelled but which is suspended in a wait step. In this scenario, the Process Instance Id is already known.
To stop an instance of a workflow process through a script

Call the _StopInstance method on the Workflow Process Manager business service, as in the following example, which uses a Process Instance Id that is hard coded: var bs_WF var ps_inputs var ps_outputs = TheApplication().GetService("Workflow Process Manager"); = TheApplication().NewPropertySet(); = TheApplication().NewPropertySet();
ps_inputs.SetProperty("ProcessInstanceId", "1-IIT"); bs_WF.InvokeMethod("_StopInstance" , ps_inputs, ps_outputs);
Deactivating the Instance of a Workflow Process

You can deactivate a single instance of a workflow process, or multiple instances in a batch.
To deactivate an instance of a workflow process 1

In the Active Workflow Processes list of the Workflow Deployment view, choose the workflow process you must deactivate. For more information, see Viewing Run-Time Instances of a Workflow Process on page 227.
2 3
In the Active Workflow Processes list, choose the instance you must deactivate. From the applet menu, choose Deactivate Process. The status of the chosen instance is changed to Inactive.
Deactivating Instances of a Workflow Process in Batch

You can deactivate instances of a workflow process in batch.
To deactivate instances of a workflow process in batch 1

In the Active Workflow Processes list of the Workflow Deployment view, choose the instances you must deactivate. Use Multi-click, holding down the CTRL key while clicking each record in the list. TIP: Instead of using Multi-click, formulate a query to display only the workflow processes you must deactivate, then choose Select all from the applet menu. For more information, see Viewing Run-Time Instances of a Workflow Process on page 227.
230
From the applet menu, choose Deactivate Process. The status of the instances that are chosen in Step 1 are changed to Inactive.
Removing a Workflow Process From the Run-Time Environment

To remove a workflow process from the run-time environment, you can delete the workflow, then purge the instance of the workflow from the log.
Deleting a Workflow Process

You can delete a workflow process from within the Workflow Deployment view, which removes the definition of the workflow from the run-time environment. It also stops instances of the deleted workflow.
To delete a workflow process 1

In the Active Workflow Processes list of the Workflow Deployment view, choose the workflow process you must remove. For more information, see Viewing Run-Time Instances of a Workflow Process on page 227.
2 3
From the applet menu, choose Delete Process. If necessary, purge the workflow process from the log. For more information see Purging a Workflow Process from the Log File on page 231.
TIP: You can use Multi-select to choose multiple workflow processes. Because the Delete Process functionality deletes a workflow and stops the instances of that workflow, instances that are related to the chosen workflows are also stopped. Therefore, if you must perform a batch delete of multiple workflows, then perform the procedure beginning with Step 1 on page 231, using Multi-select to choose multiple workflows rather than just one workflow. To use Multi-select, keep the CTRL key depressed as you click each record in the list.
Purging a Workflow Process from the Log File

You can use the purge feature in order to delete a workflow process that contains a status of Stopped or Completed. If you must delete a paused instance, then stop the instance first. If you delete a running instance from the log, then the execution of the instance is unaffected and the instance continues to run.
23 1
To purge a workflow process from the log file 1 2 3 4 5

In the Siebel client, navigate to the Administration-Business Process screen, Workflow Instance Monitor, then the Process Instances view. In the Process Instances list, choose the workflow process you must purge. Click Purge. In the Workflow Instance Monitor Purge dialog box, choose a date. Click Purge.
232
Administering a Workflow Process Monitoring a Workflow Process
Monitoring a Workflow Process

This topic describes how to monitor and troubleshoot a workflow process in the production environment. It includes the following topics: Overview of Monitoring and Troubleshooting Tools on page 233 Setting Monitoring Levels for a Workflow Process on page 233 Setting Monitoring Levels for Tracing and the Event Log on page 236 Defining Metrics for a Workflow Process on page 237 Capturing Data with Siebel Application Response Measurement on page 238 Recording Behavior with the Siebel Flight Data Recorder on page 239
Overview of Monitoring and Troubleshooting Tools

Tools that can be used to monitor and troubleshoot a workflow process include: Progress and status information. Use the Workflow Instance Monitor view and the Workflow Instance Admin view to monitor the progress and status of each workflow process. For more information, see Setting Monitoring Levels for a Workflow Process on page 233. Operation details. Use event logging to trace operations that are performed by each step of a workflow process. For more information, see Setting Monitoring Levels for Tracing and the Event Log on page 236. Performance measurement data. Use SARM (Siebel Application Response Measurement) to capture timing data for measuring performance of a workflow process. For more information, see Capturing Data with Siebel Application Response Measurement on page 238. Failure analysis records. Use Siebel FDR (Flight Data Recorder) to automatically capture the events that might lead to a system failure. For more information, see Recording Behavior with the Siebel Flight Data Recorder on page 239
Setting Monitoring Levels for a Workflow Process

The Monitoring Level you set determines the frequency with which log writing occurs and, hence, the data that is available in the views for the instance of a workflow process. There are two views you can use to monitor a workflow. For more information, see Stopping an Instance of a Workflow Process on page 229 and Removing a Workflow Process From the Run-Time Environment on page 231.
Monitoring Instances of a Workflow Process

The Workflow Instance Monitor view allows you to monitor instances of a workflow process, as well as step instances and aggregate data.
23 3
To monitor instances of a workflow process 1 2 3 4

Log in to the Siebel client. Navigate to the Administration-Business Process screen, then the Workflow Instance Monitor view. In the Workflow Process list, query the Name field for the workflow process you must monitor. Monitor run-time data of the workflow process, using values from the following table. List Name or View Tab Workflow Process Description Displays definitions of workflow processes that have monitoring turned on. A workflow with a Monitoring Level that is not set to NONE is turned on. For more information, see Monitoring Level on page 234. Displays the related log instances for the chosen workflow process. Displays the steps and process properties for the chosen instance of a workflow process. Displays aggregate data as a chart view for the chosen workflow process.
Process Instances Step Instances Aggregate Data
For more information, see Purging a Workflow Process from the Log File on page 231, and Using Instance Monitoring to Diagnose a Workflow Process on page 240.
Monitoring Level When the Monitoring level is set for a workflow process that is deployed, the instance of the workflow remains in the Workflow Instance Monitor view after it finishes and is no longer visible in the Workflow Instance Admin view. Depending on the monitoring level that is set for the chosen workflow, there might be no records in the Step Instances and Aggregate Data views.
Setting the Monitoring Level Parameter

When an instance of a workflow process is created, the monitoring level is read from the workflow and remains throughout the lifetime of the instance unless the instance is paused. In the case of a paused instance, when the instance is resumed, the monitor level is reread from the workflow.
234
Table 38 describes parameters for monitoring levels and their corresponding frequencies for log writing that you can set for a workflow process.
Table 38.
Descriptions of Parameters for Monitoring Levels Record Process Instance No Yes Yes Yes Yes Record Step Instances None None All Steps All Steps All Steps Record Process Properties None None None All Steps All Steps
Monitoring Level 0 None 1 Status 2 Progress 3 Detail 4 Debug
To set the monitoring level parameter 1 2

In the Siebel client, navigate to the Administration-Business Process screen, then the Workflow Deployment view. In the Active Workflow Processes list, set the Monitoring Level field.
Guidelines for Setting the Monitoring Level

The monitoring level determines the frequency with which data is written to the disk. The frequency is optimized internally by the run-time environment for Siebel Workflow, based on the type of workflow process and the monitoring level you choose. Monitoring can incur a performance overhead. It is best to set the monitoring level to 0 (None) or 1 (Status) on a workflow process that is running in a production environment. NOTE: It is recommended that a monitoring level of 2 (Progress) and higher only be used for debugging a workflow process. If the monitoring level is Debug, then the log is written to the disk after every step.
Monitoring Level and Compatibility with the 7.0 Workflow Process

Settings for monitoring levels with a 7.0 workflow process include: If the persistence frequency is set to NONE, then the monitoring level is set to NONE. If the persistence frequency is ON_PAUSE or EVERY_STEP, then persistence is explicitly turned on and the monitoring level is set:

If the persistence level is ALL_STEPS, then the monitoring level is set to PROGRESS. If the persistence level is CURRENT_STATE, then the monitoring level is set to STATUS.
23 5
With the Siebel CRM 8.1 release, persistence and monitoring are separate features that serve different purposes. Persistence affects quality of service and is controlled during development. Monitoring is an administrative tool and is controlled during deployment. Monitoring typically does not affect the functionality of a workflow process.
Setting Monitoring Levels for Tracing and the Event Log

You can use tracing levels to troubleshoot a workflow process. Setting a trace level above the default level affects performance. Reset the trace level to the default value after troubleshooting is finished. Table 39 describes the events that a workflow process uses for logging.
Table 39. Event
Events for Logging of a Workflow Process Level 3 4 4 4 Description Traces object definitions for workflow processes and steps for workflows that are loaded into memory. Traces methods that are called and arguments that are passed to the Workflow Engine. Traces creation and completion for instances of workflow processes. Traces the process property get or set. Traces creation and completion of the step, evaluation of the decision condition for the branch , calling of the business service, and inserting or updating of the business component . Measures overall execution time for a workfow process. Measures execution time of the workflow process and of individual steps of a workflow. Traces recovery status and progress for an instance of a workflow process. Applicable only to the Workflow Recovery Manager server component. Traces recovery details for an instance of a workflow process. Applicable only to the Workflow Recovery Manager server component.
Workflow Definition Loading (DfnLoad) Workflow Engine Invoked (EngInv) Workflow Process Execution (PrcExec) Workflow Step Execution (StpExec) Workflow Performance (WfPerf ) Workflow Performance (WfPerf ) Workflow Recovery (WfRecv) Workflow Recovery (WfRecv)
4 5 3
Increasing Tracing Levels for Components of the Workflow Management Server

You can generate a more detailed trace file to assist in troubleshooting Workflow Process Manager, Workflow Process Batch Manager, and Workflow Recovery Manager. You should increase tracing levels prior to executing the server process.
236
To increase tracing levels for components of the workflow management server 1 2

In the Siebel client, navigate to the Administration-Server Configuration screen, Servers, Components, then the Events view. In the Components list, choose the component for which you must generate tracing. These components include the Workflow Process Manager, the Workflow Process Batch Manager, or the Workflow Recovery Manager.
Click the Events tab in order to view the configurable event types for the chosen component. The log level is set to a default value of 1.
4 5
Change the log level value to 3, 4, or 5. For more information, see Table 39 on page 236. (Optional) For more troubleshooting, you can repeat Step 4 to increase the tracing level for the Object Manager SQL log event.
More tracing information is generated as the Component Event Configuration Log Level value increases. For more information on the different Log Level values available for Component Event Configuration, see Siebel System Monitoring and Diagnostics Guide.
Defining Metrics for a Workflow Process

A workflow process metric allows you to collect data that is associated with a property of the workflow. To collect metrics, you define the subset of metrics to be captured, then activate the metric collection after you deploy the application.
To define metrics for a workflow process 1

Make sure the WF Process Metrics object type is exposed in the Object Explorer. For more information, see Exposing Object Types That Are Used to Develop a Workflow Process on page 116.
3 4 5 6 7
In the Object Explorer, expand the Workflow Process tree, then click WF Process Metric. Right-click in the WF Process Metrics OBLE, then choose New Record from the pop-up menu. In the Metric Name property, choose the desired metric from the list of predefined metric names. For the Property Name property, choose a process property from the list of those defined for the workflow process. Make sure the Inactive property does not contain a checkmark. The Inactive property provides a convenient means for you to turn off a metric and turn it on later.
23 7
Activate the workflow process. For more information, see Process of Deploying a Workflow Process on page 211.
In the Siebel client, navigate to the Administration-Business Process screen, then the Workflow Deployment view. in Step 8.
10 Query the Name field of the Active Workflow Processes list for the workflow process you activated 11 Set the Analytics Level field of the Active Workflow Processes to Property or All.
This step allows metrics to be collected at run time.
Capturing Data with Siebel Application Response Measurement

The Workflow Process Manager server component can use Siebel Application Response Measurement (SARM). SARM captures timing data that is useful for monitoring the performance of the Siebel application, and records this information to binary files. Table 40 describes SARM levels that are used with a workflow process.
Table 40.
SARM Levels That Are Used with a Workflow Process Description The Workflow Process Manager business service records the time that is required in order to execute the method of a business service. Examples of service methods in Workflow Process Manager are RunProcess and ResumeInstance.
SARM Level 1
The Workflow Process Manager business service records the time required to perform the following: Execute the method of a business service Execute a step in a workflow process Write monitoring data to the disk
SARM level 2 can help you determine the logging overhead when you increase the monitoring level of your workflow process.
238
Table 41 describes SARM areas and subareas that are used with a workflow process.
Table 41. Level 1 1 1 2 2
SARM Areas and Subareas That Are Used with a Workflow Process Area WORKFLOW WORKFLOW WORKFLOW WORKFLOW WORKFLOW Subarea CORDR_RESUME CORDR_EXECUTE ENGNE_INVOKE STEPS_EXSTEP MONTR_WRTE Description Resume a workflow process that is suspended. Execute a workflow process. Call a method of the Workflow Process Manager business service. Execute a step of a workflow process. Write monitoring data of a workflow process to disk.
For more information on configuring SARM and the SARM analyzer, see Siebel Performance Tuning Guide.
Recording Behavior with the Siebel Flight Data Recorder

Log files of the Siebel Flight Data Recorder (FDR) , identified with the .fdr extension, are records of system and server component behavior at run time. If a system or server component fails, then the settings and events that lead up to the failure are logged. The FDR log file can then be used to troubleshoot and analyze the specific settings and events that occurred prior to the failure. FDR log files are stored in the Binary subdirectory of the Siebel Server root directory. FDR instrumentation points are embedded in the Workflow Process Manager business service and the Workflow Recovery Manager business service in order to provide capture processing details in case of a system failure or server component failure. For information, see How to Get Help with an Error of a Workflow Process on page 242, and Siebel System Monitoring and Diagnostics Guide.
23 9
Administering a Workflow Process Diagnosing a Workflow Process That Has Failed
Diagnosing a Workflow Process That Has Failed

This topic includes following topics: Diagnosing a Workflow Process That Has Failed in a Production Environment on page 240 Troubleshooting Execution Problems with a Workflow Process on page 243 About the Workflow Recovery Manager on page 246
Diagnosing a Workflow Process That Has Failed in a Production Environment

This topic describes how to diagnose problems in the production environment. For more information about some of the tools described in this topic, see Monitoring a Workflow Process on page 233.
Using Tracing to Diagnose a Workflow Process

You can use tracing to diagnose a workflow process that has failed.
To use tracing to diagnose a workflow process 1

Turn on tracing for the appropriate component that is running the workflow process. Example components include the Workflow Process Manager, Workflow Process Batch Manager, or the application Object Manager.
View the event log files.
For details on how to turn on tracing, see Setting Monitoring Levels for Tracing and the Event Log on page 236.
Using Instance Monitoring to Diagnose a Workflow Process

You can use instance monitoring to diagnose a workflow process that has failed.
To use instance monitoring to diagnose a workflow process 1 2

In the Siebel client, navigate to the Administration-Business Process screen, then the Workflow Deployment view. In the Active Workflow Processes list, choose the workflow process you must monitor.
240
Set the monitoring level to 3-Detail or 4-Debug. At this level, the state and process properties values for each step in a workflow process are recorded, regardless of which component runs the step. NOTE: The 3-Detail and 4-Debug monitoring levels affect performance of the Workflow Engine. For this reason, use these levels for troubleshooting purposes only.
4 5
Navigate to the Administration-Business Process screen, Workflow Instance Monitor, then the Process Instances view. View the monitoring information and fix problems, as necessary.
Using the Business Service Simulator to Diagnose a Workflow Process

You can use the business service simulator to diagnose a workflow process that has failed.
To use the business service simulator to diagnose a workflow process 1

Run the workflow process from the Business Service Simulator using the Workflow Process Manager business service. This step executes the workflow process in the application object manager.
2 3
In the Siebel client, navigate to the Administration-Business Service screen, then the Simulator view. In the Simulator list, define a new record, then set the fields using values from the following table. Field Service Name Method Name Iterations Value Workflow Process Manager RunProcess 1
In the Input Arguments list, define a new record, and perform the following:
a b
Set the Test Case # field to 1. Choose and open the Property Name field. The Property Name field opens a multi-value applet.
In the multi-value applet, click New, then set the fields using values from the following table. Field Property Name Value Value ProcessName (Enter the name of the workflow process.)
Click Save.
24 1
7 8 9
Repeat Step 5 and Step 6 for other parameters that are passed to the workflow process, especially RowId, if necessary. In the multi-value applet, click OK. In the Simulator list of the Simulator view, click Run.
TIP: To increase the data that is available to you for troubleshooting, set the monitoring level to 4Debug, as described in Step 3 on page 241, launch the workflow process with the Business Service Simulator, then view execution information of the workflow process in the Workflow Instance Monitor views. For more information, see Business Service Simulator on page 201, and Removing a Workflow Process From the Run-Time Environment on page 231.
Avoiding Excessive Records in the S_WF_PROP_VAL Table

The S_WF_PROP_VAL table stores values of process property for a workflow process. When a workflow process is executed, records are created in the S_WF_PROP_VAL table along with a new S_WF_STEP_INST record. There is the potential for the S_WF_PROP_VAL table to become very large over time, because a workflow process typically contains five or more process properties. Therefore, five records can be added to the S_WF_PROP_VAL table for each instance of a workflow process. Having Persistence defined on a large number of workflow processes can cause an increase in the size of the S_WF_PROP_VAL table. To avoid this situation, disable persistence on your workflows unless it is absolutely necessary.
To avoid excessive records in the S_WF_PROP_VAL table

Disable persistence by setting the Auto Persist property to NO on the workflow process. For more information, see About Events on page 157.
How to Get Help with an Error of a Workflow Process

To get help with an error of a workflow process, create a service request on OracleMetaLink 3. Alternatively, you can phone Global Customer Support directly in order to create a service request or get a status update on your current SR. Support phone numbers are listed on OracleMetaLink 3.
242
You can use the following ways to communicate errors of a workflow process: Send the log files. Log files are generated by turning on tracing, as described in Step 1 on page 240. Communicate the error code and error message. Except for a service workflow process, if a workflow process encounters an error, then the state of the workflow is persistent with a status of In-Error. If a workflow encounters an error in a subprocess, then the state of the subprocess is also persistent. Both the error code and the error message are saved in a process property. You can examine the error code and error message in the Process Properties list of the Workflow Process Instance Admin view. If a record is chosen from the All Workflow Process Instances list, then the related instance list displays the parent and child workflows. You can communicate the error code and the error message for further assistance.
Troubleshooting Execution Problems with a Workflow Process

This topic describes guidelines for resolving execution problems of a workflow process. Table 42 lists Symptoms and error messages you can review in order to resolve problems with the execution of a workflow process.
Table 42.
Troubleshooting Execution Problems of a Workflow Process Diagnostic Steps and Cause Not applicable Solution Make sure Reload Runtime Events is executed. To determine if a workflow process is started, turn on workflow logging for EngInv, StpExec, and PrcExec. For more information, see Increasing Tracing Levels for Components of the Workflow Management Server on page 236. For a workflow process that is running in the Workflow Process Manager server component, reset the parameter Workflow Version Checking Interval. By default the interval is 60 minutes.
Symptom After activating a workflow process, it does not execute when the corresponding run-time event is called.
After revising a workflow process and reactivating it, the revised workflow information is not read.
Not applicable
24 3
Table 42.
Troubleshooting Execution Problems of a Workflow Process Diagnostic Steps and Cause If the DisplayApplet run-time event is a UI event, and if the default Web UI framework design uses a cache, then the event only fires the first time a non cached view is accessed. The workflow process is started only when the event fires and works correctly. The run-time event is passed to the row ID of the primary business component and not to the row ID of the business component on which the runtime event acts. Solution To make the field still work in this situation, you can explicitly set EnableViewCache to FALSE in the .cfg file.
Symptom When a workflow process is started by the DisplayApplet run-time event, the workflow is started the first time but not subsequently.
After a workflow process is started from a run-time event, the row ID of the record on which the event occurred is not retrieved.
Retrieve the row ID of the active business component by using a search specification. For example: the Active_row-id process property is equal to [Id], defined as Type equals Expression and the business component equals the business component name. Ignore the error message and proceed. Step 1 through Step 3 must occur, in that order, and in the same user session in order for the error message to be reported. As a result, the error message disappears when the application is restarted. The Purge feature only works on instances that have stopped and finished. To delete persistent or incomplete instances, you first must manually stop the instances.
The following error message displays: Cannot resume Process [x-xxxxx] for Object-id [x-xxxxx]. Please verify that the process exists and has a waiting status.
Deleting existing instances of the workflow process does not help. This error typically occurs in the following scenario:
An instance of a workflow process is started and paused, waiting for a runtime event. The run-time event fires. The instance is resumed and run to completion. The run-time event fires for a second time. The Workflow Engine tries to resume the instance but fails because the instance is no longer in a Waiting state.
Unable to access a different business object from a workflow process.
The architecture for Siebel Workflow restricts the use of one business object to a workflow process.
Use a sub process step to access a different business object.
244
Table 42.
Troubleshooting Execution Problems of a Workflow Process Diagnostic Steps and Cause Not applicable Solution Make sure the following situations are true: The workflow process exists. The status for the workflow process is set to Active. The workflow process is not expired.
Symptom The following error message displays: Unable to initiate the process definition [process name].
One of the following error messages displays: OMS-00107: (: 0) error code = 4300107, system error = 27869, msg1 = Could not find 'Class' named 'Test Order Part A' OMS-00107: (: 0) error code = 4300107, system error = 28078, msg1 = Unable to create the Business Service 'Test Order Part A'
Not applicable
Make sure at least one SRF is copied to the Siebel Server \objects\[lang] directory.
The following error message displays: The selected record has been modified by another user since it was retrieved.
A workflow process attempted to update a record that was updated by another user or task since the record was initially retrieved by the workflow.
Define an error exception connector to handle the update conflict. For more information, see Defining an Error Exception Connector to Handle an Update Conflict on page 166.
24 5
About the Workflow Recovery Manager

This topic describes Workflow Recovery Manager. It includes the following topics: Overview of the Workflow Recovery Manager on page 246 Administering the Workflow Recovery Manager on page 248 Recommended Techniques to Recover a Workflow Process on page 250 Recovering a Workflow Process on page 250
Overview of the Workflow Recovery Manager

Functionality provided by Workflow Recovery Manager includes: Recovers interrupted instances of a long-running workflow process upon failure of the Siebel Server. As the instance is recovered, the Workflow Engine attempts to continue forward execution. If forward progress is not possible, then the workflow is marked as IN_ERROR and manual intervention is required in order to resume the workflow. A instance of a workflow process is resumed at the last checkpoint in order to maintain the integrity of the execution. The checkpoint is automatically determined by the Workflow Engine based on hints that are provided by the developer during development. The Workflow Engine automatically persists relevant execution data in order to resume execution upon failure of a workflow process. Recovery of instances of a workflow process is load balanced. One server thread can determine the recovered instances. This server thread delegates the actual resumption of the recovered instance to other server threads in a load balanced manner. Recovery of a workflow process can be started without interfering normal execution of the Workflow Engine. One server thread can start the recovery of workflow instances, while other threads in the Workflow Engine still handle new requests in order to execute workflows. Thus, the Workflow Engine is blocked by the recovery thread.
246
Architecture of the Workflow Recovery Manager Figure 21 illustrates the architecture that is used for recovering a workflow process.
Figure 21. Architecture of the Workflow Recovery Manager Components in the architecture of the Workflow Recovery Manager include:
Workflow Engine. A batch component, Workflow Process Manager, that is responsible for executing a long-running workflow process. As the workflow is executed, the Workflow Engine persists the execution state into the database at the appropriate time. Workflow Recovery Manager. A batch component that is responsible for identifying a workflow process that is interrupted due to a server failure. If Workflow Recovery Manager discovers an interrupted instance of a workflow, then the recovery manager forwards the instance to the Workflow Engine in order to resume execution. The recovery manager itself does not execute the instance of the workflow. Database. A database that is used to store the execution state of the workflow processes. The persistent record is used to restore execution state when the workflow resumes execution from a failure. Server Message Queue. A queue through which the Workflow Engine and the recovery managers multi-cast messages.
24 7
5 6
Business Process Administration View. Allows you to manually request the Workflow Recovery Manager to recover a workflow process that is interrupted. Server Administration Task Management. Allows you to define a recurrence server task for the Workflow Recovery Manager. The recurrence server task requests the server manager to periodically scan for workflow processes that are interrupted.
Administering the Workflow Recovery Manager

The status of the Workflow Recovery Manager component is Online after it is started, functioning similar to other components. However, no server tasks are visible unless a recovered instance of a workflow process is recovered after a server failure. If you run list tasks for comp WfRecvMgr and no executed server tasks are returned, then it indicates there are no failed instances, which is expected behavior. Workflow Recovery Manager that is in an Active status indicates that the Workflow Recovery Manager component is up and running.
To administer the Workflow Recovery Manager 1

In the Server Manager command-line interface, issue the enable compgrp workflow command. This step makes sure that the component group for Siebel Workflow is activated on the server. For more information about Server Manager usage, see Siebel System Administration Guide.
2 3 4
In the Siebel client, navigate to the Administration-Server Management screen, then the Components view. Query for Workflow Recovery Manager. If Workflow Recovery Manager is not Online, then click Start Up. This step starts the Workflow Recovery manager. It is not necessary to set other parameters.
Testing the Workflow Recovery Manager In this topic, you prepare to test, then test the Workflow Recovery Manager.
To prepare to test the workflow recovery manager 1

Connect to the Server Manager from the Siebel Server. You must see the smgr> prompt. For more information about Server Manager usage, see Siebel System Administration Guide.
Issue the following command and check whether the Component Group named Workflow is activated: Smgr>list compgrp
248
If the Workflow component group is not activated, then perform the following steps:
Enter the following command to activate it: Smgr> enable compgrp workflow
b 4 5
Stop, then restart the server.
In the Siebel client, navigate to the Administration-Workflow Process screen, then the Workflow Deployment view. If the server is reset, then make sure there is a workflow process that is running that then fails. In order for the Workflow Recovery Manager to attempt recovery, there must be an instance of an active, running workflow process that fails if it is interrupted. Peruse the Active Workflow Processes list to make sure such a workflow is present.
Next, test the Workflow Recovery Manager.
To test the workflow recovery manager 1

Open a Telnet session connected to the Siebel Server, issue the command siebps, then make a note of the Process Id of the Siebel Server. If you are using Windows, then use Windows Task Manager instead of Telnet.
2 3
Open a second Telnet session, then connect to the Server Manager prompt. From the smgr> prompt, issue the following command to start the execution of the workflow: Start task for comp wfprocmgr with processname = 'AutoRec_NN' A new server task for the wfprocmgr component with the server task id is started.
From the first telnet session you opened, check whether the Inloop.txt file is generated. Numeric values are added to the file over time.
Issue the following command to reset the Siebel Server: Reset_server -e <enterprise> -M <server name> This step causes the workflow process that you are monitoring to fail.
6 7
Restart the Siebel Server, then enter the siebps command as you did in Step 1. The Siebel Server process is started again. Connect back to the smgr> prompt, then issue the following command in order to resume execution of the workflow process from the point of failure: smgr>start task for comp wfrecvmgr A new server task for the Workflow Recovery Manager component is started with a new server task id.
24 9
From the Telnet session, enter the following command to check the contents of the file: tail -f inloop.txt Numeric values are added to the file until 2999 is reached.
Issue the following command to check the last value entered in the file: outfile.txt The last and only value in this file must be 3000.
10 Issue the following command:

list tasks for comp WfRecvMgr Observe that there are now one or more server tasks in the list. These are server tasks that Workflow Recovery Manager performs in order to recover workflow processes that were interrupted when you reset the server in Step 5.
Recommended Techniques to Recover a Workflow Process

It is recommended that you perform the following techniques to recover a workflow process: Modify the Allow Retry Flag property on the Siebel operation step and business service step in order to reduce the number of checkpoints, and thereby minimize run-time overhead. If the Recovery Manager cannot determine from which step the instance of a workflow process must recover, then the instance is marked for manual recovery. Recovery is performed by the Recovery Manager based on state information for the instance that is saved by the Workflow Engine. The state information is saved at recovery checkpoints. To optimize performance, the recovery checkpoints are determined by the Workflow Engine based on the nature of the step and the Allow Retry flag property on the step. Break down a complex business service into a number of simpler business services, thereby making it easier to individually recover each smaller business service. Use multiple recovery managers. Having multiple recovery managers provides a way to safeguard against system problems that are transient or permanent. For example, a situation can exist in an environment where the subnet in which the recovery manager resides is frequently down. However, it is typical for only one recovery manager to be present as long as the recovery manager itself can be automatically restarted upon server failure.
Recovering a Workflow Process

If the Workflow Process Manager server component fails, then the workflow process automatically resumes the interrupted instances for the workflow when the server restarts. Recovery is performed by the Recovery Manager based on state information for the instance that is saved by the Workflow engine. You can recover an interrupted workflow either automatically or manually.
Automatically Recovering the Instance of a Workflow Process If the Workflow Process Manager server component fails due to an event that occurs outside of the Workflow Process Manager server component, such as a server failure, then Siebel Workflow automatically resumes the interrupted instances of a workflow process when the server restarts.
250
For an instance that cannot be automatically recovered, you can manually recover the workflow process. For example, if the server fails in the middle of a Siebel operation to update a record, then the workflow is unable to determine if the Siebel operation finished. It might be necessary for you to manually make sure the update was finished before resuming execution of the workflow. In another case, if the Siebel operation queries a set of records, then even after the server fails, the workflow can be resumed automatically by requerying. Automatic recovery of a workflow process applies to a workflow that runs in the server component. A workflow that runs on a local database cannot be recovered.
Manually Recovering the Instance of a Workflow Process You can correct and resume the instance of a workflow process that encountered errors. For example, if the Communications Server is not available, then a workflow process that sends a notice through email includes a status of In Error. You can activate the Communication Server component, then resume the workflow.
To manually recover the instance of a workflow process 1

In the Siebel client, navigate to the Administration-Business Process screen, then the Workflow Instance Admin view. Instances that are marked for manual recovery are recoverable from the Workflow Instance Admin view. For more information, see Using the Workflow Instance Admin View on page 228.
In the Related Instances list, choose an option from the applet menu, using values described in the following table. Menu Item Resume Instance-Next Step Description The instance skips the current step of the workflow process, and evaluates the decision conditions that emanate from the current step in order to determine the next step to execute. The instance resumes from the current step of the workflow process. The current step is retried. If the current step is a sub process step, then a new instance of the subprocess is started.
Resume Instance-Current Step
If the Resume Instance menu items are not available, then see Affect of Call Depth on the Resume Instance Menu Items on page 252.
25 1
Affect of Call Depth on the Resume Instance Menu Items An instance of a workflow process can resume only if the Call Depth setting for the workflow is the highest among the related instances of the workflow. If the instance is part of a set of related instances, and if one or more of those other instances includes a higher Call Depth level, then Resume Instance-Next Step and Resume Instance-Current Step are disabled. For example, assume there are multiple related instances with Call Depth settings of level 0,1,2,3, and 4. Assume you choose the record with level 3. In this case, these Resume controls are disabled because level 3 is not the highest Call Depth level that is set among the related instances.
252
Administering a Workflow Process About Upgrading a Workflow Process
About Upgrading a Workflow Process

This topic describes upgrading Siebel Workflow from earlier versions. Siebel Database Upgrade Guide is the primary source for upgrade information. For important upgrade information that pertains to workflow, such as Workflow Premerge, Repository Merge, Workflow Postmerge, and Logging, see Siebel Database Upgrade Guide.
Upgrades for the Runtime and Repository Schema

If there are repository and run-time schema changes for the Siebel Workflow tables, or if new columns were added to the repository and run-time schema, then you must add the new columns to the Siebel database. Perform the instructions provided in Siebel Database Upgrade Guide. An existing workflow process in the run-time deployment table is not changed during the upgrade. After the merge is finished, use the Workflow Deployment view in the Siebel client to reactivate finished workflows in order to load the new workflows into the run-time environment. For instructions on reactivating a workflow process, see Siebel Database Upgrade Guide.
Merge for Workflow Processes

If you upgraded to Siebel CRM version 7.7, then workflow processes were moved from the run-time tables into the repository tables. If you are upgrading to version 8.0 from version 7.7 or version 7.8, then a modified seed workflow or a custom workflow is merged into the version 8.0 repository during the repository merge process. However, if you are upgrading to Siebel CRM version 8.0 directly from a version prior to version 7.7, then your custom workflows and modified seed workflows are copied over to the version 8.0 repository as is. You must manually merge your customizations with the new version 8.0 seed workflows. In either case, make sure you review your workflow customizations after the repository merge process is completed. For more information, see Examining Seed Workflow Processes on page 111. For information about detailed merge algorithms, see Siebel Database Upgrade Guide.
Mode Requirements for an Upgraded Workflow Process

If you modify a 7.0 workflow process that was upgraded to version 7.7 or later, then the mode for the workflow can remain the same.
25 3
Administering a Workflow Process About Upgrading a Workflow Process
254
12 Examples of Defining a Workflow Process

This chapter describes examples on which you can model development efforts for your workflow process. It includes the following topics: Example of Defining a Workflow Process That Creates an Activity for a Sales Representative on page 255 Example of Defining a Workflow Process That Traverses a Record Set to Close Service Requests That Are Obsolete on page 264 Example of Defining a Workflow Process That Attaches an Activity Plan to an Opportunity on page 281 Example of Defining a Workflow Process That Manages Research Activities for a Service Request on page 288 Example of Defining a Workflow Process That Manages Creation of a Service Request on page 292 Example of Defining a Workflow Process That Manages Creation of a Service Request then Navigates the User on page 301
Example of Defining a Workflow Process That Creates an Activity for a Sales Representative
This topic gives one example of using a workflow process to create an activity for a sales representative. You might use this feature differently, depending on your business model. To develop this example, perform the following tasks:
1 2 3
Defining the Workflow Process on page 256 Testing the Workflow Process on page 262 Deploying and Verifying the Workflow Process on page 263
In this workflow process, if a user creates a new opportunity, then the revenue for the opportunity is evaluated. If the value of the opportunity is over $10,000, then an activity is generated that directs the sales representative to pursue the deal. The workflow is started by the WriteRecord run-time event.
25 5
Examples of Defining a Workflow Process Example of Defining a Workflow Process That Creates an Activity for a Sales Representative
Defining the Workflow Process

Perform the procedures in this topic to define the workflow process for this example. Make sure you perform the procedures in the order in which they are presented.
Defining the New Workflow Process

You begin by defining the new workflow process.
To define the new workflow process 1 2 3

In the Object Explorer in Siebel Tools, click Project. In the Projects OBLE, define a new project named Workflow Examples. Make sure the Locked property contains a checkmark. For brevity, example workflow processes in this book use the Workflow Examples project. In a development environment, you can use a project that more closely meets your development requirements. For more information, see Using Siebel Tools.
In the Object Explorer, click Workflow Process. For more information, see About the Object Hierarchy of a Workflow Process on page 39.
In the Workflow Processes OBLE, right-click, then choose New Record to define a new workflow process using values from the following table. Property Process Name Workflow Mode Business Object Project Value Large Opportunity Creates Activity Service Flow Opportunity Workflow Examples
For more information, see Properties of a Workflow Process on page 445.
From the application-level menu, choose the File menu, then the Save menu item.
Adding Steps and Connectors to the Workflow Process

This topic describes how to add steps and connectors to the workflow process.
256
To add steps and connectors to the workflow process 1 2

In the Workflow Processes OBLE, right-click the workflow you defined in Defining the New Workflow Process on page 256, then choose Edit Workflow Process. Add steps and connectors until your workflow process resembles the workflow illustrated in the following figure:
.
Click the decision point, then use the Properties window to change the Name property to the value described in the following table. Property Name Value Is Opportunity Over 10k?
The Properties window is context sensitive. If you click a step or connector in the Process Designer, then the properties for the step or connector are displayed in the Properties window. If the Properties window is not visible, then right-click a step, and choose View Properties Window.
Clicking each remaining step in succession, use the Properties window to change the Name property for each step according to values described in the following table. Step Type Siebel Operation End Name Property Insert Activity to Follow Up End
25 7
Clicking each connector in succession, use the Properties window to change the Name property for the connector according to values described in the following table. Connector Between the start step and the decision point Between the decision point and the Siebel operation Between the decision point and the end step Name Property Evaluate Oppty Yes No
TIP: The connector that emanates from the start step defaults to the name Connector 0. To suppress the text label for a connector, right-click the connector, choose the Edit menu, then the Hide Text menu item.
Next, define properties and arguments for workflow process steps.
Defining Properties and Arguments for Steps of the Workflow Process

In this topic, you define properties and arguments for workflow process steps.
To define properties and arguments for steps of the workflow process 1

Click the Insert Activity to Follow Up step, then use the Properties window to set properties using values from the following table. Property Business Component Operation Value Action Insert
2 3
Make sure the Insert Activity to Follow Up step is still chosen in the Process Designer. Add an input argument in the MVPW using values from the following table. Field Name Description Type Literal Value This is a large opportunity. Please call the customer ASAP.
For more information, see Arguments of the Step of a Workflow Process on page 49. You must first define the Field Name, then the Value.
Add a second process property using values from the following table. Field Name Type Type Literal Value To Do
258
Defining the Run-Time Event That Starts the Workflow Process

In this topic, you define the run-time event that starts the workflow process.
To define the run-time event that starts the workflow process 1 2 3

Choose the No connector, then use the Properties window to make sure the Type property is set to Default. Choose the Yes connector, then set the Type property to Condition. In the Process Designer, click the Evaluate Oppty connector, then use the properties window to define values described in the following table. Property Event Object Type Event Object Event Type Value BusComp Opportunity WriteRecord Default
When defining these properties, enter them in the top to bottom order that is displayed in the table. Because Event Object and Event are context sensitive, based on the value entered in Event Object Type, you must define Event Object Type first. The business scenario dictates that if the revenue for an opportunity is greater than $10,000, then an activity is inserted in the Activities view that directs the sales representative to pursue the opportunity with the customer. You use a decision condition on the decision point to implement this logic. Next, define the decision condition for the workflow process.
Defining a Decision Condition for the Decision Point

in this topic, you define a decision condition for the decision point.
To define a decision condition for the decision point 1

In the Process Designer, right-click the Yes connector, then choose Edit Conditions. The Compose Condition Criteria dialog box displays. A decision condition can be defined for a connector that emanates out of a start step, decision point, wait step, or user interact step. A decision condition is defined on the connector that emanates from a step. It is not defined directly on a step.
25 9
In the Compare To dropdown picklist, choose Business Component. The Compare To picklist is used to indicate whether an object, expression, or process property is used in the comparison. In this example, the comparison is made against the run-time value of a field from the Opportunity business component, as defined in the Object picklist. The items in the Object picklist are context sensitive. They change based on the value chosen in the Compare To picklist.
3 4
In the Object dropdown picklist, choose Opportunity. In the Operation dropdown picklist, choose Greater Than. In this example, if the value defined in the Values window of the Compose Condition Criteria dialog box is greater than the run-time value of the Revenue field for the business component, then the Operation picklist defines the decision condition that applies. The Revenue field is defined in the Field window.
5 6 7
In the Field window, choose Revenue. In the Values window, click New to add a new value. In the Add Value dialog box, type 10000, then click OK.
260
In the Compose Condition Criteria dialog box, click Add. The decision condition you defined in the lower portion of the Compose Condition Criteria dialog box is added to the Conditions list in the upper portion of the dialog. At this point, you can add another decision condition. For this example, you only add a single decision condition. The decision condition you set in the Compose Condition Criteria dialog box must resemble the condition illustrated in the following figure:
At run time, if the Revenue field on an opportunity is greater than 10000, then the Yes branch is pursued. Otherwise, the No branch is pursued.
Click OK.
10 From the application-level menu, choose the File menu, then the Save menu item.
Modifications you can perform after defining a decision condition include: To update a condition, click the condition in the Conditions window of the Compose Condition Criteria dialog box, modify the condition, then click Update. To delete a condition, click the condition in the Conditions window of the Compose Condition Criteria dialog box, then click Delete.
For more information, see Defining a Decision Condition on a Branch Connector on page 95. Next, test the workflow process.
26 1
Testing the Workflow Process

In this topic, you test the workflow process you defined in Defining the Workflow Process on page 256. You must prepare this example to test the workflow process by creating an opportunity that matches the test criteria. You create this opportunity, and note the row ID for the opportunity. This row ID is then used in the properties for the workflow process in order to run the test.
Preparing This Example For Testing

This topic describes how to prepare this example for testing.
To prepare this example for testing 1

Validate the workflow process. For more information, see Validate Tool on page 197.
2 3
Log in to the Siebel client, then navigate to the Opportunities list. Add an opportunity using values from the following table. Name Large Opportunity to Test Workflow Revenue $400,000
4 5 6
Right-click the record you created in Step 3, then choose About Record. Note the value of the row Id in the Row # field. In Siebel Tools, in the Process Designer, click the canvas, making sure no workflow process step or connector is chosen. If you click an empty space in the canvas, then the Multi Value Property Window (MVPW) displays the process properties for the workflow process.
In the MVPW, find the Object Id process property, then set the Default String field for the property to the Row Id for the opportunity you identified in Step 5.
Next, simulate the workflow process, then examine simulation results.
Simulating the Workflow Process

This topic describes how to simulate the workflow process then examine simulation results.
To simulate the workflow process 1

Use the Process Simulator to step through the entire workflow process. For more information, see Preparing to Use the Process Simulator on page 203.
In the Siebel client, navigate to the Opportunities screen.
262
3 4
In the Opportunities list, drill down on the opportunity named Large Opportunity to Test Workflow. Click the Activities view tab. A new Activity must be present, and it must contain the description you defined in Defining Properties and Arguments for Steps of the Workflow Process on page 258. If so, the simulation for the workflow process finishes successfully.
Remove the modifications you made for testing:
a b c d
In Siebel Tools, close the Simulator. In the WF Process Props OBLE, choose the Object Id process property for your workflow process. In the Properties window, delete the row ID in the Default String property. In the WF Process Props OBLE, step off the record to save your changes.
Deploying and Verifying the Workflow Process

If you finish a successful simulation of your workflow process, then you are ready to deploy it, and to verify that the workflow implements the required functionality.
To deploy and verify the workflow process 1

Deploy the workflow process:
a b c d
In the Siebel client, navigate to the Administration-Business Process screen, then the Workflow Deployment view. In the Repository Workflow Processes list, query the Name field for Large Opportunity Creates Activity. Click Activate. In the Active Workflow Processes list, query the Name field for Large Opportunity Creates Activity. The record displays a status of Active. For more information, see Process of Deploying a Workflow Process on page 211.
For more information, see Process of Deploying a Workflow Process on page 211.
2 3
In the Siebel client, add a new opportunity that includes a Revenue that is greater than $10,000. Step off the record, return to the record, drill down on the name of the record, then verify that an activity associated with the opportunity is automatically added, and that it includes the custom description you defined earlier in this example.
If you must modify the workflow process, then use the Revise feature on the WF/Task Editor toolbar in Siebel Tools. For more information, see About the Process Property on page 47.
26 3
Examples of Defining a Workflow Process Example of Defining a Workflow Process That Traverses a Record Set to Close Service Requests That Are Obsolete
Example of Defining a Workflow Process That Traverses a Record Set to Close Service Requests That Are Obsolete
This topic gives one example of using a workflow process to traverse a record set in order to close obsolete service requests. You might use this feature differently, depending on your business model. To develop this example, perform the following tasks:
1 2 3 4
Defining the New Business Component on page 264 Defining the Workflow Process on page 266 Testing the Workflow Process on page 274 Preparing the Workflow Process for Production on page 279
This example identifies, then closes obsolete service requests. If a service request is more than one year old with a Status that is not Closed or Cancelled, then the service request is considered obsolete. The workflow process identifies obsolete service requests, then traverses the resulting record set, changing the Status for each obsolete service request to Cancelled, the Sub-Status to Resolved, the Close Date to the current date, and adds a message to the Description that indicates the SR was cancelled due to obsolescence. For more information about the technique used in this example, see How the Siebel Operation Step Is Used to Traverse a Record Set on page 79.
Defining the New Business Component

Some requirements for this workflow process include: The workflow process must process a record from the primary business component of the business object on which the workflow process is based. A looping workflow process that processes a batch of records can loop only through the records of a non primary business component. This non primary business component must be based on the same business object that is defined for the workflow process. In this example, that business object is Service Request. The non primary business component must be established as a child of the business object for the primary business component.
The Service Request business component is the primary business component of the Service Request business object. To satisfy these requirements, you define a new, non primary business component named Service Request No Link. This new business component is a child of the primary Service Request business component. The child business component contains the minimum number of fields required by this business case, and those fields point to the same table columns as their counterpart fields in the primary business component. Thus, if a field is modified in the child, then the same field is modified in the primary business component. Both the primary and the child business component modify the same business component record.
264
A relationship must be established between the child and the business object for the primary business component. To establish this relationship, the child is defined as a Business Object Component on the Business Object for the primary business component.
Defining the Child Business Component To define the new business component, you begin by defining the child business component.
To define the child business component 1 2 3

In the Object Explorer, click Business Component. In the Business Component OBLE, right-click, then choose New Record. Define properties for the new business component using values from the following table. Property Name Project Class Table Value Service Request No Link Workflow Examples CSSBCBase S_SRV_REQ
4 5 6
Make sure Service Request No Link is chosen in the Business Components OBLE. In the Object Explorer, expand the Business Component tree, then click Field. In the Field OBLE, right-click, then choose New Record to add fields to the Service Request No Link business component. Add four new fields using values in the following table. Name Status Sub-Status Closed Date Description Column SR_STAT_ID SR_SUB_STAT_ID ACT_CLOSE_DT DESC_TEXT Text Length 30 30 (leave empty) 2,000 Type DTYPE_TEXT DTYPE_TEXT DTYPE_UTCDATETIME DTYPE_TEXT
Fields in the child business component correspond to fields with the same name in the primary business component. Because a field on the child references the same table and column as the counterpart for the field on the primary business component, the field modifies the same record. Because Created is a system field, it is not explicitly defined as a field on the primary business component, and is therefore not defined on the child. TIP: To reduce the number keystrokes you must perform, define the Column property first. When you define the Column property, then step out of the Column field in the OBLE, the Text Length and Type properties automatically populate.
26 5
Next, establish a relationship between the child and the Business Object for the primary business component.
Establishing a Relationship Between the Child and the Business Object for the Primary In this topic, you establish a relationship between the child and the business object for the primary.
To establish a relationship between the child and the business object for the primary 1
If necessary, expose the Business Object Component object type, which is a child of the Business Object object type. For more information, see Exposing Object Types That Are Used to Develop a Workflow Process on page 116.
2 3 4 5 6 7 8 9
In the Object Explorer, click Project. In the Project OBLE, query the Name property for Service. Make sure the Locked property for the Service project contains a check mark. In the Object Explorer, click Business Object. In the Business Objects OBLE, query the Name property for the Service Request business object. In the Object Explorer, expand the Business Object tree, then click Business Object Component. In the Business Object Components OBLE, right-click, then choose New Record. Set the Bus Comp property to Service Request No Link. Do not define a link. item.
10 From the Tools application-level menu, choose the Tools menu, then the Compile Projects menu 11 Choose Locked Projects, then compile to the repository that is used by your sample database.
This is typically [Siebel client root directory]\OBJECTS\[language]\siebel.srf.

Work that this workflow process performs include: Accepts a record of the Service Request business component. This record is not processed. Identifies obsolete service requests by querying the Service Request No Link business component for records whose Created date is more than one year old and whose Status is not Closed or Cancelled. Traverses records in the query result set, modifying the Status, Sub-Status, Close Date and Description fields to reflect the obsolete status of the record.
266
To define the workflow process 1

In Siebel Tools, define a new workflow process using values from the following table. Property Process Name Workflow Mode Business Object Value Close Obsolete SRs Service Flow Service Request
The two business service steps allows you to use the Watch window to debug the workflow. These are removed near then end of the configuration instructions for this example. For more information, see Overview of Workflow Process Steps on page 65, and Diagramming a Workflow Process on page 122.
26 7
Add seven new process properties using values from the following table. Name SR Close Date SR Created Date SR Description SR Status noRecord numAcceptedRecords vRowId In/Out In/Out In/Out In/Out In/Out None None None Business Object Service Request Service Request Service Request Service Request Service Request Service Request Service Request Data Type String String String String String Number Number
The first four process properties in the table are SR Close Date, SR Created Date, SR Description and SR Status. These properties provide a basis for using the Watch window in this example. They are not required to use the traverse record set technique. The last three records in the table are noRecord, numAcceptedRecords, and vRowId. These properties are required to use the traverse record set technique. For more information, see About the Process Property on page 47. TIP: To simplify defining a process property, define a process property, then fully define fields for it. Right-click this process property, then choose Copy Record. A copy of the process property is created with the same values as the original process property. For the copy, modify only those fields that require modification from the original.
Next, define the Query Primary workflow step.
To define the query primary workflow step

Click the Query Primary workflow step, then use the Properties window to define values described in the following table. Property Business Component Operation Value Service Request Query
Next, define the Query Child workflow step.
To define the query child workflow step 1

Click the Query Child workflow step.
268
Use the Properties window to define values described in the following table. Property Business Component Operation Value Service Request No Link Query
3 4
Make sure the Query Child workflow step is still chosen in the Process Designer. Click the MVPW, then click the Search Spec Input Arguments tab. Add a new record using values from the following table. Field Expression Business Component Filter Business Component Search Specification Value Service Request No Link Service Request No Link "([Created] < Timestamp()-365.0) AND ([Description] = 'Test SR') AND ([Status] <> 'Closed') AND ([Status] <> 'Cancelled')"
Enter the argument for the Search Specification exactly as displayed in the table. The entire specification must be enclosed within double quotes. Each search string must be enclosed with single quotes. A space is required before and after operators, such as the equal sign (=) and the not equal to sign (<>).
Click the Output Arguments tab. Add a new record using values from the following table. Field Property Name Type Output Argument: Value NumAcceptedRecords Output Argument NumAffRows
The Query operation uses NumAffRows as a container to hold the total number of rows that are returned from the query. In this example, the value in NumAffRows is stored in NumAcceptedRecords, a process property, which makes the value available later in the workflow on the Yes connector in order to trap for the case where no records are returned in the query.
26 9
Add a new output argument using values from the following table. Argument Property Name Type Value Value noRecord Literal false
You initialize noRecord at this point in preparation for the Yes connector that resides downstream of the decision point. If one or more records are returned in the query, then the Yes decision condition uses the value in noRecord to check for the end of the record set that is processed by the Read Next Record step.
Add a new output argument using values from the following table. Argument Property Name Type Business Component Name Business Component Field Value vRowId Business Component Service Request No Link Id
VRowId provides a way to display the record number in the Watch window while the workflow processes each record in the record set. It is used for debugging purposes in this example. The traversing a record set technique does not mandate this variable. Next, define a decision condition for the decision point.
To define a decision condition for the decision point 1 2 3

Click the Yes connector. In the Properties window , set the Type property to Condition. Right-click the Yes connector, then choose Edit Conditions.
270
Define the following decision condition, then click Add: Property Compare To Operation Object Value Value Process Property Greater Than NumAcceptedRecords 0
This decision condition traps for the instance where no records are returned from the query. If this condition is met, then the workflow process pursues the No connector.
Define the following decision condition, then click Add: Property Compare To Operation Object Value Value Process Property All Must Match (Ignore Case) noRecord false
This decision condition determines when the workflow reaches the end of the record set in cases where at least one record is returned in the query. For more information, see Defining a Decision Condition on a Branch Connector on page 95.
6 7
Click OK. Click the No connector. Make sure the Type property in the Properties window is set to Default.
Next, define the Watch Pre-update Values workflow step.
To define the watch pre-update values workflow step 1 2

Click the Watch Pre-update Values workflow step. Use the Properties window to define values described in the following table. Property Business Service Name Business Service Method Value Workflow Utilities Echo
The Workflow Utilities business service provides a way to view variables in the Watch window. For more information, see Workflow Utilities Business Service on page 487.
27 1
In the MVPW, click the Output Arguments tab. Add four new output arguments using values from the following table. Business Component Name Service Request No Link Service Request No Link Service Request No Link Service Request No Link Business Component Field Closed Date Description Created Status
Property Name SR Close Date SR Description SR Created Date SR Status
Type Business Component Business Component Business Component Business Component
This workflow step provides data that the Workflow Utility business service uses in order to display field values for the record of the business component that is currently processed. These values are displayed in the Watch window. Values that are displayed reflect their state prior to updating. Depending on your testing requirements, you can display more descriptive record data, such as data from the Abstract field. To display other record data, define another Field, similar as you did with fields described in Step 6 on page 265. In the workflow process, define a process property that references that field, then add an Output Argument on the Workflow Utility business service that references the new process property. Next, define the Update Fields workflow step.
To define the update fields workflow step 1 2

Click the Update Fields workflow step. Use the Properties window to define values described in the following table. Property Business Component Operation Value Service Request No Link Update
In the MVPW, click the Field Input Arguments tab. Add three new input arguments using values from the following table. Field Name Closed Date Description Status Type Expression Literal Literal Value Timestamp() This SR's Status set to Cancelled due to this SR's obsolescence Cancelled
Next, define the Watch Post-update Values workflow step.
272
To define the watch post-update values workflow step 1 2

Click the Watch Post-update Values workflow step. Use the Properties window to define values described in the following table. Property Business Service Name Business Service Method Value Workflow Utilities Echo
In the MVPW, click the Output Arguments tab. Add four new output arguments using values from the following table. Business Component Name Service Request No Link Service Request No Link Service Request No Link Service Request No Link Business Component Field Closed Date Description Created Status
Property Name SR Close Date SR Description SR Created Date SR Status
Type Business Component Business Component Business Component Business Component
Next, define the Read Next Record workflow step.
To define the read next record workflow step 1 2

Click the Read Next Record workflow step. Use the Properties window to define values described in the following table. Property Business Component Operation Value Service Request No Link NextRecord
In the MVPW, click the Output Arguments tab, then add a new output argument using values from the following table. Field Property Name Type Output Argument Value noRecord Output Argument NoMoreRecords
27 3
Add a second argument using values from the following table. Field Property Name Type Business Component Name Business Component Field Value vRowId Business Component Service Request No Link Id
From the Tools application-level menu, choose the File menu, then the Save menu item.
Next, you use the Process Simulator and Watch window to test the workflow.

In this example, you first modify several service requests by using the Siebel client in order to delineate a set of test records that the workflow process traverses. Then, you use the Process Simulator and Watch window to test the workflow process. For more information, see Using the Watch Window on page 199. CAUTION: Although you are simulating the workflow process, the Update Fields step in this workflow process modifies records in the query results. It is important to remain cognizant of the fact that the traversing a record set technique processes a set of real records. If a step in the workflow modifies records, then the values for most if not every record in the database that meet the search criteria is modified.
Preparing Test Records for the Service Requests In this topic, you prepare test records for the service requests.
To prepare test records for the service requests 1 2 3

Log in to the Siebel client, connected to the Sample database. Navigate to the Service Requests screen, then the Service Request List view. Locate three records that contain an Opened date that is more than one year from the date that the workflow process is tested. For example, if you test the workflow on February 15, 2009, then make sure the Opened date for each service request is prior to February 15, 2008.
274
Modify the three records so that there are three service requests in the database that contain a Description of Test SR, and that one request is Open, one Closed, and one Cancelled. Use the values described in the following table. Status Open Closed Cancelled Description Test SR Test SR Test SR
These modifications provide a way to test the workflow process on a small, constricted set of records.
5 6
Create a new service request. Set Status to Open and enter Test SR in the Description. Log out of the Siebel client.
Next, validate and simulate the workflow process.
Validating and Simulating the Workflow Process In this topic, you validate and simulate the workflow process.
To validate and simulate the workflow process 1

Validate the workflow process. For more information, see Validating the Workflow Process on page 202.
2 3
In Siebel Tools, right-click the canvas of the Process Designer, then choose Simulate. For more information, see Preparing to Use the Process Simulator on page 203. Click Start Simulation. Wait for the Siebel client to launch, control to return to Siebel Tools, and for the simulator to automatically highlight the Query Primary workflow process step. For caution information, see Testing the Workflow Process on page 274.
4 5
From the Tools application-level menu, choose the View menu, Debug Windows, then the Watch menu item. Click the push pin to dock the window. You must initiate the simulation, as described Step 3, prior to opening the Watch window.
27 5
Click the expand icon located next to PS:Property Set, then expand the Process Properties entry in the Property Set list. Process properties that are defined for this workflow process are displayed along with the current value for each property. To check this list, stop the simulation, then compare the list of properties in the Watch window to the list of records in the MVPW. No values are displayed in the Process Properties section of the Watch window until after the simulator calls the Workflow Utilities business service, which it does when the simulator executes the Watch Pre-update Values step.
Click Simulate Next, then expand the BusComp entry in the Watch window. The simulator executes the Query Primary Step, then highlights the Query Child step. The Query Primary step performs an unrestricted query on the Service Request business component, returning every service request that exists in the database. The Watch window now displays a BusComp entry that contains a list of values for the current business component record.
276
Click Simulate Next. The simulator executes the Query Child step, then highlights the More Records decision point. The search specification on the Query Child workflow process step results in the creation of a record set that contains four service request records. In essence, Query Child populates the Service Request No Link business component with these metadata records. In addition to several system variables, the Process Properties section of the Watch window now contains values for two process properties that reference important variables that are used with the traversing a record set technique, as described in the following table. Property NumAcceptedRecords Value 1 Explanation NumAcceptedRecords is a process property that references NumAffRows, which is a variable that is used with the traversing a record set technique. NumAffRows maintains a count of the number of rows that are returned from the query on the Query Child workflow step. In this example, one record met the search specification defined on the Query Child step. noRecord false noRecord is a process property that references NoMoreRecords, which is a variable that is used with the traversing a record set technique. NoMoreRecords is a flag that indicates if records remain to be processed in the record set. The NextRecord operation sets NoMoreRecords to true when there are no more records to traverse in the record set. For every iteration through the record set, the NextRecord operation on the Read Next Record workflow step writes the value of NoMoreRecords to the noRecord process property. The BusComp section of the Watch window only displays record data from the query that was performed on the primary business component. This information does not change for the remainder of the simulation.
Click Simulate Next. The simulator executes the logic that is associated with the More Records decision point, then highlights the Watch Pre-update Values step. The Yes connector performs two tests to determine if flow continues or halts. A value of 0 in NumAcceptedRows indicates no records matched the search specification on the Query Child workflow step. A value of true in noRecord indicates there are no more records to process in the record set. If either case is true, then the workflow process ends. Because the value for NumAcceptedRecords is 1 and noRecord is false for the workflow in this example, the Yes connector is pursued.
27 7

The simulator executes the Watch Pre-update Values step, then highlights the Update Fields step. Several values under the Process Properties entry in the Watch window populate when this step is executed. Four service request fields that are modified during the example were defined. Writing to the Watch window both before and after the Update Fields workflow step allows you to clearly determine if the fields of the business component are updated appropriately. The values are described in the following table. Property SR Close Date SR Description Value (empty) Test SR Explanation Because the search specification on the Query Child workflow step excludes Closed records, the Close Date is empty. Your test records include Test SR in the Description. This value is provided to make sure only those records in the test record set are evaluated. The search specification on the Query Child workflow step excludes a Closed or Cancelled service request, but allows a service request that is Open, Pending, Field Visit, and Quoted. However, there is only one record in the resulting record set, with a value of Open. Although there is only one record in the record set, the NextRecord operation is not executed, so noRecord contains false.
SR Status
Open
noRecord
false

The simulator executes the Update Fields workflow step, then highlights the Watch Post-update Values workflow step. Although the Update Fields workflow step updates three service request fields, changes to the values in those fields are not reflected until the workflow explicitly writes the updated information to the Watch window.
278
The simulator executes the Watch Post-update Values workflow step, then highlights the Read Next Record workflow step. The Watch window displays the updated values for the record of the business component, as described in the following table. Property SR Close Date SR Description Value 11/12/2007 14:21:04 The Status for this service request is set to Cancelled due to the obsolescence for the service request. Cancelled false Description Set by the Input Argument on the Update Fields process step. Set by the Input Argument on the Update Fields process step.
SR Status noRecord
Set by the Input Argument on the Update Fields process step. NextRecord operation is not executed, so noRecord still contains false.

The simulator executes the Read Next Record workflow step, then highlights the More Records decision point. In the Watch window, values for the process properties remain constant except for noRecord. Because there is only one record in the record set, the NextRecord operation sets noRecord to true.

The simulator executes the logic that is associated with the decision point, then highlights the end workflow step. Because this simulation modifies records in the record set, to run the simulation again you must first reset values that were changed in the record set. In this case, for the record that the workflow process modified, you must reset SR Description to SR Test, and reset Status to Open. This example tests a small set of service request records. For a more thorough test, create more service request records that meet or do not meet the decision condition defined in the workflow process. Simulate the workflow again, using the Watch window to make sure the modifications accurately reflect the required outcomes for the workflow.
Preparing the Workflow Process for Production

To prepare the workflow process for a production environment, you can remove some of the configuration that is specific to supporting debugging activities. CAUTION: The traversing a record set technique can potentially modify a large number of records in your database. To avoid unwanted modifications to numerous records, when using this technique make sure your workflow is fully tested and achieves the required results. In this example, removing the Description from the Search Specification broadens the search to consider and possibly modify every service request that is over one year old and is not Closed or Cancelled.
27 9
To prepare the workflow process for production 1 2 3 4 5

Delete the Watch Pre-update Values and Watch Post-update Values workflow steps. In the MVPW, you can delete SR Close Date, CR Created Date, SR Description, and SR Status. Click the Query Child workflow step. In the MVPW, click the Search Spec Input Arguments tab. In the Search Specification, in the Description string, replace the search specification that was used for testing with the search specification that must be used for production, as described in the following table. Search Specification Used for Testing "([Created] < Timestamp()-365.0) AND ([Description] = 'Test SR') AND ([Status] <> 'Closed') AND ([Status] <> 'Cancelled')" Search Specification Used for Production "([Created] < Timestamp()-365.0) AND ([Status] <> 'Closed') AND ([Status] <> 'Cancelled')"
For caution information, see the caution at the beginning of this topic.
6 7 8
If required, restore your test records to their original data. If you made modifications to the Service Request No Link business component, such as adding new fields, then compile your work again. Identify, then implement a way to start the workflow process. This example is based on maintenance administrative work that occurs on a regularly scheduled interval, such as daily, weekly or monthly. One way to start the workflow process is to configure a repeating component job for the Workflow Process Manager component. For more information on how to configure a component to run repeatedly at specific times over specific intervals, see Usage of the Repeating Component Request on page 173.
280
Examples of Defining a Workflow Process Example of Defining a Workflow Process That Attaches an Activity Plan to an Opportunity
Example of Defining a Workflow Process That Attaches an Activity Plan to an Opportunity

This topic gives one example of using a workflow process to attach an activity plan to an opportunity. You might use this feature differently, depending on your business model. To develop this example, perform the following tasks:
1 2 3 4 5
Defining the New Workflow Process on page 281 Testing the Workflow Process on page 283 Defining How the Workflow Process is Started on page 284 Deploying the Workflow Process on page 286 Verifying Functionality of the Workflow Process on page 287
In this example, you define a workflow process that creates an activity plan for an opportunity, then navigates the user to a view that displays the new plan. The workflow then waits for the user to enter more data and save changes before continuing. You use the Process Simulator and the Siebel client to test the workflow.
Defining the New Workflow Process

To begin, you define the new workflow process, define step properties, then validate the workflow.
To define the new workflow process 1

In Siebel Tools, define a new workflow process using values from the following table. Property Process Name Business Object Workflow Mode Value Create Plan Opportunity Interactive Flow
In the Workflow Processes OBLE, right-click the new workflow process, then choose Edit Workflow Process.
28 1
For more information, see Overview of Workflow Process Steps on page 65, and Diagramming a Workflow Process on page 122. Next, define properties of the workflow step.
To define properties of the workflow step 1 2

In the Process Designer, click the Add Activity Plan to Oppty step. In the Properties window, define the business component and the operation by entering values described in the following table. Property Business Component Operation Value Activity Plan Insert
If you perform an Insert operation on a business component, then you must supply a value for fields that are required in the business component. In particular, to insert a new activity plan, you must provide the name of the template for the activity plan.
3 4
Make sure the Add Activity Plan to Oppty workflow step is still chosen in the Process Designer. In the MVPW, add a new input argument using values from the following table. Field Name Template Type Literal Value A valid activity template name, such as Introductory Sales Call.
In the Process Designer, choose the Display Activity Plan step.
282
Use the Properties window to define which view is displayed for the Display Activity Plan user interact step. Use values described in the following table. Property User Interact View Value Opportunity Activity Plan
Click the connector located between the Display Activity Plan step and the end step, then define properties in the Properties window using values from the following table. Property Event Object Type Event Event Object Type Value BusComp WriteRecordUpdated Activity Plan Condition
The run-time event signals the end of the Display Activity Plan user interact step, which is achieved by defining a conditional branch that emanates from the Display Activity Plan step. For this example, you must wait for the user to make and save a change to the Activity Plan before continuing the workflow process. WriteRecordUpdated is the run-time event that signals this change. For the Event and Event Object picklists to populate correctly for this example, you must define the Event Object Type first. Next, test the workflow process.

In this topic, you validate, then simulate the workflow process you defined in Defining the New Workflow Process on page 281. Because this workflow is based on the Opportunity business object and the workflow attempts to add an activity plan to an existing opportunity, you must define the row Id for a specific opportunity in order to allow the Process Simulator to execute logic for the workflow. Before you can test your workflow process, you create an opportunity that matches the test criteria. You create this opportunity, then note the row ID for the opportunity. This row ID is then used in the properties for the workflow process in order to run the test.
Preparing Example Data for the Simulation In this topic, you prepare example data for the simulation.
To prepare example data for the simulation 1

Log in to the Siebel client as SADMIN connected to the Sample database.
28 3
2 3 4 5
Navigate to the Opportunities list. Choose an opportunity, right-click, then choose About Record. Note the value of the row ID in the Row # field, then click OK to close the About Record dialog box. In Siebel Tools, in the MVPW, find the Object Id process property, then set the Default String field for the property to the row Id of the opportunity you identified in Step 4. If the MVPW is not visible, then, from the application-level menu, choose the View menu, Windows, then the Multi Value Property Window menu item.
Next, you validate, then simulate the workflow process.
Validating and Simulating the Workflow Process In this topic, you validate, then simulate the workflow process.
To validate, then simulate the workflow process 1

Validate, then simulate the workflow process. For more information, see Process of Testing a Workflow on page 202. After you reach the user interact step in the simulation, use the Siebel client to make a change to the Activity Plan, then save your changes. For example, change values in the Planned Start Date field or in the Description field. You cannot reach the end step by clicking Next after the Opportunity Activity Plan view displays in the Siebel client. Because you defined a decision condition on the branch, you must satisfy the condition in order to allow the logic of the workflow to proceed to the end step.
Acknowledge the message that displays at the end of the workflow process. When the last step is reached, the Siebel client displays a message reporting Simulation
terminated! Please check the Watch window for details.
3 4
Enter Alt+Tab to return to Siebel Tools, then click Next to finish the end step. In the Watch window, view the Simulator Status field. If Simulation ended successfully displays, then the workflow process ended without error.
Next, you define how the workflow process is started.
Defining How the Workflow Process is Started

Now that you built and simulated a workflow process, you must decide where and how it is started from the user interface. For this example, you add a button to the Opportunity list to start the workflow. For more information, see Starting a Workflow Process on page 143.
To how the workflow process is started 1

In Siebel Tools, in the Object Explorer, click Applet.
284
2 3 4
In the Applets OBLE, query the Name property for Opportunity List Applet. Right-click, then choose Edit Web Layout. In the Controls/Columns window, set the Mode to 3: Edit List. By default, Mode is set to 1: Base. You must set it to 3: Edit List. If the Controls/Columns window is not visible, then, from the application-level menu, choose the View menu, Windows, then the Controls Window menu item.
Drag a Button control from the palette to the layout, then set the properties for the control using values from the following table. Property Caption-String Override HTML Type MethodInvoked Value Create Plans MiniButton EventMethodCreateActivityPlan
The value displayed in the table does not appear in the MethodInvoked picklist. You must manually enter the value for MethodInvoked. Methods that use the naming format EventMethod[a string value] do not require an applet or script on a business component to allow the event. If you do not use this special naming convention, then you must write a WebApplet_PreCanInvokeMethod script to allow the event.
Preview the applet. Make sure the new Create Plan button displays as illustrated in the following figure:
7 8
Save the applet changes. Compile your changes to the SRF in your Siebel client directory.
Next, define the workflow process that is started when the run-time event is detected.
To define the workflow process that is started when the run-time event is detected 1
In the Object Explorer, click Workflow Process.
28 5
2 3 4
In the Workflow Processes OBLE, query the Process Name property for the Create Plan workflow process you defined in Defining the New Workflow Process on page 281. Right-click the workflow process, then choose Edit Workflow Process. Click the connector between the start step and the step named Add Activity Plan to Oppty, then use the Properties window to set properties for the connector using values from the following table. Property Type Event Object Type Event Object Event Subevent EventCancelFlag Value Condition Applet Opportunity List Applet PreInvokeMethod EventMethodCreateActivityPlan TRUE
This configuration supplies a start condition for the workflow process so that the workflow is started when EventMethodCreateActivityPlan occurs on the Opportunity List Applet.
Next, deploy the workflow process.
Deploying the Workflow Process

Before the new workflow process can be called in the Siebel client, you must deploy it.
To deploy the workflow process 1

Deploy the workflow process. For more information, see Process of Deploying a Workflow Process on page 211.
2 3 4
In the Active Workflow Processes list, set the Monitoring Level to 4-Debug. Make sure you reload run-time events. Make sure a run-time event was generated for this workflow process:
a b
Navigate to the Administration-Runtime Events screen, then the Events view. Query the Subevent for EventMethodCreateActivityPlan.
This technique starts the workflow process. One record must be returned. Next, you verify the workflow process.
286
Verifying Functionality of the Workflow Process

In this topic, you verify that the workflow process implements the required functionality.
To verify functionality of the workflow process 1 2

In the Siebel client, navigate to the Opportunities screen, then the All Opportunities view. In the All Opportunities list, click Create Plan. This step starts the workflow process for an opportunity. The workflow navigates you to the Opportunity Activity Plan view.
3 4
Edit the Description field for the plan, then save your changes. Navigate to the Administration-Business Process screen, then the Workflow Instance Monitor view. For more information, see Monitoring Instances of a Workflow Process on page 233.
5 6
In the Workflow Process list, query the Name field for the Create Plan workflow process. The related instance data displays in the bottom list. Choose the Step Instances tab to view step instance details.
If your workflow process runs without error, then you can turn off monitoring for the workflow.
To turn off monitoring for the workflow process 1 2 3

Navigate to the Administration-Business Process screen, then the Workflow Deployment view. In the Active Workflow Processes list, query the name field for the workflow process named Create Plan. Set the Monitoring Level field to 0-None.
28 7
Examples of Defining a Workflow Process Example of Defining a Workflow Process That Manages Research Activities for a Service Request
Example of Defining a Workflow Process That Manages Research Activities for a Service Request
This topic gives one example of using a workflow process to manage research activities for a service request. You might use this feature differently, depending on your business model. To develop this example, perform the following tasks:
1 2 3 4
Defining the Workflow Process on page 288 Defining Logic for the Workflow Process on page 289 Testing and Deploying the Workflow Process on page 290 Verifying Functionality of the Workflow Process on page 290
In this example, a workflow process detects a service request being taken ownership of, then automatically creates an activity of type Research. The workflow then provides the SR owner with initial items that can be used in research. You define a simple workflow that is initiated by a run-time event. You become familiar with elements involved in setting up this workflow, and you see that the workflow process and the run-time event work.

This topic describes how to define the workflow process.

In Siebel Tools, define a new workflow process using values from the following table. Property Process Name Business Object Group Workflow Mode Auto Persist Description Value SR Assigned-Auto Create Activities Service Request (Leave this field empty.) Service Flow No Automatically generates a research activity when SR ownership change is detected by using RTE
288
For more information, see Overview of Workflow Process Steps on page 65, and Diagramming a Workflow Process on page 122. Next, define the workflow logic.
Defining Logic for the Workflow Process

This topic describes how to define the workflow logic.
To define logic for the workflow process 1 2

Click the SR Owner Field Updated connector. In the Properties window, define properties for the connector using values from the following table. Property Type Event Object Type Event Event Object Subevent Value Condition BusComp SetFieldValue Service Request Owner
Click the Create Research Activity step, then use the Properties window to define values described in the following table. Property Operation Business Component Value Insert Action
Next, define fields to populate when inserting a new business component record.
To define fields to populate when inserting a new business component record 1

Make sure the Create Research Activity step is chosen.
28 9
Define two new input arguments using values from the following table. Field Name Type Description Type Literal Literal Value Research Research the following: Siebel Bookshelf
For more information, see Arguments of the Step of a Workflow Process on page 49. If performing an insert into a business component, then make sure fields that are required in the business component are defined in this step. Alternatively, define a value in the Pre Default Value property for the fields of the business component. To access this property, expand the Business Component object type in the Object Explorer, then click the child Field object type.
Next, test and deploy the workflow process.
Testing and Deploying the Workflow Process

In this topic, you test and deploy the workflow process.
To test and deploy the workflow process 1

2 3 4
Navigate to the Workflow Processes OBLE. Query the Process Name property for the SR Assigned-Auto Create Activities workflow process. Deploy the workflow process. For more information, see Process of Deploying a Workflow Process on page 211.
If you must debug the workflow process, then, in the Siebel client, in the Active Workflow Processes list, set the Monitoring Level to 4-Debug. For more information, see Diagnosing a Workflow Process That Has Failed on page 240.
Next, verify workflow process functionality.

This topic describes how to verify that the workflow process implements the required functionality.

In the Siebel client, navigate to the Service Requests screen, then the All Service Requests view. Create a new service request, then step off the record.
290
3 4
In the Service Request list, click the hyperlink in the SR # field. Examine the Activities tab. If the workflow executes correctly, then values displayed in the Activities list include:

Type: Research Description: Will research the following: Siebel Bookshelf
29 1
Examples of Defining a Workflow Process Example of Defining a Workflow Process That Manages Creation of a Service Request
Example of Defining a Workflow Process That Manages Creation of a Service Request

This topic gives one example of using a workflow process to manage service request creation. You might use this feature differently, depending on your business model. To develop this example, perform the following tasks:
1 2 3 4
Defining the Workflow Process on page 292. Defining Connectors for the Workflow Process on page 293. Defining Properties for the Siebel Operation Steps on page 296. Testing, Deploying, and Verifying the Workflow Process on page 300.
In this example, work that the workflow process automatically performs include: Detects when an end user creates a new service request Assigns the new service request to the creator Changes the SR Sub-Status to Assigned to reflect the ownership Sets the commit time on the SR, depending on the priority Creates an activity with a description of research steps that the SR owner can perform to resolve the SR
You define a simple workflow process that is initiated by a run-time event. You become familiar with elements involved in setting up this workflow process, and you observe how a workflow process works in conjunction with a run-time event to make several modifications to a service request.

In this topic, you define the workflow process.
292

In Siebel Tools, define a new workflow process using values from the following table. Property Process Name Business Object Group Workflow Mode Auto Persist Description Value Manage New SR Service Request (Leave this field empty.) Service Flow No For new SRs, automatically modifies several SR fields. Considers SR priority during modifications.
For more information, see Overview of Workflow Process Steps on page 65, and Diagramming a Workflow Process on page 122. Next, define the connectors for this workflow process.
Defining Connectors for the Workflow Process

In this topic, you define connectors for the workflow process.
29 3
To define the connectors for the workflow process 1

Click the Start Workflow connector, then use the Properties window to define properties using values from the following table. Property Type Event Object Type Event Event Object Value Condition BusComp WriteRecordNew Service Request
This configuration starts the workflow process when a WriteRecordNew run-time event is detected on a service request.
Click each connector in succession that emanates from the decision point. In the figure in Step 2 on page 293, these are labeled ASAP, High, Medium, and Low. As you click each connector, make sure the Type property in the Properties window is set to Condition.
Click the connector labeled Priority Not Set, then define properties using values from the following table. Property Type Value Default
4 5
Right-click the ASAP connector, then choose Edit Conditions. In the Compose Condition Criteria dialog box, define the decision condition using values from the following table. Property Compare To Operation Object Field Value Value Business Component All Must Match (Ignore Case) Service Request Priority 1-ASAP
Decision conditions in this workflow process are defined for the ASAP, High, Medium and Low connectors. Each conditional statement corresponds to a Priority value. Depending on how each priority evaluates in the priority connector decision condition, the workflow adjusts the Commit Time in the subsequent Siebel operation step. For more information, see Defining a Decision Condition on a Branch Connector on page 95.
294
6 7
Right-click the High connector, then choose Edit Conditions to access the Compose Condition Criteria dialog box. In the Compose Condition Criteria dialog box, define the decision condition using values from the following table. Property Compare To Operation Object Field Value Value Business Component All Must Match (Ignore Case) Service Request Priority 2-High
8 9
Right-click the Medium connector, then choose Edit Conditions to access the Compose Condition Criteria dialog box. In the Compose Condition Criteria dialog box, define the decision condition using values from the following table. Property Compare To Operation Object Field Value Value Business Component All Must Match (Ignore Case) Service Request Priority 3-Medium
10 Right-click the Low connector, then choose Edit Conditions to access the Compose Condition
Criteria dialog box.
29 5
11 In the Compose Condition Criteria dialog box, define the decision condition using values from the
following table. Property Compare To Operation Object Field Value Value Business Component All Must Match (Ignore Case) Service Request Priority 4-Low
TIP: For clarity, in this example you are directed to define several connectors, placing them on the canvas consecutively. You can use an alternative technique when your workflow process contains multiple connectors, and where each of these connectors contain similar definitions. You can define a single branch connector, define the decision condition, then copy and paste this connector for use elsewhere in the workflow. You can then define the variance on each connector, in this case the Value. The Siebel operation steps in this workflow can also be defined using the same cut and paste technique.
12 From the application-level menu, choose the File menu, then the Save menu item. 13 Close the Process Designer.
Next, define properties for the Siebel operation steps.
Defining Properties for the Siebel Operation Steps

In this topic, you define properties for the Siebel operation steps.
To define properties for the Siebel operation steps 1 2 3 4 5 6 7

From the application-level menu, choose the View menu, then the Options menu item. Click the Object Explorer tab, then scroll down to the Workflow Process entry in the Object Explorer Hierarchy window. In the Object Explorer Hierarchy window of the Development Tools Options dialog box, expand the Workflow Process hierarchy, then expand the WF Step hierarchy. Make sure there is a check mark next to the WF Step I/O Argument hierarchy, then click OK. in the Workflow Processes OBLE, query the Process Name property for the Manage New SR workflow process. In the Object Explorer, expand the Workflow Process tree, then click WF Step. Right-click in the WF Steps OBLE, then choose Columns Displayed. Arrange columns to reflect the order displayed in the screen print in Step 8.
296
Set the Business Component property and the Operation property for each of the Siebel operation steps in the workflow process. The resulting properties must resemble those displayed in the following figure:
Next, define input arguments for the Siebel operation steps that set the commit time.
Defining Input Arguments for the Siebel Operation Steps That Set the Commit Time Some properties for a workflow process can be defined in the Process Designer or the Workflow Processes OBLE, depending on your personal preference. In this procedure, you use the Workflow Processes OBLE to define several properties for workflow steps. To define these properties by using the Process Designer, you use the Properties window.
To define input arguments for the Siebel operation steps that set the commit time 1
Locate the Manage New SR workflow process. For more information, see Locating a Workflow Process in the Workflow Processes Object List Editor on page 43.
2 3
Right-click the Manage New SR workflow process, then choose Edit Workflow Process to open the Process Designer. Click the Siebel operation step named Set Commit Time in 1 Hour.
29 7
In the MVPW, define three new input arguments using values from the following table. Field Name Sub-Status Owner Commit Time Type Literal Business Component Expression Value Assigned (Leave this field empty.) [Created]+0.4166 Business Component Name (Leave this field empty.) Service Request (Leave this field empty.) Business Component Field (Leave this field empty.) Created By Name (Leave this field empty.)
For more information, see Arguments of the Step of a Workflow Process on page 49. These arguments provide instructions to the Siebel operation when the ASAP branch is satisfied. In this case, the Sub-Status field is set to Assigned, the Owner field is assigned to the value in Created By Name, and the Commit Time is set to one hour after the time that the SR was created. Commit Time contains a Type property of DTYPE_UTCDATETIME, which is a datetime field. Created contains a time stamp of when the SR was created. When a number is entered in a datetime field, days are represented by integers and hours. Minutes and seconds are represented by fractions. For more information, see Timestamp Usage on page 188. NOTE: The entire expression in the Value property for the Commit Time Field Input Argument must be enclosed in double quotes. A space must precede and follow the plus sign ( + ).
5 6
Click the Siebel operation step named Set Commit Time in 2 Hours. In the MVPW, define three new input arguments using values from the following table. Field Name Sub-Status Owner Commit Time Type Literal Business Component Expression Value Assigned (Leave this field empty.) [Created]+0. Business Component Name (Leave this field empty.) Service Request (Leave this field empty.) Business Component Field (Leave this field empty.) Created By Name (Leave this field empty.)
Click the Siebel operation step named Set Commit Time in 24 Hours.
298
In the MVPW, define three new input arguments using values from the following table. Field Name Sub-Status Owner Commit Time Type Literal Business Component Expression Value Assigned (Leave this field empty.) [Created]+24 Business Component Name (Leave this field empty.) Service Request (Leave this field empty.) Business Component Field (Leave this field empty.) Created By Name (Leave this field empty.)
Click the Siebel operation step named Set Commit Time in 48 Hours.
10 In the MVPW, define three new input arguments using values from the following table.
Field Name Sub-Status Owner Commit Time Type Literal Business Component Expression Value Assigned (Leave this field empty.) [Created]+48 Business Component Name (Leave this field empty.) Service Request (Leave this field empty.) Business Component Field (Leave this field empty.) Created By Name (Leave this field empty.)
Next, define Input Arguments for the Siebel operation steps named Create Plan of Action.
To define input arguments for the create plan of action Siebel operation step 1
Click the Siebel operation step named Create Plan of Action. This step creates an activity for the service request with a description that contains a set of actions the owner can follow.
In the MVPW, define two new input arguments using values from the following table. Field Name Type Comment Type Literal Literal Value Research Plan of Action: 1. Make sure customer logged description. 2. Reproduce the behavior. 3. Request logs.
Save your work, then close the Process Designer.
Next, you test, deploy, and verify the workflow process.
29 9
Testing, Deploying, and Verifying the Workflow Process

In this topic, you test and deploy the workflow process, then verify that the workflow implements the required functionality.

Deploy the workflow process. For more information, see Process of Deploying a Workflow Process on page 211. While performing the deploy procedure, make sure you reload run-time events.
Next, verify functionality of the workflow process.
To verify functionality of the workflow process 1 2 3 4

In the Siebel client, navigate to the Service Requests screen, then the All Service Requests view. Create a new service request. Set a value for the Priority field, or leave it blank. Save the record. When you step off the record, notice that the Siebel client delays slightly and an hourglass displays, which indicates that the workflow process is executing.
5 6 7 8
Choose the service request you just saved, then examine the Owner, Substatus and Date Committed fields. Verify that they are populated correctly. Click the Activities tab. Notice that the new activity created by the workflow process displays. Examine the Comments field to verify it is populated according to the input arguments you defined on the Siebel operation named Create Plan of Action. Test out a few scenarios by creating service requests with different Priority values and observe how the workflow process decision point performs.
300
Examples of Defining a Workflow Process Example of Defining a Workflow Process That Manages Creation of a Service Request then Navigates the User
Example of Defining a Workflow Process That Manages Creation of a Service Request then Navigates the User
This topic gives one example of using a workflow process to manage the creation of a service request, then navigate the user to a view. You might use this feature differently, depending on your business model. To develop this example, perform the following tasks:
1 2 3
Modifying the Existing Workflow Process on page 301 Testing and Deploying the Workflow Process on page 303. Verifying Functionality of the Workflow Process on page 303.
This example is similar to Example of Defining a Workflow Process That Manages Creation of a Service Request on page 292, with one addition. In this example, the workflow process automatically navigates the user to the Activities view of the Service Request screen, where the user can peruse newly created activities that are associated with the service request.
Modifying the Existing Workflow Process

In this topic, you copy and modify an existing workflow process.
To modify the existing workflow process 1 2 3

Log in to Siebel Tools as SADMIN connected to the sample database. In the Object Explorer, click Workflow Process. In the Workflow Processes OBLE, right-click the workflow process named Manage New SR, then choose Copy Record. This example assumes you defined and tested the Example of Defining a Workflow Process That Manages Creation of a Service Request on page 292. In this example, you can use the Revise feature on the WF/Task Editor Toolbar instead of the copy feature. The Copy feature is used in this step in the event you must continue working on the Manage New SR workflow process at some point in the future without the additional modification defined in this procedure.
Set the properties for the new workflow process using values from the following table. Property Process Name Workflow Mode Value Manage New SR-Navigate User to SR Activity Interactive Flow
Right-click the workflow process named Manage New SR-Navigate User to SR Activity, then choose Edit Workflow Process to open the Process Designer.
30 1
6 7
Drag, then drop a User Interact step from the palette to the canvas, placing it between the Create Plan of Action step and the End step. Add connectors between the Create Plan of Action step and the user interact step; and between the user interact step and the End step, as illustrated in the following figure:
Click the user interact step, then use the Properties window to set properties using values from the following table. Property Name User Interact View Value Display SR Activities View Service Request Detail View
Confirm the value set for the User Interact View property:
a b c
In the Siebel client, navigate to the Service Requests screen, then the All Service Requests view. Click the Activities view tab. From the application-level menu, choose the Help menu, then the About View menu item. The required view name displays.
302
10 Click the connector that connects the user interact step with the end step, then use the Properties
window to set properties using values from the following table. Property Type Event Object Type Event Object Event Value Condition BusComp Service Request WriteRecordUpdated
11 From the application-level menu, choose the File menu, then the Save menu item.
Next, test and deploy the workflow process.
Testing and Deploying the Workflow Process

This topic describes how to test and deploy the workflow process.

Deploy the workflow process. For more information, see Process of Deploying a Workflow Process on page 211.
Next, verify functionality of the workflow process.

This topic describes how to verify that the workflow process implements the required functionality.

In the Siebel client, navigate to the Administration-Business Process screen, then the Workflow Deployment view. Deactivate previous workflow processes where the business object for the process is set to Service Request. This way, other workflow processes do not run or interfere with starting the workflow process that is used for this example:
a b c 3 4
In the Active Workflow Processes list, query the Business Object field for Service Request. From the application-level menu, choose the Edit menu, then the Select All menu item. In the Active Workflow Processes list, click Menu, then choose Deactivate Process.
In the Repository Workflow Processes list, query the Name field for New SR-Take User to Activity. Click Activate.
30 3
In the Active Workflow Processes list, query the Name field for New SR-Take User to Activity. One row is returned for every version that is activated.
6 7 8 9
Make sure only the latest version is active. Set the Monitoring Level to 4-Debug. In the Repository Workflow Processes list, click Menu, then choose Reload Runtime Events. Navigate to the Service Request list view.
10 Create a new service request, define a Priority level, then step off the record.
The application delays, displaying an hourglass. Then the Owner, Sub-Status, and Date Committed fields are populated, and a new activity is created that is associated with the new service request. Also, the application automatically navigates the user to the Activities view of the Service Request screen and displays the new activity.
11 Make sure that a process instance exists for New SR Created-Take User to Activity in the
Workflow Process Log view.
304
13 Examples of a Workflow Process Using a Business Service with

This chapter describes examples of using a business service with a workflow process. It includes the following topics: Examples of Using the Server Requests Business Service on page 305 Examples of Using the Outbound Communications Manager Business Service on page 309 Example of Externalizing Properties when Using a Business Service on page 316
Examples of Using the Server Requests Business Service

This topic describes examples of using the Server Requests business service. For more information, see Server Requests Business Service on page 482.
Example of Using the Server Requests Business Service to Start a Workflow Process from a Script
This topic gives one example of how to use the Server Requests business service to start a workflow process from a script and to pass field values to process properties. You might use this business service differently, depending on your business model. The following code can be used: //Example: Passing Field Values to Process Properties and start workflow from script using the Server Request BS //function Invoke_Process() { var svc = TheApplication().GetService("Workflow Process Manager(Server Request)"); var Input = TheApplication().NewPropertySet(); var Output = TheApplication().NewPropertySet(); var bo = TheApplication().ActiveBusObject(); var bc = bo.GetBusComp("Opportunity"); var rowId = bc.GetFieldValue("Id"); var accountId = bc.GetFieldValue("Account Id"); Input.SetProperty("ProcessName", "My Opportunity Process");
30 5
Examples of Using a Business Service with a Workflow Process Examples of Using the Server Requests Business Service
Input.SetProperty("Object Id", rowId); // Pass the value of the Account Id field to the Account Id process property Input.SetProperty("Account Id", accountId); svc.InvokeMethod("RunProcess", Input, Output);
Example of Using the Server Requests Business Service to Call EIM

This topic gives one example of how to use the Server Requests business service from within a workflow process to call EIM. You might use this business service differently, depending on your business model. You can use a workflow process to start a server task. For example, you can start EIM to export base tables to IF tables or to load IF tables into base tables. The required component parameters that are specific for EIM must be passed in a child property set. You can use either a wrapper business service for EIM, such as the Synchronous Assignment Manager Requests business service, or you can use the Server Requests business service. Because the Server Requests business service is designed to call a variety of server tasks, it does not contain definitions for parameters that are specific to a component. Instead, these parameters are passed down in a child property set which are not declared in the repository. To make Siebel Workflow pass values in a child property set, you use the dot notation of [type].[property]. In this example, because the Server Request Manager service does not care about the child type, but uses the first child, you pass every parameter in the same child, such as EIM.Config.
To use the Server Requests business service to call EIM 1

In Siebel Tools, in the Workflow Processes OBLE, define a new workflow process with the values described in the following table. Property Process Name Business Object Workflow Mode Value EIM Export to IF (Tools) Account Service Flow
306
Open the Process Designer for the workflow process you defined in Step 1, then define a workflow that resembles the workflow in the following figure:
Click the Export EIM workflow step, then use the Properties window to define values described in the following table. Property Business Service Name Business Service Method Value Synchronous Server Requests SubmitRequest
4 5
Make sure the Export EIM workflow step is still chosen in the Process Designer. In the MVPW, add a new input argument using values from the following table. Field Input Argument Type Value Value Component Output Argument EIM
Add another input argument to the Export EIM workflow step using values from the following table. Field Input Argument Type Value Value EIM.Config Output Argument accnt.ifb
30 7
Make sure the Server section of the client .cfg file contains the configuration described in the following table. Variable Value
GatewayAddress EnterpriseServer RequestComponent RequestServer 8 9
Gateway_Machine_Name Enterprise_Server_Name SRMSynch Siebel_Server_Name
To prepare the workflow process for testing, set up accnt.ifb in the Siebel_Server\Admin directory. Validate, then simulate the workflow process. For more information, see Process of Testing a Workflow on page 202. If the workflow executes successfully, then it finishes without errors. There is an EIM task log generated in the Server Tasks screen in the Siebel client each time you step through the Process Simulator.
10 Deploy the workflow process.

After the workflow is Active, you can start it from a workflow policy, a script, or as a subprocess from another workflow process. For more information, see Process of Deploying a Workflow Process on page 211.
308
Examples of Using a Business Service with a Workflow Process Examples of Using the Outbound Communications Manager Business Service
Examples of Using the Outbound Communications Manager Business Service

This topic includes the following topics: Example of Defining a Substitution when Using the Outbound Communications Manager on page 309 Example of Using the Outbound Communications Manager to Send an Email to the Owner of a Product Defect on page 310
The Outbound Communications Manager business service can be used to send notifications through fax and email, such as notifications to contacts or employees. For more information on methods and arguments, see Siebel Communications Server Administration Guide.
Example of Defining a Substitution when Using the Outbound Communications Manager

This topic gives one example of how to define a substitution variable when calling the Outbound Communications Manager business service from within a workflow process. You might use this business service differently, depending on your business model.
To define a substitution when using the Outbound Communications Manager 1

In Siebel Tools, define a new workflow process using values from the following table. Property Process Name Workflow Mode Business Object Value Send SR Notification Service Flow Service Request
30 9
Click the Send Notification business service step, then use the Properties window to define values described in the following table. Property Business Service Name Business Service Method Value Outbound Communications Manager SendMessage
4 5
Make sure the Send Notification step is still chosen in the Process Designer. Click the MVPW, then add a new input argument using values from the following table. Input Argument MsgBody Business Component Name Service Request
Type Expression
Value "The Service Request Number" + [SR Number] + "was created with the abstract" + [SR Abstract]
Add another input argument to the Send Notification step using values from the following table. Input Argument CommProfile Type Literal Value (Enter the appropriate profile. The profile must correspond with a profile that is displayed in the Profiles view of the Administration-Communications, All Configurations screen in the Siebel client. Type in the profile name exactly as it is displayed in the client.)
Implement this technique in your production workflow.
Example of Using the Outbound Communications Manager to Send an Email to the Owner of a Product Defect
This topic gives one example of using the Outbound Communications Manager to send an email to the owner of a product defect. You might use this feature differently, depending on your business model.
310
To develop this example, perform the following tasks:
1 2 3
Defining the Custom Recipient Group on page 311 Defining the Product Defect and the Template for the Email Message on page 313 Defining a Workflow Process That Calls the Email Template on page 314
Defining the Custom Recipient Group

You can use the Outbound Communications Manager to send an email to the owner of a product defect. This technique involves setting up a recipient group. To send an email to the owner of a Product Defect by using a workflow process, you begin by defining the custom recipient group for a product defect owner.
To define the custom recipient group for a product defect owner 1 2

In the Siebel client, navigate to the Administration-Data screen, then the List of Values view. Define a new record using values from the following table. Property Type Display Value Language - Independent Code Parent LIC Value COMM_RECIP_SRC Product Defect Product Defect (Leave this field empty.)
Define a second record using values from the following table. Property Type Display Value Language - Independent Code Parent LIC Value COMM_RECIP_SRC Product Defect Owner Comm Employee Product Defect
4 5 6 7
In Siebel Tools, from the application-level menu, choose the View menu, then the Options menu item. Click the Object Explorer tab, expand the Applet tree, make sure the Applet Toggle object type contains a checkmark, then click OK. Navigate to the Applets OBLE, then query the Name column for Comm Source List Applet. From the application-level menu, choose the Edit menu, then the Copy Record menu item.
31 1
Define properties using values from the following table. Property Name Class Value Comm Source Product Defect List Applet CSSFrameListCommSrc
In the Applets OBLE, query the Name column for Comm Source List Applet, right-click the record, then choose Lock Object. Applet Toggles OBLE using values from the following table. Property Applet Value Comm Source Product Defect List Applet
10 In the Object Explorer, expand the Applet tree, click Applet Toggle, then add a new record in the
11 In the Object Explorer, click Link, then add a new record in the Links OBLE using values from the
following table. Property Name Parent Business Component Child Business Component Inter Table Inter Parent Column Inter Child Column Value Comm Request/Product Defect Comm Request Product Defect S_COMM_REQ_SRC COMM_REQ_ID SRC_ROW_ID
Make sure you define properties in the order in which they are listed in the table.
12 Navigate to the Business Objects OBLE, query the Name column for Comm Request, right-click
the record, then choose Lock Object.
13 In the Object Explorer, expand the Business Object tree, click Business Object Component, then
add a new record in the Business Object Components OBLE using values from the following table. Property BusComp Link Value Product Defect Comm Request/Product Defect
The work you performed thus far is required in order to define a custom recipient group for a product defect owner. For more information, see Siebel Communications Server Administration Guide. Next, define the product defect and employee link.
312
Defining the Product Defect and the Template for the Email Message
In this topic, you define the product defect and template for the email message.
To define the product defect and comm employee link 1

In the Object Explorer, click Link, then add a new record in the Links OBLE using values from the following table. Property Name Parent Business Component Child Business Component Source Field Destination Field Value Product Defect/Comm Employee Product Defect Comm Employee Owned By Id Id
2 3
Navigate to the Business Objects OBLE, query the Name column for Product Defect, right-click the record, then choose Lock Object. In the Object Explorer, expand the Business Object tree, click Business Object Component, then add a new record in the Business Object Components OBLE using values from the following table. Property BusComp Link Value Comm Employee Product Defect/Comm Employee
Compile your changes.
Next, define a template that defines the email message that is sent.
To define a template that defines the email message 1 2

In the Siebel client, navigate to the Communications screen, then the My Templates view. Add a new record using values from the following table. Property Name Channel Type Value eMail Notification - Product Defect Email
Click the Advanced view tab, then set the Recipient Group property to Product Defect Owner.
31 3
Define other information in the Advanced form, as required. For a detailed explanation of the available fields, see Siebel Communications Server Administration Guide.
Next, define a test workflow process that calls the template.
Defining a Workflow Process That Calls the Email Template

To finish the configuration, you define a workflow process that calls the email template.
To define a test workflow process that calls the template 1

In Siebel Tools, in the Workflow Processes OBLE, define a new workflow process with the following values: Property Process Name Business Object Workflow Mode Value Email Notification of Product Defect Service Request Service Flow
Open the Process Designer for the workflow process you defined in Step 1, then define a workflow process that resembles the workflow in the following figure:
Click the Call Template step, then use the Properties window to define values described in the following table. Property Business Service Name Business Service Method Value Outbound Communications Manager CreateRequest
Make sure the Call Template step is still chosen in the Process Designer.
314
In the MVPW, define three new input arguments using values from the following table.
Input Argument PackageNameList RecipientGroup RequestName
Type Literal Literal Literal
Value eMail Notification - Product Defect Product Defect Owner Comm Request created by AP Send Updated CR Email
In the MVPW, define one more input argument using values from the following table.
Input Argument SourceIdList
Type Process Property
Value Object Id
7 8
Validate, then simulate the workflow process. For more information, see Process of Testing a Workflow on page 202. Implement this technique in your production workflow.
31 5
Examples of Using a Business Service with a Workflow Process Example of Externalizing Properties when Using a Business Service
Example of Externalizing Properties when Using a Business Service

This topic gives one example of how to externalize properties when using a business service. You might use this technique differently, depending on your business model. This topic includes the following topics: Overview of Externalizing Properties on page 316 Benefits of Using the Externalizing Properties Technique on page 317 Input Arguments of the EAI Business Service on page 317 Example of an XML Hierarchy on page 318 Example of an eScript on page 319 Maintaining the XML File on page 321
The purpose of this example is to provide a technique to externalize properties for Siebel Workflow so that a workflow process that uses a business service that interacts with an external system does not require a repository change when migrating a Siebel instance between development, test, and production environments.
Overview of Externalizing Properties

A workflow process that uses a business service that requires interaction with an external system must be changed when the repository is migrated between development, test, and production environments. An example of this situation is EAI HTTP Transport business service, which requires the URL of the external system for the HTTPRequestURLTemplate input argument. The URL for the workflow that uses the EAI HTTP Transport business service points to the external URL for an integrated test system in the testing instance, and points to the URL for a production external system in the production instance. Consider the following:
1 2
The technique that is used in this example stores, in a file, the input arguments of a business service that are used in a workflow process. A script on the Service_PreInvokeMethod event of the business service step reads, from the file, the values of these substitutable input arguments of the business service that are used in the workflow process. The script can set the Input Argument of the business service using values read from the file.
This technique results in the following: The file that resides on an instance of the production server contains values for the external system that is used for production The file that resides on an instance for the development and test server contains the values for the external system that is used for development and test
Therefore, values for input arguments are not hard coded for the service in the workflow process. Instead, the script on the Service_PreInvokeMethod Event method reads the file at run time.
316
This technique relies on a file that has a particular name, and that is available for reading on each Siebel Server. Otherwise the business service fails and Siebel Workflow throws an error at that business service step, which is the required behavior. For a business service where the script is added to the Service_PreInvokeMethod event, it is expected that an input argument named ExternalSystem is defined, and that the value for the argument matches the XML tag name of the child of the root element in the file. This script sets the child elements of the parent that resides at the second level, that is, the child of the root element, of the file as input arguments.
Benefits of Using the Externalizing Properties Technique

Benefits of using the externalizing properties technique for certain business services include: Makes transparent the migration of repository workflow processes between development, test, and production Siebel instances. That is, workflows no longer require changes during migration between various Siebel instances. Supports current business services as well as future requirements. Supports usage scenarios of a business service that is used in various workflow processes. Is easy to manage and reduces the total cost of ownership of operational aspects of running an instance of the Siebel server.
Input Arguments of the EAI Business Service

The EAI HTTP Transport and EAI SQL Adapter business services, when used in the workflow process as a business service step, contain input arguments that might require changes when migrating the repository between development, test, and production Siebel instances. Table 43 describes potential required changes.
Table 43.
Input Arguments That Might Require Changes when Migrating Repository Data Business Service Methods Send SendReceive Business Service Method Input Arguments HTTPRequestURLTemplate
Business Service EAI HTTP Transport
EAI SQL Adapter
Query
ExtDBODBCDataSource ExtDBPassword ExtDBTableOwner ExtDBUserName
31 7
Assume that an instance of a Siebel server contains integration points with a third party HR and Finance system. To use the EAI HTTP Transport and EAI SQL Adapter business services, the input arguments listed in Table 43 must be supplied in the definition of the business service step for the workflow process where the business service is referenced.
Example of an XML Hierarchy

The following is an arbitrary file for an XML Hierarchy that contains input arguments for the EAI HTTP Transport and EAI SQL Adapter business services, and their values. The parameters under Finance and HR are for illustration purposes only. The file is named ebizint.xml. A number of parameters with appropriate values can be used. For a usage scenario of a business service, parameters that are not required do no harm. Also, this XML Hierarchy is arbitrary. The following hierarchy is for illustration purposes only: <?xml version="1.0" encoding="UTF-8" ?> <Systems> <Finance> <TargetWebAddress>http://finance</TargetWebAddress> <ExtDBODBCDataSource>financesource</ExtDBODBCDataSource> <ExtDBUserName>financeuser</ExtDBUserName> <ExtDBPassword>financepassword</ExtDBPassword> <ExtDBTableOwner>financeowner</ExtDBTableOwner> </Finance> <HR> <TargetWebAddress>http://hr</TargetWebAddress> <ExtDBODBCDataSource>hrsource</ExtDBODBCDataSource> <ExtDBUserName>hruser</ExtDBUserName> <ExtDBPassword>hrpassword</ExtDBPassword> <ExtDBTableOwner>hrowner</ExtDBTableOwner> </HR> </Systems>
318
Example of an eScript
With the structure of the example XML file displayed in Example of an XML Hierarchy on page 318, the following eScript code example can be added to the Service_PreInvokeMethod event of the EAI HTTP Transport and EAI SQL Adapter business services: function Service_PreInvokeMethod (MethodName, Inputs, Outputs) { var ExtSystem, XMLReadSvc, XMLReadSvcInputs, XMLReadSvcOutputs; var ExtSystemParent, Child var errorStr;
try { XMLReadSvcInputs = TheApplication () .NewPropertySet (); XMLReadSvcOutputs = TheApplication () .NewPropertySet (); XMLReadSvcInputs.SetProperty("FileName, C:\\ebizint.xml); XMLReadSvcInputs.SetProperty("EscapeNames, false); XMLReadSvc = TheApplication () .GetService ("EAI XML Read from File); ExtSystem = inputs.GetProperty (ExternalSystem); XMLReadSvc.InvokeMethod(ReadXMLHier, XMLReadSvcInputs, XMLReadSvcOutputs);
//ExtSystem = {HR, Finance, HRSensitive} ExtSystemParent = XMLReadSvcOutputs.GetChild(0) .GetChild(0); for (var i =0; i < ExtSystemParent.GetChildCount(); i++) { Child = ExtSystemParent.GetChild(i); if (Child.GetType() == ExtSystem) { for (var j=0; j < Child.GetChildCount(); j++) { var ExtType = Child.GetChild(j) .GetType(); var ExtValue = Child.GetChild(j) .GetValue();
31 9
Inputs.SetProperty (ExtType, ExtValue); } } } } catch (e) { errorStr = e.toString(); TheApplication () .Trace(errorStr); TheApplication () .RaiseErrorText(errorStr); return (CancelOperation); } finally { ExtSystem = null; XMLReadSvc = null; XMLReadSvcInputs = null; XMLReadSvcOutputs = null; ExtSystemParent = null; Child = null; errorStr = null; } return (ContinueOperation); }
320
Figure 22 displays an example usage of the EAI HTTP Transport business service, which includes the eScript code described in this topic that is defined in the Service_PreInvokeMethod event.
Figure 22. Example Usage of EAI HTTP Transport Business Service
Maintaining the XML File

There is no other ongoing maintenance required for ebizint.xml. If the values in the file change, then this file must be updated with the correct values on the Siebel Servers. An example change that requires an update to ebizint.xml is a change to the URL that points to the external system.
32 1
322
14 Defining a Custom Workflow Policy

This chapter describes workflow policies. It includes the following topics: About Workflow Policies on page 323 Process of Planning a Workflow Policy on page 332 Process of Defining a Workflow Policy on page 340 Examples of Defining Workflow Policy Configurations on page 349 Customizing Workflow Policy Objects on page 360 Conditions for a Workflow Policy on page 370
For more information, see Chapter 16, Administering a Workflow Policy and Appendix A, Reference Materials for Siebel Workflow.
About Workflow Policies

This topic includes the following topics: Overview of Workflow Policy Objects on page 323 Structure of a Workflow Policy on page 327 Sequence of a Workflow Policy on page 330 Hierarchy of Workflow Policy Objects on page 331
You can use a workflow policy to start a workflow process. A policy consists of one or more workflow policy conditions. If the workflow policy conditions are met, then the workflow policy action is executed. NOTE: The name Workflow Policies replaces the name Workflow Manager, which was used to refer to the Siebel Business Process automation tool in earlier releases.
Overview of Workflow Policy Objects

Workflow policy objects provide the context in which Workflow Policies operate. The workflow policy object, through the policy components for the workflow process, defines the set of tables and columns that are monitored by a policy 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 within Siebel Tools that you must monitor.
32 3
Defining a Custom Workflow Policy About Workflow Policies
Siebel Tools provides visibility to many predefined workflow policy objects for common business requirements, such as opportunity, service request, and contact. You can modify some predefined workflow policy objects through administrative screens in the Siebel client. You can also use Tools to define a custom workflow policy object in order to meet your specific business requirement.
Relations Between Objects of a Workflow Policy

Relations between workflow policy objects, workflow policy columns, and workflow policy programs are illustrated in Figure 23.
Figure 23. Relations Between Workflow Policy Objects, Programs, and Columns Relations between workflow policy objects include:
Workflow Policy Object. A workflow policy object is a collection of workflow policy components. A workflow policy object is defined by the parent and child relationship for the workflow policy object to workflow policy components and workflow policy component columns.
324
Workflow Policy Component. A workflow policy component is a logical mapping of a database table that defines the Siebel database tables that you can monitor. Workflow policy components define the relations between the primary workflow policy component and other 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. This relation is defined by defining a source policy column and a target policy column. The source and target columns on 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. From these workflow policy components, the workflow policy columns that are available for monitoring in the workflow policy can be defined. 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 you can monitor. You expose these columns for monitoring when you define workflow policy conditions for a workflow policy.
To define a workflow policy object and the components for a workflow process, familiarize yourself with the Siebel Data Model. For more information, see Siebel Data Model Reference. For information about tables and how tables are related, see Siebel Data Model Reference.
Viewing the Hierarchy 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 on page 331.
32 5
Example of an Entity Relationship Diagram for a Workflow Policy

Figure 24 displays the entity relationship diagram of four workflow policy components for a service request. The diagram 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, and the other three components are joined to it either directly or indirectly.
Figure 24. Example of an Entity Relationship Diagram for a Workflow Policy
Table Monitoring with a Workflow Policy

A workflow policy can only monitor Siebel database tables. You cannot use a workflow policy to monitor a database table that is external to Siebel. CAUTION: Do not monitor the S_DOCK_TXN_LOG table or table columns of Enterprise Integration Manager (EIM). An EIM table is prefixed with EIM_, or ends with _IF. Most tables can be monitored except S_DOCK_TXN_LOG and EIM tables.
326
Structure of a Workflow Policy

A rule contains an IF/THEN structure that provides the basic underlying logic of a workflow policy. The structure of a rule is: If the conditions are true, then an action occurs The rule contains a workflow policy condition and a workflow policy action. If the conditions of the workflow policy are met, then an action is called. Figure 25 illustrates the parts of an example workflow policy.
Figure 25. Parts of an Example of a Workflow Policy Parts that make up a typical workflow policy include:
Workflow Policy. A workflow policy is composed of workflow policy conditions and workflow policy actions. A workflow policy, based on the structure of the workflow policies rule, represents rules that the database monitors. Workflow Policy Condition. A workflow policy condition is called: a situation that causes something to happen. Workflow Policy Action. A workflow policy action is an action that is called by fulfilling a workflow policy condition. Workflow Policy Program. A workflow policy program is a predefined program that provides arguments for the workflow policy action. Duration. A duration is the amount of time for which workflow policy conditions exist in order for the conditions of the policy to be met. For more information, see Planning the Workflow Policy and Workflow Policy Conditions on page 334.
2 3 4 5
NOTE: The functionality that is available with a workflow policy can be supported by using a workflow process. It is recommended that a workflow policy be used to start a workflow process. Use a workflow process to define an action.
32 7
Workflow Policy Condition

A workflow policy condition is an object that expresses an object or the relation of an attribute to a value. For example, a workflow policy condition can target data, such as severity for a service request. The workflow policy condition compares severity data to a value, such as 1-Critical. The combination of the data element, service request severity, a comparison operation, such as the equal sign (=), and the value, such as 1-Critical, define the condition. The fact that severity of a service request is 1-Critical can be an issue only if the workflow policy condition remains valid for some extended amount of time, such as two hours. In this example, if the condition remains valid, then a duration can be set for two hours on the workflow policy. The duration is part of the condition. The policy actions are not executed until the conditions are met for the defined duration. A workflow policy action can also occur when a time duration is not set. For example, where email is automatically sent 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 frequently contains more than one workflow policy condition. The conditions of the workflow policy must be met before an action can occur. A service request with a severity of 1-High and a duration of two hours 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 these two comparison operations: SR Severity = 1-Critical AND SR Status = Open A workflow policy only supports an AND linkage between workflow policy conditions. It does not support an OR linkage. If you must monitor the service request severity to be 1-Critical or 2-High and the status to be Open, then you can use the IN operand to evaluate the OR of the severity: SR Severity IN (1-Critical, 2-High) AND SR Status = Open Alternatively, an OR linkage can be simulated by defining multiple workflow policies for each key workflow policy condition. The combination of workflow policies act similar to an OR linkage. For more information, see Examples of Defining Workflow Policy Configurations on page 349.
Workflow Policy Action

A workflow policy action is an event that occurs when the conditions of your workflow policy are met. The parts of a workflow policy action include: 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 is transmitted with the page
You can define several 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 on page 360. NOTE: In most cases, you can use a workflow policy action to start a workflow process. You can pass a constant from a workflow policy action into a workflow process. For more information, see Passing a Constant from a Workflow Policy Action into a Workflow Process on page 183.
328
Workflow Policy Program

A workflow policy program is a predefined program that provides arguments for the workflow policy action. A workflow policy action is based on the underlying program in Siebel Tools and inherits the arguments for the program. A workflow policy program defines the particular action that executes when the conditions of a workflow policy are met. Most functionality included in a workflow policy program can be executed by using a workflow process. You can use a workflow policy program in multiple actions and you can use actions in multiple workflow policies. Types of workflow policy programs include: 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 data records of a Siebel database table for chosen workflow policy components. External Program. Allows you to run an executable. Assignment Request. For internal use only. Generic Request Server. Submits a server request to a designated server component.
For more information, see Properties of the Workflow Policy Program on page 475 and Properties of the Workflow Policy Program Argument on page 476.
Predefined Workflow Policy Programs Workflow policies use workflow policy actions that are based on workflow policy programs that are predefined in Siebel Tools. Some examples include: Send Broadcast Message Database Operation
For more information, see Types of Workflow Policy Programs That Are Predefined on page 381.
32 9
Sequence of a Workflow Policy

A sequence of a typical workflow policy is illustrated in Figure 26.
Figure 26. Sequence of a Typical Workflow Policy A sequence of a typical workflow policy includes the following steps:
1 2
Detect End-User Activity or Server Process. An end-user activity or server process occurs. Create Triggers. Workflow policies are enforced at the data layer through database triggers. If the conditions for a particular workflow policy are met, then the underlying database triggers capture the database event into Workflow Policy Manager. Fire Triggers. The S_ESCL_REQ table is queued. Read Records. The Workflow Monitor Agent, which is a component of the Workflow Policy Manager, reads records in the S_ESCL_REQ table, then processes requests by executing the actions that are defined. Start. In some cases, an action can start the Workflow Process Manager.
3 4
Workflow Policy Manager provides scalability by using an additional component named Workflow Action Agent, which can be executed on a different application server within the Siebel Enterprise. For more information about: Workflow Action Agent, see Executing a Workflow Policy with the Workflow Action Agent on page 415 Generate Triggers, Workflow Process Manager and Workflow Monitor Agent, see Run-Time Architecture of a Workflow Process on page 31 The S_ESCL_REQ table, see Usage of the S_ESCL_REQ Table on page 408
330
Hierarchy of Workflow Policy Objects

Using Siebel Tools, you can modify an existing workflow policy and define a new workflow policy to meet your business requirements. Figure 27 highlights the object types you can modify and the hierarchies that exist between them.
Figure 27. Workflow Policy Object Type Hierarchy in the Object Explorer in Siebel Tools Items to consider include: If necessary, you must expose workflow policy objects in the Object Explorer. For more information, see Exposing Object Types That Are Used to Develop a Workflow Process on page 116. When you use Siebel Tools to modify or define a workflow policy object on your local system, the changes are not available on the server until after they are applied to the server.
For more information about hierarchies in the Object Explorer, and for background information about object types, object definitions, and properties, see About the Object Hierarchy of a Workflow Process on page 39.
33 1
Defining a Custom Workflow Policy Process of Planning a Workflow Policy
Process of Planning a Workflow Policy

This topic describes information about planning a workflow policy. To plan a workflow policy, perform the following tasks:
1 2 3 4 5 6 7
Planning a Workflow Policy Group on page 332 Planning a Workflow Policy on page 333 Planning Objects to Monitor with a Workflow Policy on page 334 Planning the Workflow Policy and Workflow Policy Conditions on page 334 Planning the Workflow Policy Action on page 335 Examining Workflow Policies and Workflow Policy Programs That Are Predefined on page 335 Planning a Test and Migration Strategy for a Workflow Policy on page 336
Examples in this topic ground the concepts presented. For more information, see Examples of Planning a Workflow Policy on page 336. Before planning a workflow policy, you must determine the automation solution that most closely meets the automation requirements for your business . For more information, see Identifying an Automation Solution on page 101.
Planning a Workflow Policy Group

This task is a step in Process of Planning a Workflow Policy on page 332. Workflow policies are organized into groups. A workflow policy group is a collection of workflow policies that provide a means of identifying policies that contain similar system requirements, thus facilitating load balancing on the servers and scalability. A workflow policy group allows you to manage and optimize process performance for the Workflow Agent by grouping similar policies to run under one Workflow Agent process. Before you define a workflow policy, you must define a workflow policy group. Each Workflow Policy Agent is assigned to one workflow policy group. If you run only one Workflow Policy Monitor Agent and one Workflow Policy Action Agent, then assign your policies to one policy group. Reasons to use multiple Workflow Policy Agents include: To shorten the lag time between when the policy event is called and when Workflow Policies notices the event To spread the workload across multiple application servers To adjust the polling interval so that polling for a noncritical policy does not prevent efficient processing of a critical policy
Policies with similar time intervals are generally grouped together. By defining groups of policies with similar time intervals, you can assign the workflow policy group to a Workflow Policy Agent that contains a polling rate that matches the requirements of the workflow policies, thereby more efficiently using your resources.
332
Defining workflow policy groups and using multiple Workflow Policy Agents are part of tuning your system in order to realize higher performance. This work can be performed while you monitor system performance. NOTE: The maximum number of policies in a single policy group is MaxInt. The maximum number of policies in policy groups is determined by the maximum number of records in the S_ESCL_RULE table.
Planning a Workflow Policy

This task is a step in Process of Planning a Workflow Policy on page 332. Many of the workflow policy objects and programs you must define for your workflow policies come predefined. However, you can use Siebel Tools to augment programs, define more workflow policy objects, or 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 determine the work that can be automated with a workflow policy, then prioritize the implementation sequence. For more information, see: Process of Defining a Workflow Policy on page 340 Customizing Workflow Policy Objects on page 360
Technique for Grouping Policies

It is recommended that you define and implement a small group of 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 necessitates changes to your plan, then a workflow policy can be assigned to a different group. For more information, see Moving a Workflow Policy to a Different Group on page 431.
Technique for Testing a Policy

After planning a new workflow policy, you can test the policy by issuing a query that is based on the policy. Then you can execute the query in your current production environment. The query response can help you determine the frequency of the workflow policy conditions. You might find that a policy generates excessive notification or insufficient visibility. For more information, see Testing, Troubleshooting, and Migrating a Workflow Policy on page 440.
33 3
Planning Objects to Monitor with a Workflow Policy

This task is a step in Process of Planning a Workflow Policy on page 332. You can develop a plan for what objects to monitor. For example, assume the service department must send an email to the contact for the service request when a service request is opened that contains a severity level of critical. Table 44 describes the information to monitor in this example.
Table 44.
Example of Objects to Monitor Purpose of the Policy Send an email to the contact of the service request when the service request is opened and the severity level for the service request is critical.
What to Monitor Service request status Service request severity
Planning the Workflow Policy and Workflow Policy Conditions

This task is a step in Process of Planning a Workflow Policy on page 332. Develop a plan for the properties of the workflow policy and workflow policy conditions, identify the workflow policy object to be monitored in the Siebel database, and determine the period and duration for the monitoring interval. Table 45 describes an example plan that details the type of information to model for the workflow policy.
Table 45. Name
Example of a Plan for the Workflow Policy Workflow Policy Object Service Request Workflow Policy Group Medium Frequency This value establishes the interval period for monitoring. Duration 0 (zero) Duration indicates the time that must elapse before an action is performed. Each workflow policy includes one duration. If you require an action to occur after one hour, two hours, and six hours, then you must define a different policy for each duration.
Email Confirmation of SR
334
Table 46 describes an example plan for the workflow policy conditions that is identified after you determine the workflow object and other properties for your workflow policy.
Table 46.
Example of a Plan for the Workflow Policy Conditions Operation = = Value 1-Critical Open
Field in the Workflow Policy Condition Service Request Severity Service Request Status
The condition of a workflow policy includes an expression. The Condition Field is the table column that is monitored in the database. A value for the condition of a workflow policy is read directly from a picklist that is defined at the table column level. The value that is required by the operation for the condition that you define, such as IN and NOT IN, must be available in the column policy picklist. Otherwise, the workflow policy cannot call the workflow policy action.
Planning the Workflow Policy Action

This task is a step in Process of Planning a Workflow Policy on page 332. An action of a workflow policy is executed when the conditions of the workflow policy are met. Workflow Policies come with a set of predefined actions. You can use these actions or define your own actions in order to suit your business requirements. Table 47 describes an example plan that details the type of information you must define for a workflow policy action.
Table 47.
Example of a Plan for the Workflow Policy Actions Workflow Policy Program Send SR Email Workflow Policy Object Service Request Arguments Send to Contact
Action Name Send SR Email to Contact
Examining Workflow Policies and Workflow Policy Programs That Are Predefined
This task is a step in Process of Planning a Workflow Policy on page 332. Workflow Policies comes with a number of predefined workflow policies and policy programs. Before you define a new workflow policy, you can examine the predefined policies to determine if a policy already exists that meets your business requirements. This way, you can modify existing, predefined objects rather than defining new objects. For more information, see Types of Workflow Policy Programs That Are Predefined on page 381 and Properties of Workflow Policies on page 470.
33 5
Planning a Test and Migration Strategy for a Workflow Policy

This task is a step in Process of Planning a Workflow Policy on page 332. Before you implement a new workflow policy, you must make sure that it works properly in a test environment. The environment can consist of 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 into the production environment properly executes and does not cause a conflict with an existing workflow policy.
Guidelines for Setting up Your Test and Migration Strategy

Guidelines for setting up your test and migration strategy include: Make sure your test environment and production environment contain identical versions of the software and that you are using realistic data in your database by using a partial or full copy of the production database. Define a small group of workflow policies to implement as a first phase of implementation. After you successfully implement the first group, you can add more policies in a systematic manner. To test a new workflow policy, in your production environment, manually issue a query that is based on the new policy, then check the response. This technique helps you determine if a workflow policy generates excessive notification or misses the rows you must monitor.
For more information, see Migrating Workflow Policies to the Production Environment on page 443.
Examples of Planning a Workflow Policy

This topic describes examples you can examine in order to plan a workflow policy. It includes the following topics: Example of Planning a Workflow Policy That Sends a Discount Notice on page 336 Example of Planning a Workflow Policy That Sends a Notice of An Open Service Request on page 338
Example of Planning a Workflow Policy That Sends a Discount Notice

This topic gives one example of planning a workflow policy. You might use this feature differently, depending on your business model. In this example, the sales department manager must be automatically notified when a sales representative quotes a discount that is greater than 30%.
336
To plan a workflow policy that sends a discount notice 1

Determine what to monitor. The following table describes information the workflow policy must monitor.
What to Monitor A quote that contains a discount that is greater than 30% requires Sales Manager approval.
Purpose of the Policy Notify Sales Manager to review and approve the quote.
Plan the workflow policy action. The following table describes values on which the workflow policy action is based.
Name Notify Sales Manager upon Sales Approval
Workflow Policy Object Quote
Workflow Policy Group Low Frequency
Duration 0
Quantity 5
Description Notify the manager when a quote with a discount that is greater than 30% is created.
Plan the workflow policy conditions. The following table describes the type of information that is required for the workflow policy conditions.
Field (Column Monitored in the Database) Quote Status Quote Item Discount Percent
Comparison = >
Value In Progress 30
33 7
Plan the workflow policy actions that occur when the conditions of the policy are met. You can also define the action arguments, such as the email subject and the message template, by using dynamic values. The following table describes the Send Email to Sales Manager action.
Action Name Send Email to Sales Manager
Workflow Policy Program Send Quote Email
Workflow Policy Object Quote
Arguments and Substitutions 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]
Example of Planning a Workflow Policy That Sends a Notice of An Open Service Request
This topic gives one example of planning a workflow policy. You might use this feature differently, depending on your business model. In this example, the service department must automate a notification policy when the number of open service requests for a service representative reaches 20.
To plan a workflow policy that sends a notice of an open service request 1

Determine what to monitor. The following table describes a plan for the definition of the general policy.
What to Monitor? Monitor open service requests when they reach a quantity of 20.
Purpose of the Policy Use Send Broadcast Message to alert the service representative about the situation.
Plan the workflow policy action. The following table describes a plan for the policy action.
Name Over 20 Open Service Requests
Workflow Policy Object Service Request
Workflow Policy Group High Frequency
Quantity 20
338
Plan the workflow policy conditions. After you determine the workflow object and other properties for the workflow policy, define the workflow policy conditions. The following table describes a plan for the conditions.
Field (Column Monitored in the Database) Service Request Status
Comparison =
Value Open
Plan the workflow policy actions that occur when the conditions of the policy are met. You can also define the action arguments. The following table describes a plan for the argument of the action.
Action Name Alert Representative of Open SR
Workflow Policy Program Send SR Message Broadcast
Workflow Policy Object Service Request
Arguments and Substitutions Abstract: You own over 20 service requests Message Template: You own over 20 service requests. Please review the queue for your service requests.
33 9
Defining a Custom Workflow Policy Process of Defining a Workflow Policy
Process of Defining a Workflow Policy

To define a workflow policy, perform the following tasks:
1 2 3
Defining a Workflow Policy Group on page 340 Defining a Workflow Policy Action on page 341 Defining a Workflow Policy on page 346
For more information, see: About Workflow Policies on page 323 Examples of Defining Workflow Policy Configurations on page 349 Customizing Workflow Policy Objects on page 360 Types of Workflow Policy Programs That Are Predefined on page 381
Defining a Workflow Policy Group

This task is a step in Process of Defining a Workflow Policy on page 340. To define a workflow policy, you begin by defining a workflow policy group. For more information, see Planning a Workflow Policy Group on page 332.
To define a workflow policy group 1 2 3

In the Siebel client, navigate to the Administration-Business Process screen, then the Policy Groups view. From the drop-down menu in the Policy Groups list, choose New Record. 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 be no more than 30 characters in length.
(Optional) Enter comments in the Comments field. Define comments that describe the purpose or use of the policy group.
340
In the Policies list, click New, then define fields using values from the following table. Field Name Object Usage Define the name of the workflow policy that is included in the workflow policy group. 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 the workflow policy is activated. If this field is null, then the workflow policy is activated immediately. NOTE: It is recommended that each workflow policy group contain policies that are monitored within a similar time interval. 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.
Repeat 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 on page 431.
Defining a Workflow Policy Action

This task is a step in Process of Defining a Workflow Policy on page 340. You must define the workflow policy action before you define the workflow policy that uses the action.
34 1
To define a workflow policy action 1 2

In the Siebel client, navigate to the Administration-Business Process screen, then the Actions view. In the Actions list, click New Record from the applet level menu, then define fields using values from the following table. Field Name Description Define the name of the workflow policy action. The name is displayed in the Actions Applet of the Workflow Policies view. Program Define the workflow policy program that is associated with the action. Value Enter a descriptive name that is consistent with your overall naming strategy and meaningful to the policy maker. You choose this program from a picklist. For more information, see Types of Workflow Policy Programs That Are Predefined on page 381. Chosen from a picklist of workflow policy objects.
Workflow Object
Define the workflow policy object with which this action is associated. If you define a workflow policy object, then this action is displayed only on the Actions Applet of the Workflow Policies view for workflow policies that are associated with this workflow policy object. Define comments that describe the purpose or use of this workflow policy action.
Comments
Enter comments text.
In the Arguments list, define each argument, as necessary. The Arguments list changes based on the Program you choose in the Actions list in Step 2. For more information, see Arguments List on page 344.
342
(Conditional) In the Recipients list, define a recipient using values from the following table. Field Type Description Choices available from the picklist include: 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 Send to Relative Recipient Type on page 345. Send to Address. Allows you to manually enter an email address. Used to support a program that sends email.
Name
Define the Name of the recipient based on the value you pick for the Type field. The message is sent based on position. If choosing an employee as the recipient, and if multiple employees occupy the same position, then the message is sent to every employee, even though you only choose one employee as the recipient.
You only use the Recipients list when you choose certain programs in the Actions list in Step 2. For more information, see Recipients List on page 345.
(Optional) Repeat Step 2 to add additional recipients, as necessary.
34 3
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. Instead, use a workflow process to call a DLL or external function. You cannot call a business service from a workflow policy action.
Insert Operation Usage with a Workflow Policy Action An insert operation with a workflow policy action cannot populate the Primary Owner. For example, you cannot modify a Workflow Policy Program, such as Create SR Activity, to populate Primary Activity Owner, OWNER_PER_ID, because the intersection table, S_ACT_EMP, must also be populated. Because the same Workflow Policy Program cannot update two tables within one database operation, Workflow Process must be used to populate OWNER_PER_ID. Earlier versions, such as Siebel CRM version 6, can support this technique because an Activity can be assigned to only one employee. However, in later versions, such as Siebel version 7.x, an Activity can be assigned to multiple employees.
Arguments List
The Arguments list is context sensitive. A different applet is displayed based 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 the Send Message Broadcast Arguments list displays. If you choose Send Email in the Program field of the Actions list, then the Send Message Arguments form displays.
Items to consider when using the Arguments form include: A program argument is case sensitive. You must use the correct case. Use the picklists in the Arguments form when possible instead of entering the arguments manually. Before using email or paging, you must perform the setup procedures described in Administering a Workflow Policy on page 401. If the workflow policy program is Send Email, Send Page, or Send Broadcast Message, then use the Recipient list to enter the recipients of the action.
For a description of each workflow policy program type, the available workflow policy program arguments, and valid values, see Types of Workflow Policy Programs That Are Predefined on page 381.
344
Applets Refresh Automatically The applets that are displayed 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, when you navigate to the Administration-Business Process screen, then the Policies view, the following applets are displayed: Policies List, Conditions, Actions, Arguments. If you choose Send Page to Opportunity Sales Rep in the Action field of the Actions list, then the Arguments list is automatically replaced with the Send Page Arguments form.
Recipients List
You only use the Recipients list when you choose Send Email, Send Page, or Send Message Broadcast in the Program field of the Actions list.
Send to Relative Recipient Type The Send to Relative recipient type sends an email or page to an individual or 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 are based on the Workflow Object you choose in the Actions list. Send to Relative is also used when you must define a custom Send to [xxxx] recipient. Because you must use one of the Recipient Type choices in the picklist, you use Send to Relative to define a custom recipient type. The Recipient Type choices are Send to Employee, Position, Contact, or Relative. Email Manager does not send email to the same recipient twice for the same action. If it detects that an email was sent to a specific email address, then another message is not sent. If the Send to Relative type returns more than one recipient, then each recipient is sent an email as long as each email address is unique.
Sending an Email to Multiple Relative Recipients A workflow policy can be defined so that the same email message is sent to a number of different relative recipients.
To send an email to multiple relative recipients 1 2 3 4

Define an action for the policy program. In the Recipients list, add a new record, set the Type field to Send to Relative, then pick the name of the first recipient in the Name field. Repeat Step 2 for each additional recipient, updating the Name field for each recipient. Associate the action with the workflow policy.
34 5
Defining a Workflow Policy

This task is a step in Process of Defining a Workflow Policy on page 340. After you define your workflow policy group and workflow policy action, you can use the Workflow Policies view to define the workflow policy. For more information, see Examples of Defining a Workflow Policy on page 357.
To define a workflow policy 1 2

In the Siebel client, navigate to the Administration-Business Process screen, then the Policies view. In the list for the Policies List, choose New Record from the applet level menu, then define fields using values from the following table. Field Name Workflow Object Description Define the name of the workflow policy. Define the workflow policy object for which the policy was defined. Define the workflow policy group to which the policy belongs. Explanation Not applicable For example, Service Request, Activity, or Accounts. This field is required. Each workflow policy must be assigned to a workflow policy group. For more information, see Moving a Workflow Policy to a Different Group on page 431. If this field is null, then the workflow policy is activated immediately. If this field is null, then the workflow policy is active indefinitely. If the workflow policy is run in batch, then this field is ignored.
Policy Group
Activation Expiration Duration
Define the date and time that the policy is activated. Define the date and time that the policy expires. Define the duration fields in days, hours, or minutes that the workflow policy conditions must be true in order for the workflow policy to be executed.
346
Field Qty
Description Define the number of records that meet the workflow policy conditions before the workflow policy action executes.
Explanation If you do not define a quantity, then Siebel Workflow assumes a quantity of 1. Qty allows you to define a workflow policy condition that is based on the number of records that meet the condition. For example, you can define a policy that sends a broadcast message when 20 or more critical service requests are open. The Workflow Monitor Agent scans records by using the conditions of the policy in order to find the matches. If this field is checked, then run Workflow Monitor Agent with the Batch Mode flag set to TRUE. The default is unchecked.
Batch Mode
Define, by checking Batch, that this workflow policy evaluates records that potentially meet the conditions of the workflow policy.
In the Conditions list, choose New Record from the applet level menu, then define fields using values from the following table. Field Condition Field Usage Define the workflow policy component column in the workflow policy object on which the workflow policy condition is based. Values that appear in the Condition Field are context sensitive, depending on the value you choose for Workflow Object in Step 2. NOTE: For a workflow policy to be called that contains a Condition Field <> [Value n], a value must be defined in this field other than the value that is defined in the workflow policy condition. If there is no value, then the workflow policy is not called. The Operator IS NULL is used in this case. Example Choose Service Request Area from the picklist.
34 7
Field Operation
Usage Define the comparison to make between the value of the column for a workflow policy agent and the value you define. Choose the comparison from the picklist for the field. For more information, see Examples of Defining Workflow Policy Configurations on page 349.
Example Choose equals (=) from the picklist.
Value
Define the value to compare to the column of the instance of the workflow policy. Value is a required field except when the Comparison field contains a value of Is Null, Is Not Null, Is Updated, Is Deleted, or Is Added. For more information, see Examples of Defining Workflow Policy Configurations on page 349, and Date Calculations in the Conditions List on page 375.
Choose Printer from the picklist.
In the Actions list, choose New Record from the applet level menu, then define fields using values from the following table. Field Action Sequence Consolidate Usage Pick the action that is executed with this workflow policy. Define the sequence of the action relative to other actions. If more than one record meets the conditions of the workflow policy 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 checkmark. The consolidate flag is not available with an action that sends a page.
(Optional). Repeat Step 4 to add additional actions, as necessary.
Restrictions with Defining a Workflow Policy

Restrictions with defining a workflow policy include: A workflow policy cannot be based on the S_DOCK_TXN_LOG table. The unique index for this table is TXN_ID, rather than the ROW_ID that is used with other standard Siebel tables. Because Siebel Workflow uses ROW_ID to do the comparison and execute actions, it errors out if used against the S_DOCK_TXN_LOG table. You cannot execute a business service from a workflow policy. A workflow policy updates a database field directly through the Data Layer, and does not update through the Business Object Layer. Therefore, a workflow process that includes a business component event that is related to the updated field is not executed.
348
Defining a Custom Workflow Policy Examples of Defining Workflow Policy Configurations
Examples of Defining Workflow Policy Configurations

This topic describes example configurations for workflow policy actions and workflow policies. It includes the following topics: Examples of Defining a Workflow Policy Action on page 349 Examples of Defining a Workflow Policy on page 357
Examples of Defining a Workflow Policy Action

This topic describes examples that use a workflow policy action in order to address a specific business requirement. It includes the following topics: Example of Defining a Workflow Policy Action That Sends a Page on page 349 Example of Defining a Workflow Policy Action That Sends an Email with a Repeating Message on page 351 Example of Defining a Workflow Policy Action That Sends a Broadcast Message on page 352 Example of Defining a Workflow Policy Action That Executes a Database Operation on page 354 Example of Defining a Workflow Policy Action That Runs an External Program on page 354
You can use these examples as the basis for defining your own workflow policy actions.
Example of Defining a Workflow Policy Action That Sends a Page

This topic gives one example of using a workflow policy action to send a page. You might use this feature differently, depending on your business model. A page can be sent to the support manager when the priority for a service request is very high and the service request is not assigned to anyone. Use the procedure in this topic to define a workflow policy action that addresses this situation.
To define a workflow policy action that sends a page 1

In the Siebel client, navigate to the Administration-Business Process screen, then the Actions view.
34 9
In the Actions list, define a new record using values from the following table. Field Name Program Workflow Object Value Page Support Manager when SR request changes. Send SR Page Service Request
If a workflow policy object is defined in the workflow policy Program field, then the Workflow Object field automatically populates. You choose a workflow policy object from the picklist when it does not automatically populate.
In the Send Page Arguments form, define the argument using values from the following table. Field Alpha Message Template Value 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 type of paging to use is indicated by the pager type in the employee table. You can copy and paste fields that are available from the Available Substitutions window.
In the Recipients list, define a new record using values from the following table. Field Type Name Value Send to Position Support Manager
This action is now available to use in a workflow policy.
5 6
Navigate to the Administration-Business Process screen, then the Policies view. Query the Workflow Object field for Service Request. This query returns a list of policies where the action you just defined can most appropriately be used.
7 8 9
In the Name column, choose a Workflow policy, such as Page SR Owner (Gold). In the Actions list, define a new record, then locate Page Support Manager when SR request changes, which is the action you just defined. Examine the Send Page Arguments form. The Send Page Arguments form populates with values that you defined in this procedure.
350
Example of Defining a Workflow Policy Action That Sends an Email with a Repeating Message
This topic gives one example of using a workflow policy action to send an email with a repeating message. You might use this feature differently, depending on your business model. In this example, the vice president of sales must be notified only after a specific number of deals fail to close. Because this action is used with a workflow policy that uses the Batch feature, you enter relevant information in the Repeating Message field of the Send Message Arguments form. Using this technique makes sure that the recipient receives one email with a consolidated list of the pertinent information on each of the deals. Without a Repeating Message, the email is sent but might not contain meaningful information.
To define a workflow policy action that sends an email with a repeating message 1 2
In the Siebel client, navigate to the Administration-Business Process screen, then the Actions view. In the Actions list, define a new record using values from the following table. Field Name Program Workflow Object Comment Value Excellent Quality Opportunity Send Opportunity Email Opportunity Send an email to the VP of Sales when deals are not closing.
In the Send Message Arguments form, define the argument using values from the following table. Field Subject Message Template Repeating Message Value Opportunities not Closing Meet with [Last User First Name] [Last User Last Name] about [Opportunity] for [Account] Meet with [Last User First Name] [Last User Last Name] about [Opportunity] for [Account]
In the Recipients list, define a new record using values from the following table. Field Type Name Value Send to Position VP Sales
This action is now available for use in a workflow policy.
Navigate to the Administration-Business Process screen, then the Policies view.
35 1
Query the Workflow Object field for Opportunity. This step returns a list of policies where the action you just defined can most appropriately be used.
7 8 9
In the Name column, choose a Workflow policy, such as New Opportunity. In the Actions list, define a new record, then locate Excellent Quality Opportunity, which is the action you just defined. Examine the Send Page Arguments form. The Send Page Arguments form populates with values you defined in this procedure.
10 In the list for the Policies List, make sure the Batch Mode field contains a check mark.
Example of Defining a Workflow Policy Action That Sends a Broadcast Message

This topic gives one example of using a workflow policy action to send a broadcast message. You might use this feature differently, depending on your business model. 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 define a workflow policy action that sends a broadcast message 1 2

In the Siebel client, navigate to the Administration-Business Process screen, then the Actions view. In the Actions list, define a new record using values from the following table. Field Name Program Workflow Object Value Alert Representative of Open SRs Send SR Message Broadcast Service Request
In the Send Message Broadcast Arguments form, define the argument using values from the following table. Field Abstract Message Template Value You own over 20 Service Requests. You own over 20 service requests. Please review your service request queue.
352
In the Recipients list, define a new record using values from the following table. Field Type Name Value Send to Relative SR Owner
This action is now available for use in a workflow policy. For instructions on how to add an action to a workflow policy, see Example of Defining a Workflow Policy Action That Sends a Page on page 349.
35 3
Example of Defining a Workflow Policy Action That Executes a Database Operation

This topic gives one example of using a workflow policy action to execute a database operation. You might use this feature differently, depending on your business model. Insert and update are the two kinds of database operations that are possible with workflow policies. Insert allows a record to be inserted into a table in the Siebel database. The update database operation allows one or more columns in an existing record to be changed. In the following example, a database update occurs when you use workflow policies to update the value of the Priority field to Very High if the Severity is Critical.
To define a workflow policy action that executes a database operation 1 2

In the Siebel client, navigate to the Administration-Business Process screen, then the Actions view. In the Actions list, define a new record using values from the following table. Field Name Program Workflow Object Value Update SR Priority to Very High Change SR Priority Service Request
In the Arguments form, define the argument using values from the following table. Field Name Value Value New Priority 1-ASAP
Example of Defining a Workflow Policy Action That Runs an External Program

This topic gives one example of using a workflow policy action to run an external program. You might use this feature differently, depending on your business model. In Siebel Workflow, you use Run External Program to define an action that runs an external program. For example, your company can write a custom executable to calculate the quality of a new lead. You can then call this executable from a workflow process when the parameters to calculate the lead change. You can use a program named leadcalc.exe in the C:\bin directory and an Action in order to call and execute Run External Program.
354
To define a workflow policy action that runs an external program 1 2

In the Siebel client, navigate to the Administration-Business Process screen, then the Actions view. In the Actions list, define a new record using values from the following table. Field Name Program Workflow Object Value Run Lead Calculation Program Run External Program (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 the Workflow Object field automatically populates. Otherwise, you pick a workflow policy object from the picklist for the Workflow Object field. After you step off the record, you cannot modify the Workflow Object.
In the External Program Arguments form, define fields using values from the following table. Field Executable Name Command Line Execute Type Available Substitutions Value leadcalc.exe (Enter command line parameters. These are the parameters you must pass to the executable.) (Choose an execute type.) (Choose the appropriate dynamic fields.)
In this form, you define the executable and information you must pass to the external program.
In the Recipients list, define a new record using values from the following table. Field Type Name Value Send to Position Support manager
35 5
Defining an External Program to Run on UNIX The predefined Run External Program workflow policy program is not supported on UNIX. However, you can use the procedure described in this topic instead.
To define an external program to run on UNIX 1

Define a business service that executes an external program:
a b
Navigate to the Business Service Administration screen, then the Business Service Methods view. Add a new business service. For example, Run Program.
c d
Add a new Method. For example, Run. Add a new Method Argument. For example, Program.
e f
Select Proc: Service_PreInvokeMethod. Call Clib.system in the function body. For example: var program = Inputs.GetProperty (Program) if (program) { Clib.system(program); } return (CancelOperation);
Define a workflow process that calls the business service defined in Step 1:
a b c d
Add a start step, a business service step, and an end step. Connect the steps. For the business service step, define Run Program and Run. For the input argument for Program, define the external program you must run. For example, you can define letter.txt that exists in /bin/mail hkim@pcs.com </home/users/ hkim/letter.txt.
Run your workflow process.
356
Examples of Defining a Workflow Policy

This topic describes examples of defining a workflow policy. It includes the following topics: Example of Defining a Workflow Policy That Sends Paging Notification of Service Requests That Are Not Assigned on page 357 Example of Defining a Workflow Policy That Sends an Email Notification of Open Opportunities on page 358
Example of Defining a Workflow Policy That Sends Paging Notification of Service Requests That Are Not Assigned
This topic gives one example of using a workflow policy to send a page. You might use this feature differently, depending on your business model. In this example, the support manager requires that a page be sent when the priority for a service request is Very High and no one is assigned to the service request. Assume the Send Page action is already defined. Next, you define the workflow policy to implement the workflow policy action.
To define a workflow policy that sends paging notification of service requests that are not assigned 1 2
Navigate to the Administration-Business Process screen, then the Policies view. In the list for the Policies List, choose New Record from the applet level menu. Define a new policy record using values from the following table. Field Name Workflow Object Policy Group Duration Value Page Support Manager Service Request High Frequency 2 hours
In the Conditions list, add two new records using values from the following table. Condition Field Service Request Priority Service Request Owner Operation = IS NULL Value High (leave empty)
This step defines the conditions under which the Page Support Manager policy applies.
4 5
Scroll down to the Actions list, then add an Action. From the picklist in the Action field, choose the appropriate notification action. For example, Page for Critical SR Gold Support.
35 7
Example of Defining a Workflow Policy That Sends an Email Notification of Open Opportunities
This topic gives one example of using a workflow policy to send a notice through email. You might use this feature differently, depending on your business model. In this example, the vice president of sales must be notified when the number of deals that are not closed reaches a designated level. For this example, assume you already defined a workflow policy action that batches information on the deals and sends an email message that contains information on the number of deals you designated.
To define a workflow policy that sends an email notification of open opportunities 1 2

Navigate to the Administration-Business Process screen, then the Policies view. In the list for the Policies List, chose New Record from the applet level menu. Define a new policy record using values from the following table. Field Name Workflow Object Policy Group Quantity Batch Value Very High Value Opportunity Opportunity Medium Frequency 5 checked
NOTE: It is not necessary for you to define the Quantity field in order to display a repeating message.
In the Conditions list, add two new records, using values from the following table. Condition Field Forecast Probability Forecast Revenue Operation <= > Value 50 400000
This step defines the conditions under which the Very High Value Opportunity policy applies.
In the Actions list, add a new action record using values from the following table. Action Excellent Quality Opportunity Email Consolidate Checked
This step defines the action to execute when the conditions are met.
358
Scroll to the bottom of the screen and examine the Send Message Arguments form. Values in the form automatically populated with information from the Action you defined in Step 4.
6 7
In the Actions applet, click the Excellent Quality Opportunity E-mail hyperlink in the Action applet. Examine values in the Actions applet and Send Message Arguments. These values can be modified to meet the specific requirements of your implementation.
Configuring the Workflow Policy Monitor to Align the Timing of Email Creation This topic describes how to make sure your email lists the opportunities that meet the conditions of the workflow policy. If the Workflow Policy Action agent runs too fast, then an individual email is inserted each time the conditions of the workflow policy are met.
To configure the workflow policy monitor to align the timing of email creation 1 2
Restart the Workflow Policy Monitor agent. 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 a Workflow Policy on page 401.
35 9
Defining a Custom Workflow Policy Customizing Workflow Policy Objects
Customizing Workflow Policy Objects

Values assigned to a predefined object that is associated with defining a workflow policy are modified in the Siebel client. You can use Siebel Tools to modify these predefined objects or to define new objects. After compiling your modifications, the modified definitions are available for use in the Siebel client. This topic includes the following topics: Display of Workflow Policy Objects on page 360 Defining a Customized Workflow Policy Object on page 361
For more information about: Procedures for using the Siebel client in order to define a workflow policy that references these compiled objects, see Process of Defining a Workflow Policy on page 340 Predefined policies you can use instead of defining new objects, see Types of Workflow Policy Programs That Are Predefined on page 381 Reference information, see Properties of Workflow Policies on page 470
Display of Workflow Policy Objects

This topic describes how workflow policy objects are displayed in the Siebel client. For information about how workflow policy objects are displayed in Siebel Tools, see Hierarchy of Workflow Policy Objects on page 331.
Workflow Policy Objects in the Siebel Client

You use Siebel Tools to modify a predefined or to define a custom workflow policy and workflow policy program. After deployment, a customization is visible in the Workflow Policy view and the Workflow Action view in the Siebel client.
Objects That Are Displayed in the Workflow Policy View Table 48 describes how a Workflow Policy Object is displayed in the Workflow Policy view in the Siebel client after the object is deployed from Siebel Tools.
Table 48.
Workflow Policy Objects That Are Displayed in the Workflow Policy View Location of Workflow Object in the Siebel Client Workflow Object picklist in the list for the Policies List. Condition Field picklist of the Conditions list. Values displayed in the picklist for the Condition field are context sensitive, depending on the value in the Workflow Object field in the list for the Policies List.
Workflow Object in Siebel Tools Workflow Policy Object Workflow Policy Component Column
360
Object definitions for the Workflow Policy Component do not appear in the Workflow Policy view. However, the Workflow Policy Component object acts as an aggregator for values that are displayed in the Condition Field. Because the Workflow Policy Component Column object is a child of the Workflow Policy Component, values for the object definitions of the Workflow Policy Component Column that are part of a Workflow Policy Component are displayed in the Condition Field. The deployed definitions are visible in the Siebel client in the Policies view of the Administration-Business Process screen.
Objects That Are Displayed in the Actions View Table 49 describes how a Workflow Policy Program is displayed in the Workflow Action view in the Siebel client after the program is deployed from Siebel Tools.
Table 49.
Workflow Policy Programs That Are Displayed in the Workflow Action View Location of Workflow Object in the Siebel Client Program field picklist in the Actions list Arguments field picklist in the Arguments list Values displayed in the picklist for the Arguments field are context sensitive, depending on the value in the Program field in the list for the Policies List.
Workflow Object in Siebel Tools Workflow Policy Program Workflow Policy Program Argument
The deployed object definitions are visible in the Siebel client in the Actions view of the Administration-Business Process screen. Information that is specific to Workflow Policies is described in this document. For more information about general Siebel Tools usage, see Using Siebel Tools.
Defining a Customized Workflow Policy Object

This topic describes how to use Siebel Tools in order to define customized objects that are associated with a workflow policy. It includes the following topics: Defining a Customized Workflow Policy Column on page 362 Defining a Customized Workflow Policy Object on page 363 Defining a Customized Workflow Policy Component on page 364 Defining a Customized Workflow Policy Component Column on page 364 Defining a Customized Workflow Policy Program on page 366 Defining a Workflow Policy Program Argument on page 368
For more information, see Examples of Workflow Policy Programs That Are Predefined on page 388.
36 1
Defining a Customized Workflow Policy Column

This topic describes how to define a customized workflow policy column. Before you can add a workflow policy column to a workflow policy component, you must define the workflow policy column in the Object List Editor (OBLE) for the Workflow Policy Columns. CAUTION: Deleting a workflow policy column requires removal of references to the columns in workflow policy objects. Even if a workflow policy column is not currently used in an active workflow policy, the Workflow Monitor Agent might reference the columns in the repository, thereby facilitating fast activation of new workflow policies in the future. However, in order to avoid potential link conflicts, care must be used to remove old references if design requirements change.
To define a customized Workflow Policy Column 1

Identify the business object, business component, and applet that use the new workflow policy column:
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, then choose the Activities view tab.
b c d e 2
From the application-level menu, choose the Help menu, then the About View menu item. Note the Business Object, Business Components, and Applets that this view uses. In Siebel Tools, in the Business Components OBLE, choose one of the business components identified in Step c, 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.
Define the new workflow policy column:
a b c
Choose Workflow Policy Column in the Object Explorer. From the application-level menu, choose the Edit menu, then the New Record menu item. In the Workflow Policy Columns OBLE, use the values you found in previous steps of this procedure to define properties for the new object. The table name and column name combination must be unique. If the table name and column name combination are already defined for another object, then you cannot save the object.
Defining the Condition of a Workflow Policy That Is Based on a Foreign Key You can define the condition of a workflow policy that is based on a foreign key that exists 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, and CURR_STG_ID is a foreign key from S_STG.NAME.
362
To define the condition of a workflow policy that is based on a foreign key 1 2 3

In the Workflow Policy Columns OBLE, define a new workflow policy column with S_STG.NAME in the Name property. Make sure CURR_STG_ID is added under the Opportunity workflow component. Define a new workflow component in the Opportunity workflow object that is based on the S_STG table, using values displayed in the following table. Property Name Source Table Name Source Column Name Target Component Name Target Column Name Value (your choice) S_STG ROW_ID Opportunity CURR_STG_ID
Add the new workflow column, S_STG.NAME, that you defined in Step 1 to the new workflow component you defined in Step 3.
You can now define a condition for the workflow policy that is based on the new workflow column.
Defining a Customized Workflow Policy Object

This topic describes how to define a customized workflow policy object. CAUTION: In the Workflow Policy Components OBLE, you must define only one record as the primary workflow policy component. The Primary property can be checked for only one record.
To define a customized workflow policy object 1 2 3 4 5 6

In Siebel Tools, navigate to the Workflow Policy Objects OBLE. From the application-level menu, choose the Edit menu, then the New Record menu item. Define properties for the new record. In the Object Explorer, click Workflow Policy Components. From the application-level menu, choose the Edit menu, then the New Record menu item. Make sure the Primary property contains a check mark. Note the caution provided at the beginning of this topic.
7 8 9
Add more workflow policy components, defining relations to the primary workflow policy component, as necessary. In the Object Explorer, click Workflow Policy Component Col. In the Workflow Policy Component Columns OBLE, add an object for each of the workflow policy components that you defined in Step 7.
36 3
Defining a Customized Workflow Policy Component

This topic describes how to define a customized workflow policy component.
To define a customized workflow policy component 1 2 3 4 5 6

In Siebel Tools, choose the Workflow Policy Object in the Object Explorer. In the Workflow Policy Objects OBLE, query the Name property for Account. In the Object Explorer, expand Workflow Policy Object, then choose Workflow Policy Component. In the Workflow Policy Components OBLE, define a new record with a value in the Name property. Enter a value in the Source Table Name property. Enter a value in the Source Column Name property. The Source Column Name property establishes a relationship between the workflow policy component you are currently defining and the primary policy component.
Identify the set of columns for the workflow policy component you just defined that you must monitor:
a b
In Siebel Tools, navigate to the Workflow Policy Column OBLE. Identify the column in the predefined workflow policy columns with an activity assigned to it but that is not currently exposed in the OBLE for the Workflow Policy Component Column.
Defining a Customized Workflow Policy Component Column

This topic describes how to associate a column with a workflow policy component. Your business can use specialized terminology that more clearly defines the environment within your company. Values that appear in the Condition Field picklist on the Conditions list of the Workflow Policies view in the Siebel client are populated from the Alias property. You can use the Alias property in the Workflow Component Columns OBLE to define a custom label. Then, you can use this label when you refer to the definition of the workflow component column.
To define a customized workflow policy component column 1 2

In Siebel Tools, navigate to the Workflow Policy Columns OBLE. Query the Name property for the name of the column you must modify. If the query returns no results, then define a new Workflow Policy Column that references the required data table and data table column.
3 4 5
Navigate to the Workflow Policy Objects OBLE, then query the Name property for the required Workflow Policy Object. Navigate to the Workflow Policy Components OBLE, then query the Name property for the required Workflow Policy Component. Navigate to the Workflow Policy Component Columns OBLE.
364
Define your customization:
If you are defining a new object, then, from the application-level menu, choose the Edit menu, then the New Record menu item. Add values to the Workflow Column Name and Alias properties, as necessary. If you are modifying an existing object, then query the Workflow Column Name property for the required Workflow Policy Component Column, and then modify the Alias property.
When defining the Workflow Column Name property, use the picklist 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 define a new object for it by using the Workflow Policy Columns OBLE.
In the Object Explorer, click Workflow Policy Object. By default, the Workflow Policy Object with the name of the object you just modified is the active record in the Workflow Policy Objects OBLE.
8 9
From the application-level menu, choose the Tools menu, then the Compile Selected Objects menu item. Click Compile. view.
10 In the Siebel client, navigate to the Administration-Business Process screen, then the Policies 11 In the list for the Policies List, click Query. 12 Query the Workflow Object field for the workflow object you just modified, then click Go.
Your custom alias displays in the Condition Field picklist in the Conditions list.
Example of Modifying a Workflow Policy Component Column to Display a Custom Label This topic gives one example of modifying a workflow policy component column. You might use this feature differently, depending on your business model. In this example, the sales department in your company must refer to the person who is handling the opportunity as the Opportunity Primary Sales Associate.
To modify a workflow policy component column to display a custom label 1 2 3 4 5

In Siebel Tools, in the Object Explorer, click Workflow Policy Object. In the Workflow Policy Objects OBLE, query the Name property for Opportunity. In the Object Explorer, expand the Workflow Policy Object tree, click Workflow Policy Component, then query the Name property of the Workflow Policy Components OBLE for Opportunity. In the Object Explorer, expand the Workflow Policy Component tree, then click Workflow Policy Component Col. In the Workflow Policy Component Columns OLBLE, query the Workflow Column Name property for Opportunity Primary Sales Rep Position, then change the Alias property to Opportunity Primary Sales Associate.
36 5
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 OBLE.
7 8 9
From the application-level menu, choose the Tools menu, then the Compile Selected Objects menu item. Click Compile. In the Siebel client, navigate to the Administration-Business Process screen, then the Policies view.
10 In the list for the Policies List, click Query, enter New Opportunity in the Name field, then click Go. 11 In the Conditions list, define a new record, setting the Condition Field to Opportunity Primary
Sales Rep Position, and the Operation to IS ADDED. Your custom alias displays in the Condition Field picklist.
Defining a Customized Workflow Policy Program

This topic describes how to define a customized workflow policy program. A workflow policy program is a generic event on which actions are based. You define a workflow policy program by defining the workflow policy event. CAUTION: Do not rename or change the name of an existing workflow policy program, as this can result in the loss of actions that are created for the program. If you define a workflow policy program that inserts a new record, then you must determine and provide the minimum field values that constitute a valid record for the inserted record, as defined in the repository for the table. Table 50 describes required values.
Table 50.
Values Required when Defining a Customized Workflow Policy Program Values Not Required A value for a system generated column is not required, such as CREATED, CREATED BY, LAST_UPD, LAST_UPD_BY, ROW_Id, MODIFICTION_NUM, and CONFLICT_Id.
Required Values Values for the columns that are needed to constitute the inserted record are required. If a default value is defined for a column, then that default value is used on the insert if the program specifies none. For example, the S_EVT_ACT table contains two required columns: NAME and ROW_STATUS. Because ROW_STATUS defaults to Y, it is not necessary for you to set a value in the program.
For more information, see Siebel Data Model Reference. CAUTION: Thoroughly test SQL queries that you plan to use with custom policy programs. Be aware that if the SQL statement fails to find rows, then the workflow policies action is unable to process a token.
366
To define a customized workflow policy program 1 2 3

In Siebel Tools, in the Object Explorer, click Workflow Policy Program. In the Workflow Policy Programs OBLE, choose an existing workflow policy program that is similar to what you require for the customized workflow policy program. Right-click, then choose Copy Record. The Copy Record feature copies the entire program, including the program arguments.
4 5
In the new workflow policy program, modify the appropriate properties in order to meet the requirements of the customized program, such as Workflow Object. Define the program arguments. Enter the arguments carefully to make sure capitalization, punctuation, and spelling are correct:
Type the entries in the Name column exactly as indicated in Table 99 on page 478. Primary ID, Primary Table, Operation Type, SQL Statement, and SQL Statement Outputs must contain one space between each word and each word must be properly capitalized. For example, Primary Id must contain: one space between the two words, a capital P, and a lowercase d. Avoid using the carriage return. For more information, see Use of Carriage Return in the Argument of a Workflow Policy Program on page 367. If using an SQL statement in a program argument, then make sure the statement is specific to the particular RDBMS you are using. Type the names of the column pairs exactly: one space between each word, identically capitalized, one space in front of the left parenthesis, and no spaces in the column. The order of the rows is not important.
NOTE: Before you use a workflow policy program and related arguments for the workflow policy program, you must delete the definitions for workflow policy program arguments that are inactive or incomplete. These can cause Workflow Monitor Agent errors.
Use of Carriage Return in the Argument of a Workflow Policy Program In a workflow policy program argument, the carriage return character that exists in SQL Statement and SQL Statement Outputs can cause unexpected behavior for a workflow policy program. In most cases, the substitution value is not substituted with the intended value but is instead substituted with the [Label] literally. Avoid using the carriage return character.
Copying an Existing Workflow Policy Program The advantage of copying an existing workflow policy program is that if something goes wrong with your customized workflow policy program, then you can start over with the original, unmodified workflow policy program. NOTE: It is recommended that if you define a new workflow policy program, then first copy an existing workflow policy program that is similar to what you require, and then modify the copy in order to suit your specific business requirements.
36 7
Also, if you modify a copy of an existing workflow policy program, then you can often reuse a significant portion of the preexisting configuration, which leads to fewer errors than if you define an entirely new workflow policy program.
Defining a Workflow Policy Program Argument

This topic gives one example of using a workflow policy program argument to send an email. You might use this feature differently, depending on your business model. The example in this topic adds a new workflow policy program argument. The current recipients of type relative are limited to the Primary Sales representative. You add a relative for Primary Contact, thereby allowing a policy maker to define an action that sends an email to the Primary Contact for an opportunity.
To define a workflow policy program argument 1 2 3 4

In Siebel Tools, navigate to the Workflow Policy Programs OBLE. In the Object Explorer, click Workflow Policy Program Arg. In the Workflow Policy Program Arguments OBLE, make sure an object named Send to Relative exists. Define a new record, setting the Name property to Primary Contact. A new workflow policy program argument cannot contain the same name as an SQL Statement Output. If an attempt is made to add a new program argument that does contain the same name as an SQL Statement Output, then the Monitor Agent server task suspends, and then displays the Examining request for policy message.
5 6
Click in the Default Value property. In the compose box, define your SQL statement. For example: select O.PR_CON_ID, 'Send to Contact' from &Table_Owner.S_OPTY O where O.ROW_ID=? Because Siebel Workflow passes the ROW_ID of the violating row, be sure your SQL queries use the same ROW_ID. In this example, the WHERE clause is written to use the ROW_ID of the opportunity row that violates the policy. Certain requirements must be considered when defining an SQL statement. For more information, see Requirements of an SQL Statement That Is Written for a Workflow Policy Program Argument on page 369. TIP: An SQL statement is specific to the database vendor. Use an external SQL tool in order to build and test your statement. If the test works, then copy the statement into the field.
Set the PickList property to Workflow Relative Type Picklist. This picklist identifies this argument as a relative.
The Visible field is checked for your new workflow policy program argument . The changed field is checked when you define a new program argument.
368
Requirements of an SQL Statement That Is Written for a Workflow Policy Program Argument An SQL statement that is written for a workflow policy program argument must include: The table name and column name you reference must be in upper case The case sensitive table name must be prefixed with &Table_Owner The SQL statement must be valid for the specific database vendor
Guidelines for Using an SQL Statement with a Workflow Policy Program Argument Guidelines when using a SQL statement with a workflow policy program argument include: It is recommended that the SQL statement return only one record. To be sure, use a statement that uses the outer join rather than the inner join. Only one workflow policy program argument that uses an SQL statement can be used 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.
CAUTION: It is recommended that you thoroughly test your SQL statement in the context of the workflow policy program in which it is used prior to implementation.
36 9
Defining a Custom Workflow Policy Conditions for a Workflow Policy
Conditions for a Workflow Policy

This topic describes how conditional logic is defined for a workflow policy. It includes the following topics: Standard Comparisons in the Conditions List on page 370 A Field That Is Not Known Is Interpreted as Null on page 371 Specialized Comparisons in the Conditions List on page 371 Date Calculations in the Conditions List on page 375
Conditional logic for a workflow policy is defined in the Conditions list of the Workflow Policies view in the Siebel client. Comparison values in the Operation field expose the Siebel Workflow policy component column for monitoring.
Standard Comparisons in the Conditions List

The Comparison field supports greater than (<), less than (>), not equal to (<>), greater than or equal to (>=), less than or equal to (<=), equal (=), LIKE, IN, NOT IN, BETWEEN, IS NULL, and IS NOT NULL operators. Table 51 describes comparisons and values for a typical database. The requirements of the syntax that is used with your specific database might vary.
Table 51.
Comparison Operators and Values for a Typical Database Value 5 5 5 5 5 A Abc% (1, 2, 3) ('A', 'B', 'C') 1 and 2 'A' and 'B'
Comparison less than sign (<) greater than sign (>) not equal to sign (<>) greater than or equal to sign (>=) less than or equal to sign (<=) equal sign (= ) LIKE IN NOT IN BETWEEN BETWEEN
370
The following syntax rules apply: If using LIKE, IN, NOT IN, or BETWEEN with character fields, then use single quotes around the value. If using IN or NOT IN, then you must place the value within parentheses. An AND is implied between multiple conditions that are defined that use these comparison values. AND means that all the conditions must be met before the action occurs. LIKE and NOT LIKE allow you to use wildcards. For example, LIKE Smith%, or NOT LIKE Sm%th%.
The following requirements of the underlying database apply: If you define values for the comparison operands LIKE, IN, NOT IN, and BETWEEN in the Value field of the Conditions list of the Workflow Policies view, then it must be in a form that the underlying database expects. IN, NOT IN, and BETWEEN require you to enter the database specific format for the field examined. For example, IN ('a', 'b', 'c') or IN (1, 2, 3, 4) and BETWEEN 'A' and 'B' or BETWEEN 1 and 10. On an MS SQL Server database, if you define a workflow policy condition on a LONG column, then the available comparisons are IS NULL, IS NOT NULL, LIKE, and NOT LIKE. NOTE: It is up to the creator of the policy to make sure the syntax is correct. The Process Designer only passes the BETWEEN clause to the database. It does not confirm syntax, except for date and time. For date and time fields, the Process Designer converts the date and time columns to the format of month/day/year, hour:minute:second.
A Field That Is Not Known Is Interpreted as Null

If a field value is not known rather than having no value, then the field is interpreted as null. For example, assume a condition includes the following logic: FIeldA IS UPDATED FieldB <> "MyValue" In this case, if FieldB is null, then the condition <> "MyValue" is false. Null is interpreted as the field value is not known. When evaluating whether null is not equal to Y, Siebel assumes the field could be set to anything, including Y. Therefore, because it cannot be concluded that the field is definitely not set to Y, false is returned and the Workflow Monitor Agent does not execute the action.
Specialized Comparisons in the Conditions List

The Comparison field supports the specialized operators IS ADDED, IS UPDATED, and IS DELETED. The IS operators serve as a starting point for the examination of the workflow policy.
37 1
If defining a batch type of workflow policy, then the comparison operators IS ADDED, IS UPDATED, or IS DELETED must be used in conjunction with a regular workflow policy condition. These comparison operators are considered special conditions that are intended for Dynamic mode when calling rows to look up a regular condition. The following comparisons work at the workflow policy component level but do not operate at the field level: IS ADDED. If a new row is added for this workflow policy component, then call this workflow policy to be examined. If used in conjunction with a standard comparison, IS ADDED can be used when a record is updated. IS DELETED. If a row is deleted from this workflow policy component, then call this workflow policy to be examined.
The following comparisons operate at the field level: IS UPDATED. If the value for a field that is changed by adding a new record with the specific field, or by modifying the field in an existing record, then call this policy to be examined. To monitor if a field for a particular table is updated, use the workflow policy component column that represents the LAST_UPD column for that table. To monitor if a field within the workflow policy component is modified, use the field that is named after the workflow policy component.
372
Table 52 describes specialized comparisons for a database platform that can be used in defining a workflow policy condition.
Table 52.
Specialized Comparisons Value Use IS ADDED with a workflow policy component column that is defined in the Condition field and when nothing is defined in the Condition value. Use IS UPDATED with a field that is defined in the Condition field, and when nothing is defined in the Condition value. The condition is met when the field changes. Use IS DELETED when you define a child workflow policy component in the Condition field, and when nothing is defined in the Condition value. Explanation The workflow policy condition is met when an instance of the workflow policy component is added. For example, if the policy component column for the service request is defined in the Condition field, and if IS ADDED is defined in the comparison, then the condition is met when you create a new service request. For example, if the status of a service request is defined in the Condition field, and if IS UPDATED is defined in the comparison, then the workflow policy condition is met when the status for the service request changes. For more information, see IS UPDATED in the Conditions List on page 374. A child workflow policy component is a workflow policy component that is associated with a parent workflow policy component in Siebel. For example, a parent workflow policy component might be Service Request. A child workflow policy component might be Service Request Activity. If IS DELETED is used in conjunction with another workflow policy condition, then the other condition must be based on the parent workflow policy component. For more information, see IS DELETED in the Conditions List on page 374.
Comparison IS ADDED
IS UPDATED
IS DELETED
An OR is implied between specialized comparisons, 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 when an activity is added to an open service request. Conditions in the policy that you then create include: 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 are generated do not represent every condition defined in the policy. The database triggers that are not represented are ignored. This situation can be viewed by examining the trigger.sql file that is produced as a result of the comparison. This behavior is expected. If the condition is modified, then Generate Triggers must be run in order to implement the updated conditions.
37 3
If using a workflow policy condition with a standard comparison, then the condition is encompassed in the database triggers that are generated. However, if using a specialized comparison, because Workflow Monitor Agent evaluates the condition at runtime, then database triggers on the tables do not include the standard comparison conditions.
IS UPDATED in the Conditions List

Although workflow policy conditions are joined when an IS UPDATED statement is present, the format of the trigger.sql statement that is generated for the condition does not contain AND within the SQL syntax. If a condition that is defined in the workflow policy is violated when IS UPDATED is not present, then the Workflow Monitor Agent calls the policy. However, if an IS UPDATED comparison is included as criteria on a field, then other fields in the Policy conditions are not checked.
IS DELETED in the Conditions List

For example, assume that if an activity is deleted from a service request that contains a Sub-Status of In Process, then you must notify a service request owner. Table 53 describes the configuration that you use in this case.
Table 53. Policy
Example of Using IS DELETED First Condition Condition is based on each of the following situations being true: Field is Activity Component Comparison is IS DELETED Value is empty Second Condition Condition is based on each of the following situations being true: Field is Service Request Sub-Status Comparison is equal (=) Value is In Process Action Send an email to the SR owner.
Based on the Service Request Workflow policy object.
NOTE: If using IS DELETED, then the ROW_ID of the record that is deleted from the child workflow policy component is not tracked or logged in the S_ESCL_REQ table, nor can the Workflow Monitor Agent component determine exactly which row that was deleted caused the policy to be called. If you must define Siebel Workflow to capture the deleted row, then you must use a workflow process that is driven by a run-time event. The run-time event is the PreDeleteRecord event on the BusComp event object type.
374
Date Calculations in the Conditions List

Workflow Monitor considers both date and time when evaluating a workflow policy condition that performs a date comparison. CURRENT can be used when a value is entered for a date comparison. The following format can be applied for using CURRENT: CURRENT [+/-] d:h:m where:

d represents the day h represents the hour m represents the minutes
For example, CURRENT + 01:02:03 is the value in CURRENT plus one day, two hours, and three minutes. You can use CURRENT in the comparison value for date fields. You can also use CURRENT when you define the activation and expiration dates for a broadcast message action. For more information, see Date Format with a Workflow Policy Program on page 477.
37 5
376
15 Using a Predefined Workflow Policy

This chapter describes workflow policies and workflow policy programs that are predefined. It includes the following topics: Configuring a Predefined Workflow Policy on page 377 Types of Workflow Policy Programs That Are Predefined on page 381 Examples of Workflow Policy Programs That Are Predefined on page 388 Workflow Policy Programs that Are Predefined for Siebel Marketing on page 393
Configuring a Predefined Workflow Policy

You can use a predefined workflow policy to implement commonly used functionality. You can view these policies as groups in the Siebel client by navigating to the Administration-Business Process screen, then the Policy Groups view.
To view groups of predefined workflow policies for messaging 1 2

In the Siebel client, navigate to the Administration-Business Process screen, then the Policy Groups view. Choose Siebel Messaging in the Name column. The messaging policies are displayed in the Policies list.
Configuring a Predefined Workflow Policy for Messaging

You can use a predefined messaging policy to display a message in a pop-up dialog box in the Siebel client. For example, the predefined Messaging Policy Send Screen Pop for Activity can be used to display a pop-up dialog that informs the end-user of a new activity.
To configure a predefined workflow policy for messaging 1 2 3 4

In the Siebel client, navigate to the Administration-Business Process screen, 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.
37 7
Using a Predefined Workflow Policy Configuring a Predefined Workflow Policy
Run the Generate Triggers server component with EXEC = True and Remove = True. For more information, see Generating Database Triggers on page 404.
6 7 8 9
Run Generate Triggers again, this time with Remove = False. Navigate to the Messages screen, then the All Messages view. Click New. In the Last Name field, enter the name of the contact who receives the message.
10 In the Assigned To field, enter the name of the employee to which this user is assigned. 11 In the Message field, type the text message that displays in the pop-up dialog. 12 Set the Alert Type field to Screen Alert. 13 Click the Message Alert Setup tab, then make sure there is a corresponding entry for the message
recipient and that Alert Type is set to Screen Alert. If the message recipient is already defined, then perform the following steps:
a b c
Click New. Set the Last Name field to the same name you set in Step 9. Set the Alert Type field to Screen Alert.
14 Start a Workflow Monitor Agent server task for the workflow policy group you activated in Step 5.
For more information, see Executing a Workflow Policy with Workflow Monitor Agent on page 417.
15 Verify the configuration: a b c d

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 initial client session, insert a new activity for this user. In the second client session, verify the pop-up dialog that contains the message you entered in Step 11 displays.
Identifying the Source Table When Modifying an Existing Workflow Policy

When defining the types of workflow policies for your business, you might find that the predefined workflow policy objects do not contain the policy components you require. You can use the procedures in this topic as a general guideline to identify the source database table and column when modifying an existing workflow policy object.
378
Work you must perform before modifying a workflow policy object include: Identify the names of the database table and column for the workflow policy object. If you are going to add or modify a component, then you must know the relationship between the component and the primary workflow policy component. Make sure other records are not referencing this object that can be affected by your change. For example, before you inactivate a component column, make sure that no workflow policy conditions are referencing that component column.
The procedures in this topic are presented in the context of account objects.
To identify the database table 1

In the Siebel client, navigate to the appropriate workflow policy object view, which is the view that contains the business data you must monitor. For example, if you must modify the workflow for an account activity, then navigate to the Accounts screen, Accounts List, then the Activities view.
From the application-level menu, choose the Help menu, then the About View menu item. About View identifies the business object, business components, and applets that this view uses. In the example of the Account Activities view, the dialog box identifies Action as the business component that is used by the Activities list.
In Siebel Tools, navigate to the Business Components OBLE, then query the Name property for Action. Note the value in the Table property. In this example, the table name is S_EVT_ACT. You use this table name when you define a workflow policy component.
Next, determine the relationship between the business component and the primary workflow policy component.
To determine the relationship between the business component and the primary workflow policy component 1 2
Navigate to the Business Objects OBLE, then query the Name property for Account. Navigate to the Business Object Components OBLE, query the Bus Comp property for Action, then click the hyperlink 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 and the Action business components. This Link defines the relationship between the parent Business Component and the child Business Component through the Source field and Destination field. A Source Field property that is empty indicates that the join is using the ROW_ID column of the table that is defined in the Table property of the parent business component. The Destination Field property defines the field within the child business component that is a foreign key to the Business Component.
37 9
Click the hyperlink in the Child Business Component property. Clicking this hyperlink navigates you to the Action business component in the Business Components OBLE.
4 5
In the Object Explorer, expand the Business Component tree, then click Field. In the Fields OBLE, choose the Account Id field, 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 use this information when you define the workflow policy component.
380
Using a Predefined Workflow Policy Types of Workflow Policy Programs That Are Predefined
Types of Workflow Policy Programs That Are Predefined

This topic describes the types of predefined workflow policy program types that can be used in a workflow process. It includes the following topics: Overview of Workflow Policy Programs That Are Predefined on page 381 Workflow Policy Program That Sends a Page on page 382 Workflow Policy Program That Sends an Email Message on page 383 Workflow Policy Program That Sends a Broadcast Message on page 384 Workflow Policy Programs That Execute a Database Operation on page 386 Workflow Policy Program That Runs an External Program on page 386
Workflow Policies comes with a number of predefined workflow policy programs that you can use to meet specific business requirements. This way, you can modify existing, predefined objects rather than define them from scratch.
Overview of Workflow Policy Programs That Are Predefined

A workflow policy program is a generic event on which actions are based. A workflow policy program defines the particular execution that occurs when the conditions of a workflow policy are met. To view object definitions for a predefined workflow policy program, navigate to the Workflow Policy Programs OBLE in Siebel Tools. Table 54 describes workflow policy programs that are created from program types. It provides an inventory of predefined workflow policy programs, and describes common actions you can use by inserting your own message text.
Table 54.
Types of Predefined Workflow Policy Program Program Send Page Send Opportunity Page Send Quote Page Send SR Page Description Sends a generic page message. Sends a page regarding an opportunity. Sends a page regarding a quote. Sends a page regarding a service request. Sends a generic email message. Sends an email regarding an opportunity. Sends an email regarding an opportunity quote. Sends an email regarding a service request.
Program Type Send Page
Send Email
Send Email Send Opportunity Email Send Quote Email Send SR Email
38 1
Table 54.
Types of Predefined Workflow Policy Program Program Send Message Broadcast Send SR Message Broadcast Send Opportunity Message Broadcast Description Sends a generic broadcast message. Sends a broadcast message regarding a service request. Sends a broadcast message regarding an opportunity. Updates the close date of the service request to the date for today. Changes the owner of the service request. Changes the group of the service request. Changes the owner of the service request to the current manager for the owner. Changes the priority of the service request to a new value. Changes the severity of the service request to a new value. Changes the status of the service request to a new value. Changes the Sub-Status of the service request to a new value. Creates an activity for a service request. Creates an activity for an opportunity.
Program Type Send Broadcast Message
Database Operation
Change SR Close Date to Today Change SR Owner Change SR Group Change SR Owner to Manager Change SR Priority Change SR Severity Change SR Status Change SR Sub-Status Create SR Activity Create Opportunity Activity
Workflow Policy Program That Sends a Page

If you choose the Send Page workflow policy program type in the Workflow Policies Actions list, then the Send Page Arguments form displays.
382
Table 55 describes arguments and values for the Send Page workflow policy program type.
Table 55.
Arguments and Values for the Send Page Workflow Policy Program Type Description Numeric message when the pager is numeric. Text message when the pager is alphanumeric. Current is a reserved word in Siebel Workflow. Do not use this word in a message. Dynamic fields that you can use in the Alpha Message Template. When the action executes, the substitution value is populated with the value from the record that meets the conditions for the workflow policy.
Argument Numeric Message Template Alpha Message Template
Available Substitutions
Items to consider include: Workflow policies automatically determine the correctly formatted message depending on the type of pager that is used by the person who is paged. If neither of the message arguments contains a value, then Workflow Policies logs an error message and the action is not finished. You can only send a page to an employee. The pager information for an employee is stored in the Employee Administration view. The Siebel database currently does not store pager information for contacts. Values in a message that originate from the Available Substitutions field can be substituted.
Configurations That Define Numeric Paging Numeric paging is inherently unreliable because of a lack of a computer protocol for sending a numeric page. If you must send a numeric page, then you can use the Pager Pin field in the employee table in order to control the delay that occurs between dialing the paging phone number and sending the numeric message. Add commas to the Pager Pin field. Each comma is roughly equal to a half second delay. Avoid using the numeric paging feature in an application that is mission critical.
Workflow Policy Program That Sends an Email Message

If you choose the Send Email workflow policy program in the Actions list, then the Send Message Arguments form displays along with the Recipients list. The Send Message Arguments form allows you to define an email template that is used to build the message which is sent to the recipient who is defined in the Recipients list.
38 3
Table 56 describes arguments and values for the Send Email workflow policy program type.
Table 56.
Arguments for the Send Email Workflow Policy Program Type Description Subject line of the email message. Text of the message. The maximum length is 2000 characters, including variable substitutions. Current is a reserved word in Siebel Workflow. Do not use this word in a message.
Argument Subject Message Template
Repeating Message
The message that is repeated when the Consolidate flag is checked on the Workflow Policies view. Current is a reserved word in Siebel Workflow. Do not use this word in a message.
Available Substitutions
A dynamic field that you can use in Subject, Message Template, and Repeating Message. If the action executes, then the substitution value is populated with the value from the record that meets the conditions of the workflow policy.
How an Email Can Be Sent to an Email Address That is Held in a Custom Field Workflow Manager can be configured to send an email message to an email address that is defined in a custom field, including to an address that is stored in a column other than S_EMPLOYEE.EMAIL_ADDR. For more information, see 475546.1 (Doc ID) on OracleMetaLink 3.
Workflow Policy Program That Sends a Broadcast Message

If the Send Message Broadcast workflow policy program is chosen in the Actions list, then the Send Message Broadcast Arguments form displays.
384
Table 57 describes arguments and values for the Send Broadcast Message workflow policy program type.
Table 57.
Arguments for the Send Broadcast Message Workflow Policy Program Type Description Date and time for which the broadcast message is active. The variable CURRENT can be used when defining the activation date. For more information, see Date Calculations in the Conditions List on page 375.
Argument Activation
Expiration
Date and time when the broadcast message expires. The variable CURRENT can be used when defining the activation date. For more information, see Date Calculations in the Conditions List on page 375.
Abstract Message Template
Short description of the broadcast message. Text of message to broadcast. The maximum length is 2000 characters, including variable substitutions. Current is a reserved word in Siebel Workflow. Do not use this word in a message.
Severity Available Substitutions
Severity of message to broadcast. Dynamic fields that you can use in the Abstract and Message Template. If the action executes, then the substitution value is populated with the value from the record that meets the conditions of the workflow policy.
Activation of the Check New Broadcasted Message Workflow Policy The Check New Broadcasted Message policy monitors the S_BRDCST_MSG table and starts the Notify Broadcasted Message workflow process in order to broadcast a new message that is added to the table. If you use a workflow policy that contains a workflow policy program Type property that is set to Send Broadcast Message, and if you implement caching for the broadcast message on an object manager component, then you must activate the Check New Broadcasted Message workflow policy, which belongs to the Siebel Messaging policy group. For more information about: Activating a workflow policy, see Overview of Generating Database Triggers on page 403. Configuring caching for a broadcast message, see Siebel Applications Administration Guide.
Consolidation of Messages That Are Sent Through the Send Broadcast Message Workflow Policy Program It is not possible to consolidate multiple broadcast messages into a single message that is then displayed to an end user. A user receives every broadcast message that is sent by a workflow process, each as a separate message.
38 5
Workflow Policy Programs That Execute a Database Operation

A number of database operation programs are predefined. You just define the parameters. If you choose a database operation program, such as Create Opportunity Activity in the Actions list, then the Arguments list displays. Table 58 describes arguments and values for the Database Operation workflow policy program type.
Table 58.
Arguments for the Database Operation Workflow Policy Program Type Description Name of column to be updated. Indication that the argument is required. Updated value of the column. If a substitution is defined in the program, then you can use a substitution in the value. The syntax for adding a substitution to the value is square brackets around the variable. For example, [SR Num].
Argument Name Required Value
Workflow Policy Program That Runs an External Program

If a Run External workflow policy program type is chosen in the Program field of the Actions list, then the External Programs Arguments list displays. For more information, see Example of Defining a Workflow Policy Action That Runs an External Program on page 354.
386
Table 59 describes arguments for the Run External workflow policy program type.
Table 59.
Arguments for the Run External Workflow Policy Program Type Description Path and name of executable to run. For example, the executable launches from the Siebel Server. The executable can be a batch program.
Argument Executable Name
Command Line
The command line to use. Include the parameters that you must pass to the executable. If passing multiple substitution parameters, then you must include a space between each parameter. For example: "[FirstName]"^"[LastName]" where: ^ is a space
A substitution parameter that contains a space must be encased in quotes. The quotes are also passed as part of the parameter. For more information, see Siebel Object Types Reference. Execute Type Settings for Execute Type include: Wait. Workflow Policies waits for the external program to finish, then examines the return code of the external program. If the return code is not 0, then an error occurs. No Wait. Workflow Policies executes the external program in the background, then continues processing. The return code is not checked.
When using a Visual Basic program that generates files, set Execute Type to Wait in order to avoid possible corruption of files. If Execute Type is set to No Wait, then Visual Basic attempts to write files twice, thus corrupting the data. Available Substitutions Dynamic fields that can be used as command line parameters. If the action executes, then the substitution value is populated with the value from the record that is in violation.
If no path is supplied for the Executable Name argument, then the executable is assumed to be in the current path of Workflow Policies running on the Siebel Server. For example, if your Siebel Server is installed on C:\siebsrvr, then the default path for the executable name is C:\siebsrvr\bin. NOTE: The external program cannot be one that is interactive, requires a user interface, or accesses the Windows desktop.
38 7
Using a Predefined Workflow Policy Examples of Workflow Policy Programs That Are Predefined
Examples of Workflow Policy Programs That Are Predefined

This topic includes examples of using predefined workflow policy programs. It includes the following topics: Example of a Workflow Policy Program That Manages the SR Close Date on page 388 Example of a Workflow Policy Program That Assigns an SR Owner on page 389 Example of a Workflow Policy Program That Escalates an SR on page 390 Example of a Workflow Policy Program That Sends a Quote by Using a Page on page 392 Workflow Policy Programs that Are Predefined for Siebel Marketing on page 393.
The examples use predefined workflow policy programs that are included with Workflow Policies. These programs can be viewed in the Object Explorer in Siebel Tools by choosing the Workflow Policy Program object.
Example of a Workflow Policy Program That Manages the SR Close Date

This topic gives one example of using a predefined workflow policy program to automatically close SRs (service requests) that are marked as resolved but not closed. You might use this feature differently, depending on your business model. Using this program, you can define a policy so that if a service request contains an activity of type Resolution, and if the service request is open for more than five days, then the service request close date is changed to the date for today. If the policy calls the workflow policy program, then the program enters the current system date into the Close Date field of the service request. Table 60 describes arguments for the Change SR Close Date to Today workflow policy program.
Table 60.
Arguments for the Change SR Close Date to Today Workflow Policy Program Description Contains the row ID of the service request that meets the conditions for the workflow policy. Specifies the S_SRV_REQ table and the operation to execute the Update operation.
Argument Name Primary ID Primary Table Operation Type
388
Table 60.
Arguments for the Change SR Close Date to Today Workflow Policy Program Description select sys_extract_utc(current_timestamp) from &Table_Owner.S_DUAL This statement calls the Siebel function now() to obtain the current date and uses the table &Table_Owner.S_DUAL to temporarily hold the value. The S_DUAL table is used to hold temporary values. A math function can also be performed. For example, the SQL statement select {fn now()}+7 from &Table_Owner.S_DUAL returns the current date plus seven days. Different RDBMS databases use different formats for the same function. For example, in MS SQL, the function GetDate() is used to return the current date. NOTE: The column name length must be less than 30 characters. For example, the following statement violates this rule because it is more than 30 characters in length: TO_CHAR(CREATED,'dd month yyyy','NLS_DATE_LANGUAGE=FRENCH').
Argument Name Sql Statement
Sql Statement Outputs New Close Date (Column) New Close Date Update Row ID
The value for the Today variable is obtained from the SQL statement. Specifies the column in the record to be updated (ACT_CLOSE_DT). Specifies the field to be updated to the value of Today. The row ID of the record you must update. This argument is the same as the value of the Primary ID.
Example of a Workflow Policy Program That Assigns an SR Owner

This topic gives one example of using a predefined workflow policy program to automatically assign an SR that is not yet assigned. You might use this feature differently, depending on your business model. If an open service request is not assigned for a certain length of time, then this workflow policy program can be used to assign, that is change the owner of, a service request to the person who is considered an expert in the area of the specific service request. This configuration allows the correct people to see the incoming service request and assign it appropriately. This workflow policy program allows you to choose a new owner from a picklist and put it into the field of the service request that matches the condition for the workflow policy.
38 9
Table 61 describes arguments for the Change SR Owner workflow policy program.
Table 61.
Arguments for the Change SR Owner Workflow Policy Program Description Contains the row ID of the service request that meets the condition for the workflow policy. Specifies the S_SRV_REQ table and to execute the Update action.
Argument Name Primary ID Primary Table Operation Type New Owner (Column) New Owner
Specifies to update the Owner_EMP_ID field in the record that is updated. Indicates that a picklist is displayed for assigning a new owner. The picklist is defined by the columns picklist that is set to Picklist SR Owner, the Source set to ID, and the Applet set to SR Owner Pick Applet.
Visible
If checked, then indicates that the picklist is visible to the user.
Example of a Workflow Policy Program That Escalates an SR

This topic gives one example of using a predefined workflow policy program to assign an open SR (service request) to a manager. You might use this feature differently, depending on your business model. If the service request is not closed within a specific duration of time, then assign the service request to the manager for the owner. This configuration allows a proper response time to service calls. Work performed by this workflow policy program includes: Uses the Primary ID as input into a SQL statement Uses a query SQL statement to retrieve 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 optionally update the New Owner field through a picklist
390
Table 62 describes arguments for the Change SR Owner to Manager workflow policy program.
Table 62.
Arguments for the Change SR Owner to Manager Workflow Policy Program Description Contains the row ID of the service request that meets the condition for the workflow policy. Specifies the S_SRV_REQ table and to execute the Update action.
Argument Name Primary ID Primary Table Operation Type New Owner (Column) New Owner Sql Statement
Specifies to update the Owner_EM_ID field in the record that is updated. Indicates that a picklist is displayed for assigning a new owner. Policy Monitor requires definitions that are contained in the workflow policy object, workflow policy components, and workflow policy columns. If working and coding a workflow policy program by using Siebel tables, then it is required that the base table be explicitly joined through SQL code. The following example SQL statement joins four tables, thus providing access to data from these four 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
Items to consider include: Only one field is retrieved. SR.ROW_ID = ? uses a question mark as a placeholder for inputting the value of the Primary ID. The Primary ID is substituted for the question mark.
Sql Statement Inputs Sql Statement Outputs
Set to the value of Primary ID. Set to the value of Manager.
39 1
Example of a Workflow Policy Program That Sends a Quote by Using a Page

This topic gives one example of using a predefined workflow policy program to automatically send a quote depending on the relationship between the value for the quote and the revenue value of the opportunity that the quote references. You might use this feature differently, depending on your business model. If a created quote contains a value that is less than some percentage of the revenue for the opportunity, then it is considered heavily discounted, and a page is sent to a designated employee.
SQL Usage with This Example This workflow policy program sends out a pager message. The SQL statement is configured for the different RDBMS syntax. The four SQL statements include one default and three that are specific to an RDBMS: Informix, Oracle, and SQL Anywhere. The default SQL Statement retrieves five values from four tables by using an outer join that is defined by *=: 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 Oracle SQL Statement retrieves five values from four tables by using an outer join that is defined by (+): 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. However, if an SQL statement with <SQL style> is present, then this style takes precedence over the SQL Statement. Output from the SQL statement defines five variables that hold the result of the query statement. These variables are Quote Number, Revision, Opportunity, Account, and Site. In an outer join, there might not be an associated table, in which case the variables are set to null.
392
Using a Predefined Workflow Policy Workflow Policy Programs that Are Predefined for Siebel Marketing
Workflow Policy Programs that Are Predefined for Siebel Marketing

This topic describes how to use workflow policy programs in order to assist with the execution of a marketing campaign.
Overview of Workflow Policy Programs That Are Predefined for Siebel Marketing
The workflow policy programs in Siebel Marketing are designed to allow a marketer to define complex campaign policies in order to automate the different stages of the campaign. Actions are based on the type of workflow policy program that is used by Workflow Policies in order to define campaign policies. Workflow policy programs that generate actions in order to execute a campaign include: Send Campaign Email. Sends an email to the contacts and prospects who are associated with a campaign. Create Campaign Contact Activity. Generates an activity record for the contacts or prospects who are the target of the marketing campaign. Assign to Campaign. Uses a contact or a prospect and assigns it to a chosen campaign.
Workflow Policy Program to Send Email for a Marketing Campaign

The Send Campaign Email workflow policy program provides a marketer the ability to send an email to the targets of the marketing campaign, such as contacts or prospects. Send Campaign Email uses Available Substitutions in the Send Message Arguments form, such as Prospect First Name, in order to allow for the personalization of campaign emails. You use the Recipients list in the Workflow Policy view in the Siebel client in order to choose the Recipient Type. The campaign contacts and prospects to whom the email is sent 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 for the workflow policy program.
To modify available substitutions 1 2 3 4

In Siebel Tools, query the Name property of the Workflow Policy Programs OBLE for Send Campaign Email. Right-click the Send Campaign Email workflow policy program, then choose Lock Object. In the Workflow Policy Program Arguments OBLE, 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. The list that is defined in the Default Value property is displayed in the Available Substitution field in the Send Message Argument form.
39 3
Workflow Policy Program to Create Activities for a Marketing Campaign

The Create Campaign Contact Activity workflow policy program generates an activity record for the contacts or prospects who are the targets of the campaign. You use the Workflow Policy Program Arguments OBLE to define the data that populates the Contact Activity record. Table 63 describes some values that can be assigned to arguments for the Create Campaign Contact Activity workflow policy program in order to generate email activity.
Table 63.
Arguments for the Create Campaign Contact Activity Workflow Policy Program Value Values for the Name argument include: Description. Use text to describe activity. Status. Choose the activity status, such as planned or active, from the picklist. Type. Choose the Activity type from the picklist.
Argument Name
Required Value
This value indicates whether the argument is required. Text or picklist.
Workflow Policy Program to Assign a Contact to a Marketing Campaign

The Assign to Campaign workflow policy program adds the contact or prospect to the list of campaign contacts or prospects for the designated campaign. Table 64 describes some of the values that can be assigned to arguments for the Assign to Campaign workflow policy program.
Table 64.
Arguments for the Assign to Campaign Workflow Policy Program Value Picklist that allows you to choose a campaign to which you assign the contact or prospect.
Argument New Campaign
Example of Developing a Workflow Policy That Manages a Marketing Campaign

This topic gives one example of developing a workflow policy to manage a marketing campaign. You might use this feature differently, depending on your business model.
394
To develop a workflow policy that manages a marketing campaign, perform the following tasks:
1 2 3
Defining Workflow Policy Actions for the Marketing Campaign on page 395. Defining the Workflow Policy Group for the Marketing Campaign on page 397. Defining Workflow Policies for the Marketing Campaign on page 397.
In this example, a marketer must run a two tier campaign with different work executed depending on how the campaign recipient responds. The marketer names the campaign CD-ROM Promotion. Ways that the marketer requires the campaign to work include: An email is sent telling recipients they can receive a discount by ordering a new product over the phone. The marketer must keep track of the recipients and gives them two weeks to respond. At the end of the two week period, recipients who did not respond to the offer are assigned to a new campaign.
Defining Workflow Policy Actions for the Marketing Campaign

This task is a step in Example of Developing a Workflow Policy That Manages a Marketing Campaign on page 394. Workflow policy actions required for this example include: Send Campaign Email. To send the offer email to the campaign recipients. Create Campaign Contact Activity. To record the activity that is associated with the contact. Assign to Campaign. To assign non respondents to a new campaign.
First, define a send campaign email action.
To define a send campaign email action 1 2

In the Siebel client, navigate to the Administration-Business Process screen, then the Actions view. In the Actions list, define a new record using values from the following table. Field Name Program Workflow Object Comment Value Send First Campaign Contact Send Campaign Email Campaign Contact (Enter appropriate text, as necessary.)
39 5
In the Send Message Arguments form, define the argument using values from the following table. Field Subject Message Template Value (Enter text and dynamic fields, as necessary.) (Enter text and dynamic fields for sending email to Contacts.)
In the Recipients list, define a new record using values from the following table. Field Type Name Value (Choose a predefined Recipient.) (Choose the appropriate recipient name.)
This action is now available for use in a workflow policy. Next, define a Create Campaign Contact Activity action.
To define a create campaign contact activity action 1 2

Navigate to the Administration-Business Process screen, then the Actions view. In the Actions list, define a new record using values from the following table. Field Name Program Workflow Object Comment Value First CD-ROM Campaign Create Campaign Contact Activity Campaign Contact (Enter appropriate text, as necessary.)
In the Arguments list, define the Type argument using values from the following table. Field Argument Value Value Type (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, define a new record in the Arguments list, then define the field and value. Next, define an Assign to Campaign Email action.
396
To define an assign to campaign email action 1 2

Navigate to the Administration-Business Process screen, then the Actions view. In the Actions list, define a new record using values from the following table. Field Name Program Workflow Object Comment Value Assign to Campaign Assign to Campaign Campaign Contact (Enter appropriate text, as necessary.)
In the Arguments list, define the Type argument using values from the following table. Field Argument Value Value New Campaign Not applicable
Defining the Workflow Policy Group for the Marketing Campaign

This task is a step in Example of Developing a Workflow Policy That Manages a Marketing Campaign on page 394. Workflow policies must be assigned to a workflow policy group. Therefore, in this example, a workflow policy group is defined specifically for the marketing campaign.
To define the workflow policy group for the marketing campaign 1 2

Navigate to the Administration-Business Process screen, then the Policy Groups view. In the Policy Groups list, add a new record using values from the following table. Field Name Comments Value CD-ROM Promotion group of policies for CD-ROM marketing campaign
Defining Workflow Policies for the Marketing Campaign

This task is a step in Example of Developing a Workflow Policy That Manages a Marketing Campaign on page 394. After the workflow policy actions and the workflow policy group are defined, the workflow policies can be defined. In this topic, you define workflow policies for the marketing campaign and for assigning non respondents. When performing the procedures for defining the policies in this topic, pay careful attention to how the fields in the Conditions list are set.
39 7
Defining the Email for the Marketing Campaign Policy The policy that you define in this topic calls for the sending of the offer email and the activity record for the email.
To define the email for the marketing campaign policy 1 2

Navigate to the Administration-Business Process screen, then the Policies view. In the list for the Policies List, define a new record using values from the following table. Field Name Workflow Object Policy Group Duration Value Email for CD-ROM campaign Campaign Contact CD-ROM Promotion 0
The Policy Group you define in this step is the group you created in Defining the Workflow Policy Group for the Marketing Campaign on page 397.
In the Conditions list, to define the name, define a new record using values from the following table. Field Condition Field Operation Value Value Name = 1st CD-ROM Promotion
In the Conditions list, to define the Start Date, define a new record using values from the following table. Field Condition Field Operation Value Value Start Date = (Enter the date on which the campaign starts sending messages to the target audience.)
398
In the Conditions list, to define the Campaign Status, define a new record using values from the following table. Field Condition Field Operation Value Value Campaign Status = Launched
The Launched value starts the campaign. Next, define the Assign Non-Respondents policy.
Defining the Assign Non Respondents Policy The policy that you define in this topic starts the reassignment of non respondents to a new campaign.
To define the assign non respondents policy 1 2

Navigate to the Administration-Business Process screen, then the Policies view. In the list for the Policies List, define a new record using values from the following table. Field Name Workflow Object Policy Group Duration Value Non-Respondents of CD-ROM campaign Campaign Contact CD-ROM Promotion 14
In the Conditions list, to define the Name, define a new record using values from the following table. Field Condition Field Operation Value Value Name = 1st CD-ROM Promotion
39 9
In the Conditions list, to define the Campaign Status, define a new record using values from the following table. Field Condition Field Operation Value Value Campaign Status = Launched
In the Conditions list, to define the Done Flag, define a new record using values from the following table. Field Condition Field Operation Value Value Done Flag = N
Defining Logic That Calls the Assign Non Respondents Policy Setting Done Flag to N flags the activity record for this recipient as requiring additional attention. If the Policy duration is set to 14 days and Done Flag is equal to N, then the policy executes in 14 days. Members of the target audience who did not respond to the first campaign are assigned to a new campaign after 14 days.
400
16 Administering a Workflow Policy

This chapter describes how to administer a workflow policy. It includes the following topics: Administering a Workflow Policy on page 401 Testing, Troubleshooting, and Migrating a Workflow Policy on page 440
Administering a Workflow Policy

This topic describes administration work that is relevant to workflow policies. It includes the following topics: Confirming the Installation of Workflow Policies on page 401 Administering Database Triggers on the Workflow Policy Server on page 402 Administering Email Manager and Page Manager on page 409 Executing a Workflow Policy with the Workflow Action Agent on page 415 Executing a Workflow Policy with Workflow Monitor Agent on page 417 Defining a Workflow Policy to Run in Batch Mode on page 428 Moving a Workflow Policy to a Different Group on page 431 Expiring a Workflow Policy on page 432 Deleting a Workflow Policy That Is Obsolete on page 434 Tracing and Reporting a Workflow Policy on page 436 Guidelines for Converting a Workflow Policy to a Workflow Process on page 439
Confirming the Installation of Workflow Policies

In this topic, you make sure workflow policies are installed correctly. The Workflow Policies module is installed as part of the Siebel Server and client installation and is activated by using your license key. This topic only describes how to make sure Workflow Policies is correctly installed. For information about the installation process, see the installation guide for the operating system you are using. To use Workflow Policies, make sure Siebel Server components, including Workflow Management, Siebel Tools, and the Siebel client, are installed.
40 1
Administering a Workflow Policy Administering a Workflow Policy
Confirming the Repository Setting for An Installation of Workflow Policies

In the Siebel client, the cfg file is used to configure the Workflow Policies module. You must make sure the DockRepositoryName parameter of this cfg file specifies the correct repository name.
Confirming Siebel Workflow is Set Up for Workflow Policies

You must make sure that your license key includes Siebel Workflow. You must also make sure the Siebel Server is installed properly because Siebel Workflow runs as a server component on the Siebel Server.
To confirm Siebel Workflow is set up for workflow policies 1 2

Log in to the Siebel client as the Siebel administrator. Navigate to the Administration-Business Process screen. Under the list of views, the Policies, Policy Groups, and so forth are visible. This visibility indicates that your license key is correct.
3 4
From a Siebel client that is configured to manage the server component groups, navigate to the Administration-Server Management screen, Servers, then the Component Groups view. Make sure the Workflow Management component group is activated.
Administering Database Triggers on the Workflow Policy Server

This topic describes how to administer database triggers on the workflow policy server. It includes the following topics: Overview of Generating Database Triggers on page 403 Generating Database Triggers on page 404 Guidelines for Generating Database Triggers on page 407 Database Triggers and Remote Users on page 407 Database Triggers and Database Administration on page 407 Usage of the S_ESCL_REQ Table on page 408
402
Overview of Generating Database Triggers

The Generate Trigger (GenTrig) component on the Siebel Server allows you to generate database triggers. Workflow Policies uses database triggers to identify which records match workflow policy conditions. You can run the Generate Triggers component when you must perform one of the following: Define or delete new policies, including assignment policies, except for workflow policies with the Batch Flag set to TRUE Amend workflow policy conditions or policy criteria Change activation or expiration dates of policies, including assignment policies
Example of Behavior of Generate Triggers for a Workflow Policy That Contains Multiple Conditions If two or more workflow policy conditions are used in a workflow policy, then Generate Triggers uses OR logic instead of AND logic. Table 65 describes example workflow policy conditions to use in order to create a workflow policy that is based on the Account object.
Table 65. Property
Example of Workflow Policy Conditions Condition 1 Account Modification Num > 0 Condition 2 Account Last Update By <> 0-1
Condition Field Operation Value
Multiple database triggers that are generated for multiple workflow policy conditions of one workflow policy is expected behavior. This technique separates the functionality of Generate Triggers and Workflow Monitor Agent. Generate Triggers simply monitors changes that are made to database records and inserts records into tables that are specific to a workflow policy. Workflow Monitor Agent evaluates violations, determines if the conditions that are associated with the rule for the violation are met, and executes the actions that are associated with a policy. You cannot use AND between database triggers that are generated for multiple workflow policy conditions of a workflow policy, because Generate Triggers can monitor only database changes, and database changes that violate different conditions might not be concurrent. Therefore, using an AND condition causes Generate Triggers to miss many violations. For example, assume a workflow policy contains the following workflow policy conditions: SR area is Network Activity Priority is 1-ASAP
Two database triggers are generated. One database trigger monitors an SR that is created or updated, and checks if the area equals Network. The other database trigger monitors an activity that is created or updated, and checks whether the Priority equals 1-ASAP.
40 3
But if you use AND database triggers and an end user creates an SR without an activity, then the database trigger is not violated because the activity does not exist. If later, a user adds an activity to the SR, then there still is no database trigger violation because the SR record does not change. This violation is missed due to use of AND logic. However, if you use OR for the database triggers and Workflow Monitor Agent evaluates the workflow policy condition, even though there are multiple violations in the S_ESCL_REQ table, then the Workflow Monitor Agent only processes one request because the other requests do not evaluate to TRUE.
Generating Database Triggers

This topic describes how to generate database triggers with the Generate Triggers server component. You can run the Generate Triggers server component from the Siebel client or from the command line. Both the Siebel client and the command line use the same parameters. The database triggers are only there in order to generate indicators for the Workflow Engine to check conditions for the policies. CAUTION: If you incorrectly define a workflow policy condition, then running Generate Triggers can result in an invalid database trigger. An invalid database trigger can prevent execution of normal user transactions. For this reason, thoroughly test your workflow policy in a test environment before you migrate it to a production environment.
To generate database triggers 1

Make sure you meet the prerequisites for running the Generate Triggers server component.
a b
Make sure the Siebel Server is installed. Make sure the Siebel client is configured to access the Siebel Server Administration screens.
For more information on installing Server Manager, see the installation guide for the operating system you are using.
2 3 4
In the Siebel client, navigate to the Administration-Server Management screen, then the Jobs view. In the Jobs list, click New. In the drop-down list for the Component/Job field, choose Generate Triggers. This step creates a new line entry but does not start the server task.
404
In the Job Parameters list, click New to modify component specific parameters, using values from the following table. Name Remove Value TRUE or FALSE (default) Valid filename on the Siebel Server Usage Set to TRUE in order to generate DROP TRIGGER statements to clean up the database triggers. Remove does not generate CREATE TRIGGER statements. Define the name and output location for the SQL script file. The default is TRIGGER.SQL. The file is generated, then placed in the root directory of the Siebel Server during installation. Set to TRUE in order to run the SQL script file automatically. Set to FALSE in order to run the SQL script manually. For more information, see Usage of the EXEC Parameter on page 406. Mode ALL, WORK, or ASGN The following settings are available for the Mode parameter: Privileged User Name and Privileged User Password Assigned Privileged User name and password ALL. Generates database triggers for workflow policies and Assignment Manager. WORK. Only generates database triggers for workflow policies. ASGN. Only generates database triggers for Assignment Manager.
Trigger File Name
EXEC
TRUE or FALSE (default)
Define the user name and password in order to make sure the end user enters a Privileged User name and password. The Table Owner is considered a Privileged User, so you can enter the Table Owner name and password in the Privileged User name and password fields.
For a description of generic and enterprise parameters, see Siebel System Administration Guide.
6 7 8
Enter the Privileged User name and password. In the Job Detail form, from the applet-level menu, choose Start Job. To view changes to the state, refresh the screen by clicking Run Query from the applet menu. Upon completion, the Status field contains Success or Error. You can view the log details.
(Conditional) If EXEC equals FALSE, then you must manually run the SQL script file. For more information, see Manually Running the SQL Script File on page 406.
40 5
Usage of the EXEC Parameter The EXEC parameter specifies whether the SQL script file runs automatically or manually. If TRUE, then the Generate Trigger server component automatically generates the SQL script and applies it to the server database. If FALSE, then you must manually run the SQL script file. Environments in which you must set EXEC to FALSE include: You run a Sybase server with a Siebel or MS_SQL server. Setting EXEC to false prevents an end user who is connected from receiving an error message when Siebel generates database triggers. Make sure nobody is logged in to the database before you generate database triggers. When you define a large number of database triggers because there are too many workflow policies.
In both cases, you must manually run the SQL script file and not use the Generate Triggers server component. For more information, see Manually Running the SQL Script File on page 406.
Manually Running the SQL Script File After Generate Triggers finishes, if the EXEC parameter is FALSE, then run the SQL script file.
To manually run the SQL script file 1

Use the SQL tool provided by your RDBMS vendor to connect to the database server as the Siebel table owner. For example, ISQL for Microsoft or SQL*Plus for Oracle.
Run the SQL script file that is defined by the Trigger File Name parameter. The default filename is TRIGGER.SQL. The default location of this file is the root of the directory in which the Siebel Server is installed. For example: C:\siebsrvr\trigger.sql If you are using an MS SQL server database, then execute the trigger.sql script as the database owner login for the Siebel database. The database owner login is also known as the dbo login.
Make sure no errors are reported. For example, assume you finished defining workflow policies in the Siebel client and you must set the database triggers in the Siebel database for the new policies. Using the Generate Triggers component, you set the file output name, thus creating a TRIGGER.SQL file that contains the database triggers that must be modified or defined in the test database for these policies. You then run the following command in SQL*Plus to generate the database triggers in the Oracle database: SQL>@<path>\mytrig.sql The successful creation of each database trigger in the Oracle database is indicated on the screen. For information on the syntax that is required for other databases, see your database documentation.
406
Guidelines for Generating Database Triggers

Guidelines for running the Generate Triggers server component, especially if you are deleting a workflow policy, include: If deleting a workflow policy, then running Generate Triggers does not remove the database trigger. If you delete a policy, then you must run Generate Triggers with the remove parameter set to TRUE, thus removing every database trigger. You must then rerun Generate Triggers in order to reset the database triggers for existing policies. You must stop and restart the workflow monitor agents when running Generate Triggers. If you change a workflow policy condition or a workflow policy group, then you must rerun Generate Triggers. It is not necessary for you to rerun Generate Triggers when you change a workflow policy action. For more information, see Moving a Workflow Policy to a Different Group on page 431. For SQL Server, set your default database correctly. To determine your default database, launch the SQL Server Enterprise Manager, then navigate to the SQL Server Machine name. Next, click Security, then click LOGIN. The default database is listed to the right. If you drop or regenerate database task triggers, then you must start a new Workflow Monitor Agent server, thus refreshing the cache for the Workflow Monitor Agent in order to account for the new changes in the monitored policy. If a table name exceeds 18 characters, then Generate Triggers fails with the error 18 character limit, table_name trigger fail. When running Generate Triggers, there is an 18 character limit for table names. This error is caused by a DB2 SQL limitation for database trigger names that are limited to 18 characters. The name of the database trigger is derived from the table name plus a suffix, such as U, I, D, U1,I1,D1, and so forth.
Database Triggers and Remote Users

When a remote user synchronizes, the changes are incorporated into the database. For example, account information in the S_ORG_EXT table is updated upon synchronization. If you run a workflow process that generates database triggers which compares changes in the database against a specific workflow policy condition, and if the changes are of interest to the condition during synchronization, then the database triggers fire and rows are written to the S_ESCL_REQ table.
Database Triggers and Database Administration

It is important to keep your database administrators informed of database triggers that are active for a workflow process, because a database Update or Insert event causes the database trigger to react, regardless of how the event is executed. For example, if there are inserts to the S_SRV_REQ table, and if the database administrator performs a table export and import of these records, then the database triggers treat every record in the database as if it is a newly inserted record, which can result in an inappropriate modification to old records that were simply imported again. NOTE: With the 8.1 release, the Generate Triggers server task requires the Privileged User Name and Password instead of Table Owner ID and Password.
40 7
Usage of the S_ESCL_REQ Table

If a database trigger fires against a workflow policy condition, then a record is inserted in the S_ESCL_REQ table, which is the escalation request table. This table contains the rows in the database that can cause a workflow policy to execute. After the Workflow Monitor Agent processes a request, it removes the row from this table. Frequently, because of the way database triggers are generated, the logic that is defined in the condition for a workflow policy is not included on the database trigger itself. Also, the conditions in the database trigger file might not be indicative of the workflow policies that are violated. When Workflow Monitor Agent is run, the records in the S_ESCL_REQ table causes Siebel Workflow to evaluate the conditions for the related policy. Therefore, the database triggers are only there to generate indicators for the Workflow Engine to check the conditions for the workflow policy. For more information about how the S_ESCL_REQ table is used, see Workflow Monitor Agent on page 417.
Remedies to Address Problems That Involve the S_ESCL_REQ Table Remedies to avoid or fix problems in the S_ESCL_REQ table include: Use your database tools to monitor the size and efficiency of the table.

If the table is very large, then this situation indicates that too many policies are monitored and a new process for workflow policies must be defined in order to share the load. If rows are monitored and not removed after the time interval is met, then this situation can indicate that a policy was deactivated without removing the database triggers. The database triggers are continuing to send data that is not acted on by an instance of a workflow policy.
If defining a new business component, then do not set the Table property to the S_ESCL_REQ table. A business component cannot be based on the S_ESCL_REQ table. Expire, rather than delete a workflow policy. For more information, see Expiring a Workflow Policy on page 432. Remove rows that belong to obsolete workflow policies. For more information, see Deleting a Workflow Policy That Is Obsolete on page 434.
408
Administering Email Manager and Page Manager

This topic describes how to administer email manager and page manager. It includes the following topics: About Setting Up the Siebel Server for Email Manager on page 409 Setting Up the Communications Profile to Send Email Through a Workflow Process on page 409 Starting Email Manager on page 410 Running the Page Manager Server Component on page 411 Parameters of the Page Manager Server Component on page 413 Troubleshooting Email Manager and Page Manager on page 414
About Setting Up the Siebel Server for Email Manager

Some actions for a workflow policy allow you to send an email message to a specific individual. Items to consider include: If sending email using a workflow policy through a mail system that is compliant with SMTP or POP3, then make sure that SMTP and POP3 are working properly on the network. Make sure the Email Manager component of the Siebel server is running. This component is part of the Communications Management component group, which must be configured. Make sure the profiles that are set up in the Communications Manager are configured correctly to log in to a mail system that is compliant with SMTP or POP3. Email Manager uses these profiles. The Communications Outbound Manager verifies the profile. Make sure the Mail Profile parameter is set to the name of the communication profile you use for sending the email.
Date Format in an Email Message A workflow policy program is executed by the Siebel server, which connects to Oracle through ODBC. As part of this process, the required data is retrieved from the database through this connection. The format of a date in an email message is the format returned from the ODBC driver, which might be different from that used by Oracle.
Setting Up the Communications Profile to Send Email Through a Workflow Process

Sending email through Siebel Workflow involves defining a communications profile. NOTE: To define a new communications profile, CompGrp CommMgmt must be configured. Make sure it is configured before you perform the procedure described in this topic. For more information, see Siebel Communications Server Administration Guide.
40 9
To set up the communications profile to send email through a workflow process 1 2 3 4 5

In the Siebel client, navigate to the Administration-Communications screen, then the Communications Drivers and Profiles view. In the Communications Drivers list, query the Name field for the Internet SMTP/POP3 Server communications driver. Click the Profiles view tab. Define a new profile named [Profile Name]. In the Profile Parameters Overrides list, define records for parameters using values from the following table. Parameter From Address POP3 Account Name POP3 Account Password POP3 Server Usage Define the email address of the sender for outbound communications. Define the account name for the POP3 mailbox from which to retrieve inbound communications. Define the password for the POP3 mailbox account. Define the host name or IP address of the machine on which the Internet POP3 server is running, as appropriate for your network configuration. Define the host name or IP address of the machine on which the Internet SMTP server is running, as appropriate for your network configuration.
SMTP Server
For details on these parameters, see Siebel Communications Server Administration Guide. After you define the communications profile, you must define the component definition of Email Manager. The Email Manager component executes email actions after the conditions of a workflow policy are met.
Starting Email Manager

You can start Email Manager from the command line or from the Server Configuration view in the Siebel client.
To start Email Manager from the command line

To start the Email Manager server task with the [Profile Name] profile, issue the following command in the server manager command line: start task for comp MailMgr with MailProfile=<Profile Name>
410
To start Email Manager from the server configuration view 1 2 3 4

Navigate to the Administration-Server Configuration screen, Servers, then the Components view. In the Components list, locate the Email Manager component. In the Component Parameters list, set the Mail Profile field to Test. Set the Default Tasks component parameter to 1. This step automatically begins a server task for Email Manager when the component is restarted or when the Siebel Server services are restarted.
How Outbound Communications Manager Sends Email The Outbound Communications Manager sends email messages according to the following sequence:
1 2 3 4
If the workflow policy is violated, then Workflow Monitor Agent inserts a record into the S_APSRVR_REQ table for workflow actions that call the Send Email workflow policy programs. Email Manager picks up records from the S_APSRVR_REQ table, setting the status for each record from QUEUED to ACTIVE, then to SUCCEEDED during the course of the execution. Outbound Communications Manager is called to log onto the [Profile Name] profile. Outbound Communications Manager uses the Send Message method of the Outbound Communications Manager business service in order to send emails to recipients.
Mail Profile Parameter The Mail Profile parameter specifies the mail profile to use and is defined in the Control Panel. The parameter establishes the connection between the application and the email system. If you do not define a profile, then the default profile is used. The names must match exactly.
Running the Page Manager Server Component

Some workflow policy actions allow you to send a page message to a specific individual. The Page Manager server component of the Siebel server must be running in order for you to send a page. You can page a specific individual who uses an alphanumeric or numeric pager. Prerequisites to send a page using a workflow policy include: Access to a local or network modem is provided for the server that is running the Page Manager component. The Page Manager component of the Siebel server is running. Several parameters, similar to the dial-up networking set up in Windows, must be set prior to running the Page Manager component. The appropriate telephone numbers for paging are entered in the Employee view. These numbers are used by Siebel Workflow. The regional configuration is changed in order to avoid inputting the country code prior to the telephone number. Inputting the country code prior to inputting the telephone number can cause an error.
41 1
The PAGE_TYPE list of values parameters is changed in order to force the page manager to accept an alphanumeric send, thus displaying the language and the value.
NOTE: Alphanumeric paging is more reliable than numeric paging because the pager message is transmitted by a computer that resides at the company that provides pager services. This situation is not true for numeric paging, where a pager message is sent by emulating key presses on a telephone. A failure in sending a numeric pager message is very difficult to detect. The Page Manager component uses the Telocator Alphanumeric Protocol (TAP) industry standard protocol for alphanumeric paging. To determine the phone number in which to send your alphanumeric page, check with the company that provides pager services. Several parameters affect how the Page Manager component interacts with the modem. The parameters that can be changed are listed in the Server Administration screen. The modem parameters are the defaults for Hayes compatible modems. Make sure the settings are compatible with your modem.
To run the Page Manager server component 1 2 3 4 5

In the Siebel client, navigate to the Administration-Server Management screen, then the Jobs view. In the Jobs list, click New. In the drop-down list for the Component/Job field, choose the Page Manager server component. In the Job Parameters list, click New. Click Parameters in the Server Tasks list, then enter your parameters. For a list of parameters, see Table 66 on page 413.
412
Parameters of the Page Manager Server Component

The most important parameters are Modem Port, Dial Prefix, Long Distance Prefix, and Local Area Code. Change the values for these parameters to match your system. Table 66 describes default values that are used if you do not define a parameter.
Table 66.
Parameters of the Page Manager Server Component Description The Component Object Model (COM) port where the modem is attached. Default is COM1. Usage Valid values are COM1, COM2, and so forth.
Parameter Modem Port
Dial Prefix
A number or sequence of numbers that must be dialed in order to acquire an outside line. Default is 9.
If no dial-out prefix is used, then insert a comma (","). If dialing 9 for an outside line is not required, and if you are using srvrmgr.exe from the command line, then defining a comma for this parameter returns an error. However, if you define a hyphen, or another character that cannot be dialed, then an error is not returned. The following is an example command: SRVRMGR.EXE /g NT01022 /e SBLPRD_ENT502 / s SBLPRD_APP502 /u ***** /p ***** /c "START TASK FOR COMPONENT PageMgr WITH DialPrefix = '-'"
Long Distance Prefix Local Area Code
The long-distance prefix. Default is 1.
This value is added in front of long-distance phone numbers. If your location does not require a longdistance prefix to be dialed, then set this parameter to equal an empty string. If the beginning digits of a phone number are equal to this code, then they are removed before the phone number is dialed, and the long-distance prefix is not added. Applies only to numeric paging. It is ignored for alphanumeric paging.
The area code of your location. Default is [empty].
Delay1
The number of seconds to wait between dialing a phone number and simulating key presses for the first set of numbers. Default is 12.
41 3
Table 66.
Parameters of the Page Manager Server Component Description The number of seconds to wait between simulating key presses for the first and second set of numbers. Default is 4. Usage Applies only to numeric paging. Situations in which it is ignored include: Alphanumeric paging When the numeric pager does not contain a Personal Identification Number (PIN)
Parameter Delay2
Modem Reset String
The modem command that is used to reset the modem. Default is ATZ.
To determine the correct command, see your modem documentation.
Modem Init String
The modem command that is used to initialize the modem. Default is AT&FQ0V1.
To determine the correct command, see your modem documentation. For example, some modems require a numeric value after &F. This parameter is rarely changed.
Modem Dial String
The modem command that is used to dial the modem. Default is ATDT.
Modem Hangup String Modem Restore String
The modem command that is used to hang up the modem. Default is ATH. The modem command that is used to restore the power-up settings of the modem. Default is AT&F.
This parameter is rarely changed.
This parameter is rarely changed.
Troubleshooting Email Manager and Page Manager

When troubleshooting Email Manager and Page Manager, note the following situations: If Email Manager is unable to log on to the mail server that is compliant with SMTP or POP3, then Email Manager stops processing and logs an error message in the trace files. If Email Manager is able to log on but encounters a problem sending a particular email, then it logs an error message and continues on to the next request. If the modem is not available, then Page Manager stops processing. The requests continue to accumulate in the Requests table. After you fix the processing problems, you must restart the servers. The servers continue processing from the point where they were interrupted. If Page Manager is able to interface with the modem but encounters a problem with a page send, then it logs an error and moves on to the next request.
414
If a workflow policy executes email and paging actions, then it inserts email requests and paging requests into the database. These requests are inserted as records in the S_APSRVR_REQ table, which are then processed by Email Manager and Page Manager. New requests contain a status of QUEUED. After a request is picked up by Email Manager or Page Manager, but before it is processed, it contains a status of ACTIVE. After a request is processed, the status for the request is SUCCEEDED if the processing is successful, or FAILED if an error occurs.
To generate sending emails, Siebel Server uses the UNIX Mail command.
Making Sure the Server Platform Can Run the Command to a Valid Recipient This topic describes how to make sure your server platform can run the command to a valid recipient, and to make sure email was successfully sent.
To make sure the server platform can run the command to a valid recipient 1
From the UNIX command prompt, type the following command: >mail recipient email address where:
recipient email address is a valid address
2 3 4
Type a message that ends with a period on the last line to indicate the end of the message. Press enter. If email that is written to the S_APSRVR_REQ table is not sent, even though the Email Manager trace file displays status SUCCEEDED, then make sure the following Outlook settings on the server are set:

Send messages immediately Check for new messages every [x] minutes
Both of these options must be configured in Outlook in order for an email message to be sent successfully.
Executing a Workflow Policy with the Workflow Action Agent

The Workflow Action Agent process submits a request to Email Manager and Page Manager when an action is to be executed. NOTE: You must define a component definition for each Workflow Action Agent server task. Work performed by Workflow Action Agent includes: Processes requests that are logged in the S_ESCL_ACTN_REQ table for a single group. The S_ESCL_ACTN_REQ table is the escalation action request table.
41 5
Calls actions that are linked with the workflow policy that is processed for Siebel Workflow. Logs email and page actions in the S_APPSRVR_REQ table for execution by Email Manager and Page Manager. Purges requests from the S_ESCL_ACTN_REQ table after processing.
If the Use Action Agent parameter is set to TRUE in the Monitor Agent process, then you must perform the work described in Starting the Workflow Action Agent on page 416.
Starting the Workflow Action Agent

Start the Workflow Action Agent in the same way that you start the Workflow Monitor Agent. For more information, see Defining a New Workflow Monitor Agent Server Component on page 419. Guidelines for starting the Workflow Action Agent include: For each Workflow Monitor Agent, there is a Workflow Action Agent. For each Workflow Monitor Agent, start only one Workflow Action Agent. If using email consolidation, and if the Use Action Agent parameter is set to TRUE on the Workflow Monitor Agent, then you must start Workflow Action Agent separately.
For more information on starting Workflow Action Agent, see Siebel System Administration Guide.
Shutting Down the Workflow Action Agent

You shut down the Workflow Action Agent in the same way that you shut down the Workflow Monitor Agent. For more information, see Defining a New Workflow Monitor Agent Server Component on page 419. If restarting a workflow policy process, then a Workflow Action Agent process immediately begins tracking relevant activities that occurred since it was shut down.
Using Workflow Action Agent for Batch Policies

You can run Workflow Action Agent separately for batch policies.
To use workflow action agent for batch policies 1

Start Workflow Monitor Agent with the following parameters:

Group Name Processes the batch policies is TRUE Use Action Agent is TRUE
416
Start Workflow Action Agent with the Group Name parameter. The Workflow Monitor Agent continues processing, and puts the qualified rows in the S_ESCL_ACTN_REQ table. The Workflow Action Agent executes actions for rows in the S_ESCL_ACTN_REQ table, and deletes the rows from the S_ESCL_ACTN_REQ table afterward. If the executed action persists for a long time or is intensive, then the Workflow Action Agent might be of use. However, in general, Workflow Action Agent does not help with a batch policy.
Executing a Workflow Policy with Workflow Monitor Agent

This topic includes the following topics: Workflow Monitor Agent on page 417 Replication with the Workflow Monitor Agent on page 419 Starting Workflow Monitor Agent on page 419 Stopping or Restarting a Component of the Workflow Monitor Agent on page 421 Keeping Definitions for Workflow Monitor Agent Current on page 422 Command Line Interface Parameters of the Workflow Monitor Agent on page 423
Workflow Monitor Agent

Workflow Monitor Agent checks when the conditions of a workflow policy is met, and executes actions after conditions are met. To execute your workflow policies, you must start Workflow Monitor Agent. You start and stop the Workflow Monitor Agent server task in the Administration-Server views. Table 67 describes some of the database tables that are involved with workflow policies.
Table 67.
Database Tables That Are Involved with Workflow Policies Description Escalation request. This table holds the potential matching requests that are caused by an application. For more information, see Usage of the S_ESCL_REQ Table on page 408. Escalation state. This table holds the policy matches that are based on time. Escalation action request. (Optional) This table holds the requests to execute actions, which is only used when Use Action Agent is set to TRUE. Escalation log. This table holds a history of rows in the base table with matched policies.
Table Name S_ESCL_REQ
S_ESCL_STATE S_ESCL_ACTN_REQ S_ESCL_LOG
41 7
Work Performed by the Workflow Monitor Agent Workflow Monitor Agent executes several server processes that monitor the Siebel database. Work performed by Workflow Monitor Agent includes: Checks the S_ESCL_REQ table to determine when the conditions of a policy are met. Monitors policies within a single group. You can only run one process of the Workflow Monitor Agent against a specific group at one time. You can run multiple processes of the Workflow Monitor Agent at the same time, but they must be against different groups. If you run two processes of the Workflow Monitor Agent against the same group, then a deadlock can occur. Generates requests for Workflow Action Agent in the S_ESCL_ACTN_REQ table. This situation occurs if you set Action Agent to True. Purges requests from the S_ESCL_REQ table after processing. If a database trigger is activated because a workflow policy condition is met, then a record is inserted into the S_ESCL_REQ table, which is the escalation request table. Workflow Monitor Agent (WorkMon) evaluates the request against the rules that are established by the policies in the workflow policy group.
If you set Action Agent to True, and if Workflow Monitor Agent determines that the request in the S_ESCL_REQ table contains no duration defined in the policy, then the Workflow Monitor Agent takes direct action and logs an entry into the S_ESCL_LOG table or sends it to the S_ESCL_ACTN_REQ table. If Workflow Monitor Agent determines that the request includes a time element that must be met, then the request is sent to the S_ESCL_STATE table along with the expiration time. The request remains in the S_ESCL_STATE table until the expiration time is met, or until the request is removed because the conditions of the policy are no longer met. Workflow Monitor Agent evaluates each of the requests that remains in the S_ESCL_STATE table for a time duration match or to determine if the condition still matches in the S_ESCL_STATE table. If you set Action Agent to True, then as each match occurs, Workflow Monitor Agent takes direct action and logs an entry into the S_ESCL_LOG table or sends it to the S_ESCL_ACTN_REQ table. NOTE: If a workflow policy contains a defined duration, then the duration time is calculated from the time Workflow Monitor Agent detects that the row is in violation of the policy, not from the time the row was inserted into the S_ESCL_REQ table. For example, if you define a policy and set the duration as one week, but then Workflow Monitor Agent is not started until several days after Generate Triggers is run, then the policy action fires one week from when Workflow Monitor Agent is started, not one week from when the policy is created or Generate Triggers is run. If the request for an action is made to the S_ESCL_ACTN_REQ table, then Workflow Action Agent executes the action and logs an entry into the S_ESCL_LOG table.
418
REQ_ID Column of the S_ESCL_REQ Table The REQ_ID column of the S_ESCL_REQ table (S_ESCL_REQ.REQ_ID) can hold up to 9 digits, so the maximum value allowed is 999,999,999. Because the S_ESCL_REQ_S sequence does not contain an upper boundary, the sequence for S_ESCL_REQ.REQ_ID can potentially generate a number that is greater than the maximum of the allowed 9 digits, causing an overflow. To avoid this situation, it is recommended that you perform one of the following work items: Use a database tool to increase the column size Use a database tool to reset the S_ESCL_REQ_S sequence
As a separate issue, you might encounter a message similar to Status: Deleting requests ([a numeric identifier]). This message does not indicate the number of rows that Workflow Monitor Agent is deleting. The numeric identifier indicates the REQ_ID from the S_ESCL_REQ table, which is generated by the database to uniquely number the rows in the database. For example, the ways in which REQ_ID is generated include: From the Sequence object in an Oracle database From the identity column in an MS SQL Server database From the User Defined Function (UDF) in a DB2 database
There is no correlation between REQ_ID and the number of rows in the S_ESCL_REQ table.
Replication with the Workflow Monitor Agent

Within the entire enterprise architecture of a Siebel deployment, there can be only one Workflow Monitor Agent monitoring a particular workflow group. For example, a regional node can run a Workflow Monitor Agent that monitors a group named Group 1. Meanwhile, in the headquarters, there is another Workflow Monitor Agent running that monitors a group named Group 2. In this way, the organization can run workflow policies where required, while working with the restriction of one Workflow Monitor Agent for one group. You cannot run more than one instance of Workflow Monitor Agent and Workflow Action Agent for a particular workflow group. However, multiple Workflow Monitor Agent and Workflow Action Agent processes are allowed for different groups that run at the same time.
Starting Workflow Monitor Agent

To start the predefined Workflow Monitor Agent, you begin by defining a separate server component for each Workflow Monitor Agent server task. You then start Workflow Monitor Agent from the server manager command line interface.
Defining a New Workflow Monitor Agent Server Component In releases prior to Siebel CRM version 7.0, you can start Workflow Monitor Agent from the Server Tasks view in the Server Manager user interface. This situation no longer applies. Beginning with Siebel version 7.0, you must start Workflow Monitor Agent from the Server Manager command line interface.
41 9
To define a new workflow monitor agent server component 1 2

In the Siebel client, navigate to the Administration-Server Configuration screen, Enterprises, then the Component Definitions view. In the Component Definitions list, define a new record using values from the following table. Field Name Component Type Component Group Description Alias Description Name of the component. [Workflow Monitor Agent] Choose an existing component group. Description of the component. Alias for the component. The alias cannot contain blank spaces.
3 4 5
Save the record. In the Component Parameters list, choose the Group Name parameter record, then enter the name of the workflow policy group for which this component handles requests. (Optional) Make additional changes to the component parameters. For more information, see Command Line Interface Parameters of the Workflow Monitor Agent on page 423.
In the Component Parameters list, choose the Default Tasks parameter record, then set the Value to 1. This component automatically starts up and shuts down with the Siebel Server. Do not set Default Tasks to a value greater than 1. Setting Default Tasks to a value greater than 1 can cause undesirable behavior, such as multiple server tasks starting for the same workflow group.
In the Component Definitions list, choose Enable Component Definition from the applet menu. The definition state changes from Creating to Active.
Stop, then restart the Siebel Server so that the component definition goes into effect. When you make a change to a component parameter, the component must be stopped and restarted in order for the changes to go into effect. Also, you must define a Workflow Monitor Agent component definition for each workflow policy group.
Next, start the workflow monitor agent.
420
Starting the Workflow Monitor Agent You use the server manager CLI to start the Workflow Monitor Agent. CAUTION: If a Workflow Process Manager server task fails, and if more server tasks are started that also fail, then Workflow Monitor Agent exits with error after only one violation. This situation can result in Workflow Monitor Agent starting more server tasks that are not required when the Workflow Process Manager server task fails. To avoid this situation, stop, then restart Workflow Process Manager. For more information, see Command Line Interface Parameters of the Workflow Monitor Agent on page 423. For more information on using the Siebel Server Manager Command Line Interface, see Siebel System Administration Guide.
To start the workflow monitor agent 1

Start the server manager by entering the following command into the Server Manager CLI: srvrmgr /g <gateway server address> /s <Siebel Server name> /e <enterprise server name> /u <server administrator username> /p <server administrator password>
Start a new Workflow Monitor Agent server task in background mode by entering the following command: start task for component WorkMon with SleepTime=<time>,GroupName=<group name>
(Optional) Start a new Workflow Monitor Agent server task to run in batch to process a Batch policy by entering the following command: start task for component WorkMon with GroupName=<group name>, BatchMode=Y
You must define a separate server component definition for each Workflow Monitor Agent server task.
Stopping or Restarting a Component of the Workflow Monitor Agent

You can stop or restart a Workflow Monitor Agent component.
To stop or restart a component of the workflow monitor agent 1 2

In the Siebel client, navigate to the Administration-Server Management screen, then the Components view. Choose the component, then click Shutdown or Startup.
NOTE: If you make changes to the parameters of the component, then the component must be stopped and restarted for the changes to go into effect. Also, you must define a component definition of the Workflow Monitor Agent for each workflow policy group.
42 1
Keeping Definitions for Workflow Monitor Agent Current

Workflow Monitor Agent and Workflow Action Agent read workflow configurations from the server database. If you use Siebel Tools to modify a workflow policy object, column, or program in the local database, then you must check these objects into the server database. Otherwise, Workflow Monitor Agent and Workflow Action Agent possess no knowledge about these modifications. Also, situations in which you must restart Workflow Monitor Agent and Workflow Action Agent include: After using Siebel Tools to modify an object, column, or program for a workflow policy After using the workflow administration views in the Siebel client to modify a workflow action
If you do not restart Workflow Monitor Agent and Workflow Action Agent, then the modifications do not go into effect until policies are reloaded, as defined in the Reload Policy parameter. Because the Reload Policy parameter is set to 600 seconds by default, in most cases 10 minutes elapse before the modifications go into effect if you do not perform a restart. It is not necessary to restart the Workflow Process Manager when modifying a workflow process. For more information, see Modifying a Workflow Process on page 118. For more information about checking in and checking out objects, see Using Siebel Tools.
To keep definitions for Workflow Monitor Agent current 1 2

Use the Project check in feature in Siebel Tools to check modifications made to a workflow policy object, column, or program into the server database. When necessary, restart Workflow Monitor Agent and Workflow Action Agent. For more information, see Stopping or Restarting a Component of the Workflow Monitor Agent on page 421.
422
Command Line Interface Parameters of the Workflow Monitor Agent

Table 68 describes parameters that can be set by using the Workflow Monitor Agent command line interface. Table 68. Command Line Interface Parameters of the Workflow Monitor Agent Display Name Use Action Agent Usage Defines whether the Action Agent is automatically run with Monitor Agent. If set to the default FALSE, then the Workflow Action Agent server component starts within Workflow Monitor Agent, and actions are then executed by Workflow Monitor Agent. Several factors apply when configuring Use Action Agent. For more information, see Setting the Use Action Agent Parameter on page 428. ActionInterval Action Interval Defines the action execution interval in seconds. This argument determines when actions for a policy are executed again on the row of a base table. The purpose of this argument is to limit the number of times an action is executed if a row continues to go in and out of a matching state. In other words, if the same record repeatedly violates the same policy before the action interval expires, then the record is removed from the S_ESCL_REQ table and the action is not performed again. The default is 3600 seconds. If this parameter is used, then the value must be greater than 0 (zero) or unexpected behavior can result. BatchMode Processes the batch policies Defines whether Monitor Agent runs in batch mode. If BatchMode is set to TRUE, then only those policies with the Batch flag set to TRUE are evaluated. If FALSE, then only those policies with the Batch flag set to FALSE are evaluated. If starting with BatchMode set to TRUE, then Workflow Monitor Agent is run one time. That is, it processes records in the table, then exits. FALSE 3600 Default Value FALSE
Parameter Name ActionAgent
42 3
Table 68.
Command Line Interface Parameters of the Workflow Monitor Agent Display Name Cache size of Policy violations Usage Defines the number of policy violations to store in the cache. The Cache size of Policy violations parameter determines how many violated policies can be stored in the cache. Based on the presence of the ROW_ID and RULE_ID in the map or cache, the cache determines whether or not an action is already initiated. The Workflow Monitor checks the S_ESCL_LOG table for policy violations for the same BT_ROW_ID and RULE_ID. Default Value 100
Parameter Name CheckLogCacheSz
DeleteSize
Request delete size
Defines the number of records to commit at a time. The minimum is 1. If Workflow Monitor encounters a deadlock, then you can reduce the default from 500 to 125 with minimal performance degradation. To avoid a call stack error, do not set Request delete size to zero.
500
GenReqRetry
Number of seconds to retry Group Name
Defines the number of seconds to retry sending a Generic Request message. Required. Defines the workflow policy group on which Monitor Agent works.
120
GroupName
Not applicable
424
Table 68.
Command Line Interface Parameters of the Workflow Monitor Agent Display Name Ignore errors Usage Defines whether to ignore errors while processing requests. By default, the Workflow Monitor Agent and Workflow Action Agent do not ignore errors that occur while processing the requests. If Ignore errors is set to TRUE, and if an error is encountered, then the agent logs the error, deletes the request, and then continues working. If Ignore errors is set to FALSE, then the agent exits on an error and sends an email message to the mail ID that is defined in the argument of the Mailing Address. If Ignore errors is set to TRUE, then valid errors are ignored. If Ignore errors is set to FALSE, then the agent stops and exits with the error. NOTE: It is recommended that you set Ignore errors to FALSE so that valid errors are not ignored. Default Value FALSE
Parameter Name IgnoreError
KeepLogDays
Number of days to keep violation information
Defines the number of days of violation information that are retained in the log. Log information that is older than the value in Number of days to keep violation information is automatically removed. This value can be set to 0 to prevent the purging of this log information. For more information, see KeepLogDays Parameter and Workflow Monitor Agent on page 428.
30
LastUsrCacheSz
Cache size of last user information
Defines the number of last user information items to cache. If executing actions, then the information about the last user to modify the row of the base table is available as a token substitution in the program arguments. By caching this information in the server, the throughput performance of executing actions can potentially increase. Defines the name of the email server to send notification of abnormal termination.
100
MailServer
Mail Server
Not applicable
42 5
Table 68.
Command Line Interface Parameters of the Workflow Monitor Agent Display Name Mailing Address Usage Defines the mail address to review notification of abnormal termination. If a Workflow Agent process exits with an error, then a mail is sent to [mail ID]. An error can be caused by the failure of an action to execute, invalid object definitions, and so forth. Default Value Not applicable
Parameter Name MailTo
NumRetries
Number of Retries
Defines the number of retries for recovery. If database connectivity is lost, then Number of Retries works in conjunction with the Retry Interval and Retry Up Time parameters to reconnect MTS or Siebel Server components to the database. Defines the policy reload interval in seconds. The Reload Policy parameter defines the frequency that policies are reloaded into the engine, thus allowing a change to be made on the screens and with the Generate Triggers component. The engine acts on the changes within some time frame. The default is 600 seconds.
10000
ReloadPolicy
Reload Policy
600
426
Table 68.
Command Line Interface Parameters of the Workflow Monitor Agent Display Name Requests Per Iteration Usage Defines the maximum number of requests that are read for each iteration. The Requests Per Iteration parameter controls the maximum number of requests that Workflow Monitor Agent reads from the requests queue within one iteration. Between iterations, Workflow Monitor Agent performs the following: Deletes processed requests from the requests queue and commits Optionally reloads policies from the database Checks for shutdown request Optionally sleeps Default Value 5000
Parameter Name Requests
The Requests Per Iteration parameter provides a mechanism to control the maximum amount of work that Workflow Monitor Agent performs before taking these steps between iterations. Sleep Time Sleep Time Defines the time in seconds that the Workflow Agent process sleeps after it polls for events and fulfills obligations to notify. After the Workflow Agent process finishes, the Workflow Agent process stops polling according to the time period set by the sleep interval. This parameter affects both the performance of the Workflow Agent process and the responsiveness of the application server. For more information, see Sleep Time Parameter and Workflow Monitor Agent on page 428. 60
42 7
Setting the Use Action Agent Parameter Table 69 describes situations in which to set the Use Action Agent parameter.
Table 69.
Situations in Which to Set the Use Action Agent Parameter When to Set Use Action Agent to True It is recommended that you start Workflow Monitor Agent with Use Action Agent set to True when executing an action that involves email consolidation. If you use email consolidation and Use Action Agent is set to True, then you must start Workflow Action Agent separately.
When to Set Use Action Agent to False In most cases, it is recommended that you start Workflow Monitor Agent with Use Action Agent set to False, the default setting. This way, Workflow Monitor Agent monitors the situation and executes actions. Some possible actions that are executed include workflow processes, workflow programs, and email programs. If you start Workflow Action Agent to execute actions when Use Action Agent is True, and if the action is executing a workflow process, then you might encounter access violation errors and Workflow Action Agent can fail.
Sleep Time Parameter and Workflow Monitor Agent You can increase the Sleep Time parameter in order to adjust the processing frequency, because the Workflow Monitor Agent server task waits for more requests when it sleeps. Because the default setting is 60 seconds, the server task sleeps every one minute. The Workflow Monitor Agent server task wakes up, processes requests , if there are any, then sleeps. Workflow Monitor Agent performs this work repeatedly.
KeepLogDays Parameter and Workflow Monitor Agent If the Number of Days to Keep Violation Information parameter is set to 0, then Workflow Monitor Agent does not purge from the S_ESCL_LOG table. If you set this parameter to 0, then it is recommended to monitor the size of the S_ESCL_LOG table, because the size of this table affects performance. Use this parameter judiciously. Because infrequent cleaning of the S_ESCL_LOG table can lead to slow performance, decide how often you must start Workflow Monitor Agent using KeepLogDays, then restart Workflow Monitor Agent with a setting of 0 for this parameter.
Defining a Workflow Policy to Run in Batch Mode

The ability to run a workflow policy in batch mode allows you to evaluate more data in the database, and not just the records that called the policy. This feature is useful when you define a new policy that must be applied to historical data, and for enforcing a policy that contains a date condition.
428
To define a workflow policy to run in batch mode 1 2 3 4 5 6

In the Siebel client, navigate to the Administration-Business Process screen, then the Policy Groups view. Create a new Policy Group. In the Name and Comments fields, enter a name and comment that indicates that this group is used for workflow policies that are run batch mode. Navigate to the Administration-Business Process screen, then the Policies view. In the list for the Policies List, query the Name field for the workflow policy you must run in batch mode. In the list for the Policies List, make sure the Batch Mode field contains a checkmark. If you start workflow monitor in batch mode, then it checks for workflow policies with the Batch Mode check box marked. Each policy causes an SQL statement to be issued to identify the specific records that meet the workflow policy conditions. The records identified are then processed in turn and the appropriate actions are carried out.
7 8
In the Policy Group field, associate the workflow policy with the workflow group you created in Step 2. (Optional). Consolidate email messages:
a b
Add a condition in the Conditions list and a corresponding action in the Actions list. In the Actions list, click the Consolidate field to consolidate email messages.
For more information, see Consolidation of Email Messages on page 429.
When you start the Workflow Monitor and Workflow Action server components, define the group name you created in Step 2, and set the parameter Processes the batch policies to TRUE. For more information, see Command Line Interface Parameters of the Workflow Monitor Agent on page 423.
NOTE: If defining a batch workflow policy, then the comparison operators IS ADDED, IS UPDATED, or IS DELETED must be used in conjunction with regular workflow policy conditions. These comparison operators are considered special conditions that are intended for Dynamic mode when triggering rows to look up regular conditions.
Consolidation of Email Messages

You can use the batch feature to consolidate email messages for a designated recipient by checking the Consolidate field in the Actions list in the Workflow Policies view. If you consolidate email messages, then the recipient receives one email with the information of multiple actions rather than multiple emails. For example, you can define a workflow policy that sends an email to the director of sales each time a quote is submitted that includes a discount over 30%. If 20 sales representatives submit quotes that include the 30% discount, and if the Batch Mode field is checked, then the director of sales receives one email listing the 20 quotes. If the Batch Mode field is not checked, then the director of sales receives 20 email messages.
42 9
Using Batch Mode to Make Sure a Workflow Policy Is Triggered Correctly

The following example demonstrates why a previously existing record that meets the workflow policy conditions does not trigger the workflow policy:
Table 70. Field
Example of Records That Meet a Policy But Do not Trigger the Policy Value Account Active Account Test
Workflow Policy Name Workflow Object Group
A workflow policy based on a business object is created to monitor a field when the following situations occur: Workflow Condition, Account Status is Active. Workflow Action, Action: Send Email to Employee. Remove and generate database triggers, then start a workflow monitor server task for the workflow group named Test.
Items to consider include: If a new account is added that meets these requirements, then the workflow policy is called. If an existing account is updated in such a way that these requirements are met, then the workflow policy is called.
NOTE: If an account existed in the database before the workflow policy was defined, and if the account meets the workflow policy requirements, then the workflow policy does not start the workflow process. If database triggers were generated for this workflow policy, then the Workflow Monitor Agent evaluates a record only if it is updated, or if a new record is created. Therefore, old records are not affected. To evaluate an account record that is created prior to the creation of the workflow policy, make sure the Batch Mode flag is checked for the workflow policy, and that the Workflow Monitor Agent is run with Batch Mode set to TRUE.
430
Moving a Workflow Policy to a Different Group

To respond to changes in the business environment or to you configuration, you might find it necessary to change the workflow group for a workflow policy. Before you can move a workflow policy from one group to another group, requests that are associated with that workflow policy must finished. If a group for a workflow policy is changed while an associated request is pending, then Workflow Monitor Agent fails with the error Rule Not Found. If this situation occurs, then restore the workflow policy to the original group for the policy, wait for the request to finish, then proceed with the change. If an existing workflow policy is moved from one workflow group to another workflow group, then the database triggers must be updated. The database triggers contain the RULE_ID and GROUP_ID for the workflow policy. Therefore, if the database triggers were not generated again, then rows exist in the S_ESCL_REQ table that reference the original RULE_ID and GROUP_ID.
To move a workflow policy to a different group 1

Run a Generate Triggers server task to drop database triggers, thus making sure no more rows are inserted for workflow policies in the group you must change. Use the following parameters: EXEC=TRUE Remove=TRUE Because database triggers are being disabled, you must avoid firing additional database triggers through a workflow policy. Therefore, consider making these changes when either no users or only a minimal number of users are accessing the system. For more information, see Generating Database Triggers on page 404.
If a Workflow Monitor Agent server task is already running, then allow the server task to finish. This step makes sure the server task processes the remaining rows in the S_ESCL_REQ table for the workflow policy group.
3 4 5 6 7
Query the S_ESCL_REQ table for the GROUP_ID to make sure no more rows are present for GROUP_ID. If no server task for the monitor agent is running for the group, then start a server task for the group with the proper group name. After the remaining rows in the S_ESCL_REQ table for the group are finished processing, stop the server task of the Workflow Monitor Agent for the group. Reassign the workflow policy to the group by changing the field of the group name for the workflow policy to the new group name. Generate database triggers again, using the following parameters: EXEC=TRUE Remove=FALSE
43 1
8 9
Restart the Workflow Monitor Agent for the old group. Start a new Workflow Monitor Agent for the new group.
Expiring a Workflow Policy

When you expire a workflow policy, you can remove rows that belong to the expired or deleted policy in the S_ESCL_REQ table, which is preferable to deleting the workflow policy. If you encounter a failed to load parent rows error message, then it can be due to the presence of rows in the S_ESCL_REQ, S_ESCL_STATE and S_ESCL_ACTN_REQ tables that reference an expired workflow policy. The procedure in this topic allows you to determine, by using SQL queries, if there are rows in these tables that reference a policy that no longer exists in the S_ESCL_RULE table. To avoid workflow manager exiting with an error, make sure there are no outstanding records in the S_ESCL_REQ, S_ESCL_ACTN_REQ or S_ESCL_STATE tables before expiring the policy. CAUTION: Setting Ignore Errors to True is primarily used to clean up the Workflow Tables. It is strongly discouraged to permanently set Ignore Errors to True.
Removing Rows That Belong to a Workflow Policy That Is Expired or Deleted

You can expire a workflow policy by removing rows from the S_ESCL_REQ table.
To remove rows that belong to a workflow policy that is expired or deleted 1

Look for the following error message in the WorkMon_xxx.log trace file:

[DBG33] 2000-01-24 08:49:30 Message: Rule not found [DBG33] 2000-01-24 08:49:30 Message: Failed to load parent rows This error message indicates an error occurred when Workflow Monitor agent attempted to process records from the S_ESCL_REQ, S_ESCL_STATE or S_ESCL_ACTN_REQ tables, and the workflow policy that it is trying to review is expired or deleted. For more information about these tables, see Workflow Monitor Agent on page 417.
To determine if there are records that reference an expired policy, run the following query: select row_id, name, expire_dt from s_escl_rule where expire_dt is not null and expire_dt <= getdate() Sysdate is an Oracle date time function. The corresponding function for SQL Server is getdate().
3 4
Note the ROW_ID for the expired workflow policy that is identified in Step 2. Run the following query to determine the number of records in the S_ESCL_REQ table that reference an expired workflow policy: select * from s_escl_req where rule_id in (select row_id from s_escl_rule where expire_dt is not null and expire_dt <= getdate())
432
5 6
Repeat Step 4 for the S_ESCL_STATE and S_ESCL_ACTN_REQ tables. If there are records in the S_ESCL_REQ, S_ESCL_STATE, or S_ESCL_ACTN_REQ tables that reference an expired policy, then, in the Siebel client, start the Workflow Monitor Agent with Ignore Errors set to TRUE. Workflow Monitor Agent can bypass the error and clean the S_ESCL_REQ table. Note the caution information provided at the beginning of this topic.
7 8
Stop the server task. Restart the server task with Ignore Errors set to FALSE. This step makes sure other types of errors are not overlooked.
If the errors continue, then delete rows by RULE_ID, expire old workflow policies, and delete database triggers. For more information, see Deleting Rows by RULE_ID, Expire Old Policies, and Delete Database Triggers on page 433.
Deleting Rows by RULE_ID, Expire Old Policies, and Delete Database Triggers
You can expire a workflow policy by deleting rows by RULE_ID, expiring old policies, and dropping database triggers.
To delete rows by RULE_ID, expire old policies, and delete database triggers 1 2 3
Make a backup copy of the database or the effected tables. Identify the RULE_IDs that belong to workflow policies that no longer must be enforced by Siebel Workflow. Use SQL to manually delete the rows that reference expired or deleted workflow policies. Delete these policies by RULE_ID. For example: delete from [table name] where RULE_ID = 'rule_id' The Siebel application does not support direct delete or update statements on the Siebel database. Also, the S_ESCL_REQ, S_ESCL_ACTN_REQ, and S_ESCL_STATE tables are the only tables that do not contain dependencies. Make sure you perform this procedure in accordance with Siebel Support guidelines. Performing the backup in Step 1 makes sure a backup exists that you can use to restore the tables to their state before rows were deleted, if necessary.
For a workflow policy that must not be active, expire it by putting an older date and time in the Expiration Date/Time field for the policy.
43 3
To delete database triggers that reference expired workflow policies, run the Generate Triggers server task with the following parameters: Drop Triggers: EXEC = True Remove = True Generate Triggers: EXEC = True Remove = False If some workflow policies are expired, and if those policies did not drop and regenerate database triggers, then the database triggers for those policies can still cause records to be inserted into the tables for Siebel Workflow. Dropping these database triggers prevents creating rows that are related to expired policies in the S_ESCL_REQ table.
If necessary, regenerate database triggers. For more information, see Generating Database Triggers on page 404.
If the errors persist, then create a service request. Include a description of the steps you performed to resolve the error, along with a copy of the Workflow Monitor trace files with the following trace flags set: Error Flags = 2 SQL Trace Flags = 2 For more information, see How to Get Help with an Error of a Workflow Process on page 242.
Deleting a Workflow Policy That Is Obsolete

Database triggers are still in effect at the time you expire or delete a workflow policy and shut down Workflow Monitor. Database triggers that are related to an expired or deleted policy continue to work because they are attached to database tables until they are deleted from the database. Therefore, between the time you expire a policy and the time you finish dropping and redefining database triggers, rows might be triggered for the expired policy in the S_ESCL_REQ table. You might encounter the ESC-00054 error while starting Workflow Monitor because Workflow Monitor Agent looks for workflow policies that are referenced in the S_ESCL_REQ table, and finds policies that are inactive or not present. The policies are stored in the S_ESCL_RULE table. Those rows must remain in the S_ESCL_REQ table and must not be processed at all.
434
If Use Action Agent is set to FALSE for Workflow Monitor, then Workflow Monitor Agent executes for Action Agent, bypasses the S_ESCL_ACTN_REQ table, and uses only the S_ESCL_REQ table. If rows in the S_ESCL_REQ table exist for a workflow policy that is expired or deleted, then you must delete them before starting Workflow Monitor. Reasons for performing this work include: To avoid the ESC-00054 error when starting Workflow Monitor. To avoid the unnecessary use of storage space. Normally, Workflow Monitor does not process the rows at all. The rows remain unused in the S_ESCL_REQ table.
You can delete the rows by RULE_ID, which is the unique identifier for a workflow policy. Back up the database prior to performing the delete.
Example of Issuing Queries to Locate Workflow Policies That Are Deleted or Expired
The queries described in this topic can help you determine whether rows in the S_ESCL_REQ table exist that are related to a deleted or expired workflow policy.
Issuing a Query That Locates Workflow Policies That Are Deleted You can issue a query that locates deleted workflow policies.
To issue a query that locates deleted workflow policies

Run the following query: select RULE_ID, count(RULE_ID) from S_ESCL_REQ a where not exists (select row_id from S_ESCL_RULE b where a.RULE_ID = b.ROW_ID) group by RULE_ID Issuing a Query That Locates Workflow Policies That Are Expired You can issue a query that locates expired workflow policies.
43 5
To issue a query that locates expired workflow policies 1

Run the following query: select a.RULE_ID, b.NAME, count (a.RULE_ID), b.EXPIRE_DT, b.SUB_TYPE_CD from S_ESCL_REQ a, S_ESCL_RULE b where a.RULE_ID = b.ROW_ID and b.EXPIRE_DT < sysdate group by a.RULE_ID, b.NAME, b.EXPIRE_DT, b.SUB_TYPE_CD where:
sysdate is the Oracle current date and time function
Determine if the workflow policies expired unintentionally. An example of a workflow policy that expired unintentionally is someone forgetting to extend the dates and nobody changed the database triggers since the policy expired.
(Conditional). If you determine a workflow policy expired unintentionally and you must process the rows, then perform the following work:
If the Workflow Monitor is running and it is not necessary for you to shut it down, then reverse the expiration of the workflow policy by entering a date and time that is greater than the current date and time in the Expiration Date field for policy. After a period of 10 minutes, the workflow policy goes into effect. This situation occurs because the default for the Reload Policy parameter of Workflow Monitor is 600 seconds.
If you require the workflow policy to go into effect immediately, then shut down Workflow Monitor if it is running, reverse expiration of the policy, then start Workflow Monitor.
You can also perform this work with a workflow policy that contains a duration.
Tracing and Reporting a Workflow Policy

This topic describes how you can trace a workflow policy and generate reports about policies.
Trace Files for Workflow Policies and Siebel Server Tasks

When you start a Workflow Policies server process, a trace file for a Siebel Server task is generated so that you can check for error messages and other information. The Siebel Server processes for which trace files are generated include: Generate Triggers Page Manager Email Manager Workflow Monitor Agent Workflow Action Agent
436
Viewing Trace Files You can view information about the trace file in either the Siebel client or the Siebel Server.
To view trace files in the Siebel client

In the Siebel client, navigate to the Administration-Server Management screen, Tasks, then the Log view. The Tasks list displays the status of the Siebel Server tasks as running or started.
To view trace files in the Siebel server

View the log directory for the Siebel Server by performing one of the following:
Use Windows Explorer to navigate to your Siebel Server log directory. Under \log, choose the name for the server in order to examine a file that lists the trace files for each server process. Double-click the Trace File icon to access the trace file. You can view the trace file for application server tasks.
For more information on using trace files, see Siebel System Administration Guide.
Log Levels for Tracing and Events for Workflow Policies

Table 71 describes the events that workflow policies use for logging.
Table 71. Event
Events That Workflow Policies Use for Logging Level 4 3 Description Traces SQL statements and execution times. Traces Workflow Monitor Agent while it is performing Dynamic Assignment. Used in conjunction with Rules Evaluation. Traces Workflow Monitor Agent while it is performing Dynamic Assignment. Used in conjunction with Object Assignment. Parameter configuration of the server task.
SqlParseAndExecute Object Assignment
Rules Evaluation
Task Configuration
NOTE: Setting a trace level above the default parameter affects performance. Reset the trace level to the default parameter after you finish troubleshooting.
Charts and Reports for Workflow Policies

Charts are available for analyzing how frequently the condition of a workflow policy is met and the total number of policy instances that occur within a defined amount of time. Reports also summarize workflow policy and workflow log information.
43 7
Displaying Information About Frequency and Trends of How a Workflow Policy is Used Policy Frequency Analysis provides information about the number of times a workflow policy executes. Policy Trend Analysis provides information about policy execution trends.
To display information about frequency and trends of how a workflow policy is used 1 2
In the Siebel client, navigate to the Administration-Business Process screen, then the Policy Frequency Analysis view. Peruse the view, using values described in the following table. List or View Monitor Log Workflow Policy Frequency Analysis Description Lists the workflow policies. Displays a chart that illustrates the execution frequency of a chosen policy. To toggle between the Workflow Policy Frequency Analysis view and the Workflow Policy Trend Analysis view, use the toggle feature on the chart view. Displays the total number of workflow policy conditions that are met over a defined amount of time.
Workflow Policy Trend Analysis
Displaying a Report for a Workflow Policy In the Workflow Policies and Log views, you can bring up a Reports page that you can print.
To display a report for a workflow policy 1 2

In the Siebel client, navigate to the Administration-Business Process screen, then the Policies view. From the menu bar, click the Reports icon, then choose Workflow Policy. A separate Siebel Report Viewer window opens with a report that displays summary information for the workflow policy. You can also bring up a similar report for the Log views.
438
Guidelines for Converting a Workflow Policy to a Workflow Process

In general, it is recommended you keep a workflow policy simple, placing most business logic into a workflow process. To use this approach, you can convert a workflow policy to a workflow process. Table 72 describes guidelines you can use when converting a workflow policy to a workflow process.
Table 72.
Guidelines for Converting a Workflow Policy to a Workflow Process Configuration Used in a Workflow Process A run-time event. A branch or decision step. A Siebel operation step at the object layer that implements logic which manipulates data at the data layer. Although a workflow process cannot call a workflow policy program, if there is a requirement to perform an operation at the database level, then it might be possible to use the Siebel operation step to accomplish the same required functionality.
Configuration Used in a Workflow Policy A specialized operator, such as IS UPDATED or IS ADDED. A standard operator, such as = or <>. A workflow policy program that performs an operation at the database layer.
Not applicable
For sending email, because a workflow process uses the communication outbound manager service, it can use a recipient group and an exact email address.
43 9
Administering a Workflow Policy Testing, Troubleshooting, and Migrating a Workflow Policy
Testing, Troubleshooting, and Migrating a Workflow Policy

This topic describes testing, troubleshooting, and migrating a workflow policy. It includes the following topics: Testing a Workflow Policy on page 440 Troubleshooting a Workflow Policy on page 442 Migrating Workflow Policies to the Production Environment on page 443
Testing a Workflow Policy

Testing a workflow policy before implementing it in your production environment increases the likelihood that the recipient of an action receives accurate and useful information, and that the overall results meet the business requirements for the workflow process. It is critical that you thoroughly test your workflow policy and eliminate problems before you implement the policy in your production environment. CAUTION: Your test environment and production environment must contain identical versions of the software.
To test a workflow policy 1

Develop a testing and migration strategy for introducing changes into the production environment. For more information, see Planning a Test and Migration Strategy for a Workflow Policy on page 336.
2 3 4 5
Make sure you installed the workflow policy components on the Siebel Server. For more information, see Siebel System Administration Guide. Make sure the server processes for email and pager that are required by your workflow policy are running. Make sure the required Workflow Agent processes are running. Make sure each workflow policy, workflow policy condition, and workflow policy action executes as expected:

Test your workflow policy by entering data that meets the conditions you defined for the policy. Make sure the policies, conditions, and actions are correctly defined. Make sure the policies, conditions, and actions accurately define the transactions. The correct columns can be monitored.
440
Make sure the workflow policy actions perform as expected and occur when expected:

Make sure your database triggers are generated. Make sure the action interval and sleep times are correctly defined. Make sure the proper action executes. For example, you can check that the email arrives or that the pager notification activates. You can use the Workflow Policies Log view to monitor progress of the Workflow Agent. For more information, see Using the Workflow Policy Log to Monitor Execution of a Workflow Policy on page 441.
Using the Workflow Policy Log to Monitor Execution of a Workflow Policy

The Workflow Policy Log view displays a log of the records that meet a workflow policy condition that is tracked by the Workflow Monitor Agent process.
To use the workflow policy log to monitor execution of a workflow policy 1 2 3

In the Siebel client, navigate to the Administration-Business Process screen, the Policy Frequency Analysis view. Query the Policy field for the workflow policy you must monitor. Peruse the log using values from the following table. Field Policy Workflow Object Object Identifier Object Values Event Description The name of the workflow policy. The name of the workflow policy object. The ID of the workflow policy object for which the workflow policy condition was met. Identifying information for the row that met the workflow policy condition. The date and time that the workflow policy condition was met.
After you verify that the workflow policy executes as expected, you can migrate the policy to your production environment. For more information, see Migrating Workflow Policies to the Production Environment on page 443.
44 1
Troubleshooting a Workflow Policy

Because a workflow policy is based on database triggers, the policy can execute on a database record only after the record is committed. If a policy is based on multiple database tables, then the policy goes into effect only if the records on those tables are committed. For example, opportunity revenue is stored in the S_OPTY_POSTN table, and lead quality is stored in the S_OPTY table. A workflow policy that applies both of the following workflow policy conditions goes into effect only when the records are committed on both tables: Opportunity Revenue > 10M Lead Quality is High
A search specification can be used to defined multiple business components for the same database table. If you define the component of a workflow policy to monitor a business component, then be sure to include fields that are used in the search specification as workflow policy columns. The workflow policy column can then be used in the conditions of the workflow policy in order to enforce appropriate behavior.
Troubleshooting a Workflow Policy Action That Does Not Trigger

You can troubleshooting a workflow policy action that does not trigger.
To troubleshoot a workflow policy action that does not trigger 1 2

Make sure your test record meets the workflow policy conditions. Make sure the Siebel client configuration file is pointing to the correct enterprise server. If the server is incorrect, then the ESC-00053 error, Error loading rule definitions, might occur.
3 4
Check the date and time that the workflow policy was activated. Check the monitor task:
a b
Check to see if the monitor is awake and running against the correct group. Search the Task Information log for the ROW_ID of your test record:

If ROW_ID does not exist, then run GENERATE TRIGGERS. Update your test record.
Check the Action Agent task:
a b 6
Check to see if the Action Agent is awake and running against the correct workflow policy group. Search the Task Information log for the ROW_ID of the test record.
Make sure the database triggers are generated.
442
Tracing a Workflow Policy

The General Events event is used for logging with a workflow policy. To view informational messages, set the log level to 3. To view debugging information, set the log level to 4. For more information, see Tracing and Reporting a Workflow Policy on page 436.
Migrating Workflow Policies to the Production Environment

To migrate fully tested workflow policies to your production environment, you must perform a procedure that is similar to the procedure that is used to implement policies in your test environment.
To migrate workflow policies to the production environment 1 2 3

Back up your production environment database. Migrate your test repository environment into your production repository environment. For more information, see the upgrade guide for the operating system you are using. Reenter, into the production environment, the workflow policy action types, workflow policies, and workflow policy groups that you defined in the test environment. When you reenter definitions in the production environment, make sure you enter them exactly as they are defined in the test environment. It is not necessary to reenter information that you defined by using Siebel Tools.
4 5 6
In the Siebel client, navigate to the Administration-Server Management screen, then the Jobs view. In the Jobs list, click New. In the drop-down list for the Component/Job field, choose Generate Triggers. This step creates a new line entry but does not start the server task.
In the Job Parameters list, click New to modify parameter settings. For a description of the parameters that are specific to the Generate Triggers server component, see Administering Database Triggers on the Workflow Policy Server on page 402. For a description of generic and enterprise parameters, see Siebel System Administration Guide.
8 9
Choose Submit Query. Use trace files, as necessary, to monitor execution. For more information on trace files, see Tracing and Reporting a Workflow Policy on page 436. For more information on using trace flags, see Siebel System Administration Guide.
NOTE: To help prevent invalid database triggers from applying to your production environment, apply database triggers to your test environment before you apply them to your production environment.
44 3
444
Reference Materials for Siebel Workflow
This appendix provides reference information for Siebel Workflow. It includes the following topics: Properties of Siebel Workflow on page 445 Properties of Workflow Policies on page 470 Predefined Business Services on page 482
Properties of Siebel Workflow

This topic describes reference information for various objects used with a workflow process. It includes the following topics: Properties of a Workflow Process on page 445 Properties of the Step and Connector of a Workflow Process on page 450 Fields and Arguments of Process Properties on page 462
Properties of a Workflow Process

Table 73 describes properties of the top level object definition for a workflow process.
Table 73. Property
Properties of the Object Definition of a Workflow Process Description Sets workflow persistence. The name of the associated business object. Possible Value (Optional) YES or NO. (Optional) This value is chosen from a picklist of business objects. Only business objects that contain a defined primary component appear in this picklist. For more information on defining the primary business component for a business object, see Defining a Primary Business Component for a Business Object on page 83.
Auto Persist Business Object
Error Process Name
The name of the workflow process to call as the error process.
(Optional) Choose from the picklist of predefined workflow processes.
44 5
Reference Materials for Siebel Workflow Properties of Siebel Workflow
Table 73. Property Group
Properties of the Object Definition of a Workflow Process Description This property applies to workflow processes that are defined earlier than version 7.7. Possible Value (Optional) NOTE: Do not use this property for a new workflow process that you define. Use the Project property instead. (Optional) TRUE or FALSE.
Pass By Ref Hierarchy
Applicable for hierarchal data that is passed between a subprocess and the parent workflow process. If pass by reference is checked, then a change that is made in the child workflow process propagates back to the parent workflow process. If implemented, then this feature reduces the memory footprint that is required for a workflow process because data is passed by reference instead of by value. The name of the workflow process.
Process Name
(Required). A descriptive name that includes the following characteristics: Consistent with your overall naming strategy Meaningful to the designer of the process Unique
Project Replication Level
The name of the project to which the workflow process belongs. How the workflow process synchronizes to a Mobile Web Client. The All value synchronizes to the regional nodes for the server as well as to mobile users. The Regional value synchronizes only to the regional nodes.
(Required). None, All, or Regional.
446
Table 73. Property
Properties of the Object Definition of a Workflow Process Description The state management type for the workflow process. Describes the type of business service requests that are made while the workflow process is executing. NOTE: If every business service that is called by this workflow process is a stateless business service, then it is recommended that the state management type be set to Stateless. Otherwise, it is recommended that the state management type be set to Stateful. The default setting is Stateful. For more information, see State Management Type and the Workflow Process on page 449. Possible Value (Required). The following values are available: Stateless. A method of a business service that is called by this workflow process does not include a dependency on a state that is specific to the service. If the stateful or cached services that are called by this workflow can be released when the workflow pauses or finishes, then choose Stateless. Stateful. A method of a business service that is called by this workflow process depends on a state that is specific to a service. If the stateful or cached services that are called by this workflow must not be released during and after the execution of the workflow, then choose Stateful.
State Management Type
Status
The current status of the workflow process.
(Required). The following values are available: Not In Use In Progress Completed
Version
The version number of the workflow process.
Read only. The default version is 0. The version number increments by one when you use Revise to modify an existing workflow process.
44 7
Table 73. Property
Properties of the Object Definition of a Workflow Process Description This property indicates that a business service or workflow process is exposable as a Web service and can be called independently. NOTE: Setting this property to TRUE does not automatically implement the workflow Web service, nor does defining the workflow process for Web service cause the flag to be checked. Possible Value (Optional) TRUE or FALSE.
Web Service Enabled
Workflow Mode
The type of the workflow process.
(Required). The following values are available: 7.0 Flow Long Running Flow Interactive Flow Service Flow
For more information, see About the Workflow Mode Property on page 127. Some of these properties, but not every property, can be defined by using the Workflow Processes OBLE, or the Properties window in the Process Designer. The Properties window in the Process Designer displays properties based on context.
To display properties for the workflow process 1

2 3 4
Right-click the workflow process, then choose Edit Workflow Process. Click the canvas, making sure no workflow process step or connector is chosen. From the Tools application-level menu, choose the View menu, Windows, then the Properties Window menu item.
448
State Management Type and the Workflow Process

The OM session state management framework requires a business service to contain a state management type that is defined. A business service must be defined as Stateless or Stateful, or as a business service that is managed by the server. The stateless Workflow Process Manager business service is the Workflow Engine. The State Management Type property of a workflow process defines whether the workflow is designed to be stateless or stateful. The Workflow Engine can execute a stateful workflow process or a stateless workflow process: If a workflow process is defined as Stateless, then the OM session state management framework can release a stateful or cached business service that is called by this workflow when the workflow instance is paused or finished. If a workflow process is defined as Stateful, then the OM session state management framework does not release a stateful or cached business service that is called by the instance of this workflow, even after the instance is finished. Instead, the framework waits for the caller of the Workflow Engine to decide when the cached business service must be released. The caller of the Workflow Engine can release stateful or cached business services by calling methods from the Web Channel Dedicated Block Service.
How the State Management Type is Defined By default, the State Management Type for a workflow process is set to Stateful in order to preserve the behavior for releases earlier than Siebel CRM 8.1. However, if a workflow process is designed to be executed through Web Channel, then it might be necessary to change the State Management Type for the workflow to Stateless in order to take advantage of the session pooling feature in the OM session state management framework. Table 74 describes how the Workflow Mode property of a workflow process determines the State Management Type for the workflow.
Table 74.
How the State Manage Type Property Is Defined How Typically Defined Stateless Description Because a service workflow cannot contain a user interact step or wait step, it is executed for the entire workflow before the object manager session state management framework can release the session back to the pool. Similar to a long-running workflow process, the instance of an interactive workflow can move between sessions through the Universal Inbox. However, because the State Management Type setting is only relevant when the workflow is executed through Web Channel, and because an interactive workflow executes in a user interactive session, the State Management Type does not effect the behavior of an interactive workflow.
Workflow Mode Service Flow
Interactive Flow
Stateless
44 9
Table 74.
How the State Manage Type Property Is Defined How Typically Defined Stateless Description The Workflow Engine is already designed to allow a longrunning workflow to deploy between sessions when a longrunning workflow is paused. NOTE: It is recommended that you do not define a longrunning workflow to call a stateful business service because the state of the service is lost when the instance of a longrunning workflow moves from one user session to another user session.
Workflow Mode Long Running Flow
7.0 Flow
Stateful
Do not change this setting unless you are sure none of the business services that the workflow process calls directly or indirectly is a stateful business service.
For more information on the Web Channel OM session state management framework, see Siebel Web UI Dynamic Developer Kit Guide.
Properties of the Step and Connector of a Workflow Process

This topic describes properties of the various steps and connectors that used in Siebel Workflow.
450
Table 75 describes the properties of a step of workflow process.
Table 75. Property Name
Properties of a Step of a Workflow Process Type of Step All Description The name of the step. Possible Value A descriptive name that includes the following characteristics: Consistent with your overall naming strategy Meaningful to the designer of the process Unique
When you define a new step, the step is automatically assigned a name, based on the type of step, and a sequence number. You can change this name or leave it as is. For more information, see Name of a Step in a Workflow Process or a Process Property on page 67. Type All The type of step. This value is automatically entered when you define the step in the Process Designer view. This value is a read only property. Choose from a list of business components that are defined for the chosen business object. The picklist displays business services that have their Hidden flag set to FALSE. For more information, see Making a Business Service Visible to a Workflow Process on page 71. Business Service Method Business Service The name of the method to call on the business service. The picklist displays methods that are defined for the business service that is chosen.
Business Component Business Service Name
Siebel Operation Business Service
Required. The business component that performs the action you define. The name of the business service to call.
45 1
Table 75. Property
Properties of a Step of a Workflow Process Type of Step Sub Process Description The name of the sub process step. Possible Value A descriptive name that includes the following characteristics: Consistent with your overall naming strategy Meaningful to the designer of the workflow process
Subprocess Name
Error Code
Stop
A number that is associated with a string in the database that comprises the error message. A string in the database that comprises the error message. The name of the view for the user interact step. The type of operation.
Numeric value.
Error Message User Interact View Operation
Stop
Text string.
User Interact Siebel Operation
Choose from a picklist that contains predefined view names. The following values are available: Delete Insert NextRecord PrevRecord Query QueryBiDirectional Update Upsert
452
Table 75. Property Maximum Iterations
Properties of a Step of a Workflow Process Type of Step Wait Description The maximum number of times that you can execute this step within an instance of a workflow process. Possible Value If the maximum number of iterations is reached, then an error from the Object Manager is generated and the workflow process returns an In Error status. If you require the workflow to run to completion, then you must use an exception mechanism in Siebel Workflow to catch and handle the error. Example mechanisms include an error process or an error exception connector. For more information, see Using an Error Exception Connector to Handle Errors on page 164. Free form text.
Description
All
A text narrative that describes the purpose of the step. A text narrative that describes the purpose of the step.
Comments
All
Free form text.
45 3
Table 75. Property Update Snapshot
Properties of a Step of a Workflow Process Type of Step All Description Indicates that if the workflow process reaches this step, then Siebel Workflow uses a snapshot of the state of the process, so that if there is a system failure, you can recover the state. This parameter is used for recovery. The mode in which the workflow process is run when it is started by a runtime event. For more information, see Processing Mode Property of a Wait Step on page 88. Possible Value Check mark.
Processing Mode
Wait
(Optional) The following values are available: Local Synchronous. Executes the workflow process in the application object manager. This value is the default. Remote Synchronous. Submits a synchronous request to the Workflow Process Manager server component in order to execute the workflow process. Remote Asynchronous. Submits an asynchronous request to the Workflow Process Manager server component in order to execute the workflow process.
Table 76 describes properties of the start step.
Table 76.
Properties of the Start Step Expected Value (Descriptive text.) (Descriptive text.) FALSE Start
Start Properties Comments Description Inactive Name
454
Table 76.
Properties of the Start Step Expected Value Workflow name:version Local Synchronous (or can be empty)
Start Properties Parent Name Processing Mode
Table 77 describes properties of the business service step.
Table 77.
Properties of the Business Service Step Expected Value FALSE (Choose the business service name from the picklist.) (Choose the business service method from the picklist.) (Descriptive text.) (Descriptive text.) FALSE Business service 0 (You can modify this value, as necessary.) Workflow name:version
Business Service Property Allow Retry Flag Business Service Name Business Service Method Comments Description Inactive Name Parent Name
Table 78 describes properties of the decision point step.
Table 78.
Properties of the Decision Point Expected Value (Descriptive text.) (Descriptive text.) FALSE Decision Point 0 (You can modify this value, as necessary.) Workflow name:version
Decision Point Properties Comments Description Inactive Name Parent Name
45 5
Table 79 describes properties of the sub process step.
Table 79.
Properties of the Sub Process Step Expected Value (Descriptive text.) (Descriptive text.) FALSE Sub Process 0 (You can modify this value, as necessary.) (Choose the name of the subprocess from the picklist.) For a subprocess to appear in this picklist of defined workflow processes, the status for the subprocess must be Complete.
Sub Process Properties Comments Description Inactive Name Sub Process Name
Table 80 describes properties of the Siebel operation step.
Table 80.
Properties of the Siebel Operation Step Expected Value FALSE (Choose the business component name from the picklist.) (Descriptive text.) (Descriptive text.) FALSE Siebel Operation 0 (You can modify this value, as necessary.) (Choose the operation from the list.) Workflow name:version
Siebel Operation Properties Allow Retry Flag Business Component Comments Description Inactive Name Operation Parent Name
Table 81 describes properties of the task step.
Table 81.
Properties of the Task Step Expected Value (Descriptive text.) (Descriptive text.) FALSE
Task Properties Comments Description Inactive
456
Table 81.
Properties of the Task Step Expected Value Task 0 (You can modify this value, as necessary.) (Choose the task name from the picklist.)
Task Properties Name Task Name
Table 82 describes properties of the user interact step.
Table 82.
Properties of the User Interact Step Expected Value (Descriptive text.) (Descriptive text.) FALSE User Interact 0 (You can modify this value, as necessary.) Workflow name:version (Choose the view name from the picklist.)
User Interact Properties Comments Description Inactive Name Parent Name User Interact View
Table 83 describes properties of the wait step.
Table 83.
Properties of the Wait Step Expected Value Sleep Workflow Utilities (Descriptive text.) (Descriptive text.) FALSE Not applicable Wait 0 (You can modify this value, as necessary.) Workflow name:version
Wait Properties Business Service Method Business Service Name Comments Description Inactive Maximum Iterations Name Parent Name
45 7
Table 84 describes properties of the stop step.
Table 84.
Properties of the Stop Step Expected Value (Descriptive text.) (Descriptive text.) (Choose the error code from the picklist.) (After the Error code is chosen, the Error message is automatically populated.) Stop 0 (You can modify this value, as necessary.) Workflow name:version
Stop Properties Comments Description Error Code Error Message Name Parent Name
Table 85 describes properties of the end step.
Table 85.
Properties of the End Step Expected Value (Descriptive text.) (Descriptive text.) FALSE End 0 (You can modify this value, as necessary.) Workflow name:version
Stop Properties Comments Description Inactive Name Parent Name
458
Table 86 describes properties of the workflow connector.
Properties of the Workflow Connector Description The name of the connector. Possible Value The name of the connector must be unique to the workflow process. If it is not unique, then you cannot commit the record. The following values are available: Default. If no other decision conditions are satisfied, then this connector is followed. Also, if Default is used, then conditions that are defined for the connector are ignored. Condition. A decision condition is defined for the connector. Connector. There is no decision condition involved. Error Exception. Captures an error that is generated by the system, such as an error that notes that the Assignment Manager server component is not available. For more information, see Using an Error Exception Connector to Handle Errors on page 164. User Defined Exception. Captures an error that is generated by an end user, such as an error that notes that an order is incomplete. For more information, see Using an Error Exception Connector to Handle Errors on page 164.
Type
The type of connector.
Event Object Type
Describes the type of object on which a run-time event occurs. NOTE: If Event Object Type is defined, then Event Object must be chosen.
(Optional) Possible values include: Application Applet BusComp
Event Object
The name of the object on which the event occurs.
(Required if Event Object Type is defined). This name is defined in Siebel Tools. Event Object is context sensitive, depending on the value in Event Object Type. For example, if Event Object Type is set to BusComp, then Event Object specifies the business component, such as Account.
45 9
Table 86. Property Event
Properties of the Workflow Connector Description The specific event that happens to the object. The name of the method or field in a business component to be monitored. Possible Value (Required if Event Object Type is defined.) The set of available events is context sensitive, depending on the value in Event Object Type. (Optional) Used when the object type is BusComp or Applet and the event is InvokeMethod or SetFieldValue. For InvokeMethod, the name of the called method. For SetFieldValue, the name of the field being set.
Subevent
Event Cancel Flag
Aborts the run-time event after the workflow process is finishes. NOTE: If this flag is not checked, then the following error results when the workflow process is run: The specialized method [Method Name] is not supported on this business component.
(Optional) This flag only applies to an event that can be canceled. This flag works similar to CancelOperation in scripting.
Expression
User friendly text for the decision condition that is defined for the connector. Controls whether the workflow process waits for a run-time event that is generated within the current session, or by another session.
Read-only
Event Visibility
If the workflow process is persistent, then the visibility can be set to Enterprise or Local. NOTE: If the workflow process is not persistent, then it is recommended that visibility be set to Local. In most cases, where a workflow process must wait for an event, the workflow must be persistent, and you set the value to Enterprise. However, setting Event Visibility to Enterprise can have a detrimental effect on performance because a run-time event searches for a matching instance. Therefore, if it is not necessary for your workflow to be persistent, then it is recommended that you set Event Visibility to Local.
460
Table 86. Property
Properties of the Workflow Connector Description An arbitrary string that denotes the name of a user event. Possible Value This value can be a string but it must be unique within the Siebel enterprise. Make sure you define a unique name on the User Event Name field. Also, make sure the name is sufficiently long so that it remains unique across the Siebel enterprise. For example: Order Placed-Begin Processing Event for Service Request Automation-Version 2.
User Event Name
User Event Storage
The process property that serves as the destination for the payload on the incoming user event. The amount of time, in days, before the event times out.
This value can be a process property. The process property must be marked as the correlator. Numeric value. If the user event is on a wait step, then use this parameter. Do not define a wait duration on the wait step. Free form text.
User Event Timeout (Days)
Comments
More statements relative to the connector.
Table 87 describes properties of the error exception connector.
Table 87.
Properties of the Error Exception Connector Expected Value (Descriptive text.) FALSE Error Exception 0 (You can modify this value, as necessary.) (From step name) Error Exception (Leave this field empty.) (Leave this field empty.) 0
Error Exception Connector Properties Comments Inactive Name Parent Name Type User Event Name User Event Storage User Event Timeout
46 1
Fields and Arguments of Process Properties

This topic describes reference information for process properties and their arguments. It includes the following topics: Fields of a Process Property on page 462 Fields of an Input Argument of a Process Property on page 465 Fields of an Output Argument of a Process Property on page 466 Fields of a Recipient Argument of a Process Property on page 468 Fields of the Input Argument of a Search Specification of a Process Property on page 469
Fields of a Process Property

This topic describes fields that can be defined for a process property in the MVPW. For configuration information, see About the Process Property on page 47. Table 88 describes fields that can be defined for a process property.
Table 88. Field Name
Fields of a Process Property Description The name of the process property. Possible Value A descriptive name that includes the following characteristics: Consistent with your overall naming strategy Meaningful to the designer of the process Unique
For more information, see Name of a Step in a Workflow Process or a Process Property on page 67. Display Name A user friendly version of the property name. The Display Name can be the same as or different from the Name.
462
Table 88. Field In/Out
Fields of a Process Property Description Describes whether or not the process property is passed in or out of the process, passed into the process and returned, or used only within the process. Possible Value The following values are available: In. The process property is passed into the workflow process. Binary types cannot be assigned this value. Out. The process property is passed out of the workflow process. Binary types cannot be assigned this value. In/Out. The process property is passed into the workflow process and returned. Binary types cannot be assigned this value. None. The process property is used only within the workflow process.
Business Object Business Component Virtual Field The name of the associated business object. The name of the business component that contains the virtual field. The name of the field of the business component that is mapped to the workflow process property.
Read only. For more information, see Defining a Primary Business Component for a Business Object on page 83. This value is chosen from a picklist of business components that belong to the business object of the workflow process. This value is chosen from a dropdown picklist of fields that belong to the business component. Only calculated fields with no calculated values appear in this picklist. Values for virtual fields are provided by the application logic at runtime. Workflow does not require that a field of a business component be specified as a virtual field. Also, an applet can reference a virtual field in the same way that a standard field of a business component is referenced. The decision to make the field of a business component a calculated field is not directed by workflow.
Default String
Initial value if the process property is a string type.
Free form text. If you enter [Value], then the process property is initialized with the value in the Value property of the workflow input property set. Calendar widget.
Default Date
Initial value if the process property is a date type.
46 3
Table 88. Field Data Type
Fields of a Process Property Description The type of data that can be stored in the process property. Possible Value The following values are available: Alias. Size limit for default value, not run-time value: 250 characters. Binary. For variant or binary information, usually for XML data. Binary types must be assigned the None value in the In/Out property. Date. For dates. Hierarchy. Data type that is used by Siebel Enterprise Application Integration in order to store data from a property set. For more information, see Overview: Siebel Enterprise Application Integration. Integration Object. For storing integration objects. Integration objects use the Hierarchy data type. Number. For numeric data. Size limit for default value, not run-time value: 22 digits. String. For alphanumeric data, usually for UTF-16 data. Size limit for default value, not run-time value: 250 characters. Strongly Typed Integration Obj. A special data type for exposing a workflow process as a Siebel inbound Web service. Siebel business services use this property when generating WSDLs. NOTE: For both the workflow process and business service engines, values in the Strongly Typed Integration Obj and the Integration Object properties are treated as the same data type.
Default Number Integration Object
Initial value if the process property is a numeric type. Data type that is used by Siebel EAI in order to store data from an integration object.
Numeric widget. For example: Account-Get Oracle Customer (Oracle)
464
Table 88. Field Correlator Flag
Fields of a Process Property Description Makes the process property ready for use as a correlator: a piece of business data that identifies the recipient of the incoming message. For more information, see Workflow User Event Service Business Service on page 486. Controls whether a process property is read only or read-write. Possible Value Check mark.
Access Mode
Read-only or Read-write.
Fields of an Input Argument of a Process Property

Table 89 describes fields that can be defined on an input argument for the business service step, sub process step, and wait step.
Table 89. Field
Fields of an Input Argument of a Process Property Description Not applicable Possible Value Not applicable
Preferred Sequence (For business service steps only.) Input Argument (For business service steps only.)
The name of the input argument.
(Required) The picklist displays input arguments that exist for the business service method that is chosen. If a method argument is defined as a business service method argument, and if the Hidden flag is set to FALSE, and if the type is Input or Input/ Output, then the method argument displays in this picklist.
Subprocess Input (For sub process steps only.) Type
The name of the input argument.
(Required)
The type of argument.
(Required) Choices in the picklist include: Literal Process Property Business Component Expression
46 5
Table 89. Field Value
Fields of an Input Argument of a Process Property Description A string value. Possible Value Used for the Literal and Expression type of input arguments. This value can be a picklist, depending on the argument that is chosen. A string value can contain a maximum of 32,767 characters. Used for the Process Property type of input argument. Used for the Business Component type of input argument.
Property Name Business Component Name Business Component Field Changed
The name of the process property. The name of a business component that is within the business object of the business process. The name of a field in the business component. Not applicable
Used for the Business Component Field type of input argument. Check mark.
Fields of an Output Argument of a Process Property

Table 90 describes fields that can be defined on an output argument for a business service step, sub process step, and Siebel operation step.
Table 90. Field Property Name
Fields of an Output Argument of a Process Property Description The name of the process property in which to store the results. Possible Value (Required) If Property Name is clicked, then a picklist of process properties that are defined for the process displays. For more information, see Passing a Process Property In and Out of a Step of a Workflow Process on page 57. (Required) The following choices are available in the picklist: Literal Output Argument Business Component Expression
Type
The type or argument.
Value
A string value.
Use for Literal or Expression arguments. A string value can contain a maximum of 32,767 characters.
466
Table 90. Field
Fields of an Output Argument of a Process Property Description The name of the output argument. Possible Value Used for the Output Argument type of output argument. This is a picklist of output arguments for the method that is chosen. If an argument is defined as a business service method argument, and if the Hidden flag is set to FALSE, and if the type is Output or Input/Output, then the argument displays in this picklist. The name of the output argument. Used for the Output Argument type of output argument.
Output Argument (For business service steps only.)
Subprocess Output (For sub process steps only.) Business Component Name Business Component Field
The name of the business component within the business object of the business process. The name of a field in the business component.
Used for the Business Component type of output argument.
Used for the Business Component Field type of output argument. NOTE: A field that is based on a multi-value group cannot be chosen as a value for an input or output argument. If you must use a field that is based on a multi-value group, then you must define a business component for the field, then link it to the appropriate business object. For more information, see Configuring Siebel Business Applications.
46 7
Fields of a Recipient Argument of a Process Property

Table 91 describes fields that can be defined on a recipient argument. For configuration information, see About the Sub Process Step on page 73.
Table 91. Field
Fields of a Recipient Argument of a Process Property Description The type of recipient. The source from which the recipient value is derived. Define This Property If. . . Not applicable Not applicable Possible Value This value is fixed as User and cannot be changed. The following values are available in the picklist for this property: Name Expression Process Property Business Component
Recipient Type Code Value Type Code
Recipient Name
The name of the recipient. This property is a pick applet which displays the first name, last name, and login name of users in the database. The name of the business component.
The Value Type Code is set to Name.
Choose one name from the list of users who are available in the database.
Business Component Name Business Component Field Process Property Name Expression
The Value Type Code is set to Business Component. The Value Type Code is set to Business Component. The Value Type Code is set to Process Property. The Value Type Code is set to Expression.
Choose one business component.
The name of the field that resides in the business component. The name of the process property. If the recipient value is derived from an expression, then the expression is entered in this property.
Choose one business component field.
Choose one process property.
The expression from which the recipient value is derived.
468
Fields of the Input Argument of a Search Specification of a Process Property

Table 92 describes fields that can be defined for an input argument on a search specification on the Search Spec Input Arguments tab of the MVPW.
Table 92. Field
Fields of an Input Argument on a Search Specification of a Process Property Description If you enter Expression in the Type field, then enter the name of the business component that evaluates the expression. For example, in the Search Specification field, you can enter: "[Due Date] < '" + [Order Date] + "'" The Expression business component evaluates Order Date so that the following search specification is used: [Due Date] < '07/04/2001 18:51:26'
Expression Business Component
Filter Business Component Search Specification
Enter the name of the business component that provides the group of records on which you perform your search. The value you enter depends on the value you choose for the Type argument: If you enter Literal in the Type argument, then enter a literal value in the form of an expression. For example, = 100. If you enter Expression in the Type argument, then enter an expression, such as [Status] LIKE *Open*. The expression is evaluated by the Expression business component you define.
Type Comments Changed
Required. Choose the type of value on which to base your search: Literal or Expression. Enter a text description of the purpose of the search. Check mark indicates a changed search specification.
46 9
Reference Materials for Siebel Workflow Properties of Workflow Policies
Properties of Workflow Policies

This topic describes reference information for various objects used with the workflow policies module. It includes the following topics: Properties of the Workflow Policy Column on page 470 Properties of the Workflow Policy Object on page 471 Properties of the Workflow Policy Component on page 472 Properties of the Workflow Policy Component Column on page 474 Properties of the Workflow Policy Program on page 475 Properties of the Workflow Policy Program Argument on page 476
Properties of the Workflow Policy Column

The Workflow Policy Columns OBLE displays a list of the available workflow policy columns. You must activate extension columns in Siebel Tools in order to make them available for use in workflow database operations. Table 93 describes properties that are displayed in the Workflow Policy Columns OBLE.
Properties of the Workflow Policy Column Usage Define the name of the workflow policy column, which is the default name that is displayed in the Conditions list on the Workflow Policies view. Description A name that includes the following characteristics: Consistent with your overall naming strategy Meaningful to the policy maker Descriptive of how the column is used
Changed Project
The identifier for whether the record was added or edited. Define the project to which the workflow policy column belongs. You must lock the project before you can modify the column. Define the name of the Siebel database table that contains the column. Define the name of the column in the Siebel table.
A check mark or a blank value. A project from the picklist of projects that are currently checked out.
Table Name
A table name from the picklist of Siebel database tables. A database column on the database table defined in Table Name.
Column Name
470
Table 93. Property Picklist
Properties of the Workflow Policy Column Usage Define the picklist that is used when choosing a comparison value for the column in the Workflow Policies view. Description A picklist that is defined in the repository. The column that is chosen contains a corresponding Business Component field. If the corresponding Business Component field includes a picklist, then the picklist is entered in the Picklist property. For more information, see Configuring Siebel Business Applications. The name of a field from a business component from the picklist that is defined in the Picklist field. An applet that is chosen from the picklist. Only choose a Pick applet. A check mark indicates that the workflow policy column is inactive and is not compiled or accessible.
Source Field Applet
Define the field in the business component of the picklist that is the source of the comparison value. Define the applet that is used to display the picklist in the Workflow Policies view. Define whether this column is active or inactive. If the column is inactive, then the column is not compiled when you compile your SRF and it is not accessible by an object.
Inactive
Comments
Add comments that describe the purpose or use of the column.
Enter comments text.
Properties of the Workflow Policy Object

The Workflow Policy Objects OBLE displays a list of the available workflow policy objects. Table 94 describes properties that are displayed in the Workflow Policy Objects OBLE.
Properties of the Workflow Policy Object Usage Define the name of the workflow policy object. Description A descriptive name that includes the following characteristics: Consistent with your overall naming strategy Meaningful to the policy maker
Changed
The identifier for whether the record was added or edited.
A check mark indicates the record was added or edited.
47 1
Table 94. Property Inactive
Properties of the Workflow Policy Object Usage If the object is active or inactive, then define this property. Description A check mark indicates that this field is inactive and is not compiled or accessible. If an object is inactive, then the object is not compiled when you compile your SRF and it is not accessible by another object or policy.
Comments Project
Add comments that relate to the workflow policy object. Define the project name.
Descriptive text. Defined in the project picklist.
Properties of the Workflow Policy Component

The Workflow Policy Components OBLE displays a list of workflow policy components for the parent workflow policy object that is currently chosen in the OBLE. The Workflow Policy Components OBLE displays both the primary policy component and the nonprimary policy components. It also displays how each of the policy components are related. Table 95 describes properties that are displayed in the Workflow Policy Components OBLE.
Properties of the Workflow Policy Component Usage Define the name of the workflow policy component. Description A descriptive name that includes the following characteristics: Consistent with your overall naming strategy Meaningful to the policy maker
Changed Primary
Indicates whether the record was added or edited. Define whether this workflow policy component is the primary for the workflow policy object that is chosen in the Workflow Policy Objects OBLE. Define the table on which the workflow policy component is based.
A check mark indicates the record was added or edited. A check mark indicates that this is the primary workflow component. Each workflow policy object must contain only one primary workflow policy component. A table name from the picklist.
Source Table Name
472
Table 95. Property
Properties of the Workflow Policy Component Usage Define the column in the source table that relates to another workflow policy component. Define the target workflow policy component to which this workflow policy component is related. Define the column in the target workflow policy component to which the source column in this workflow policy component is joined. Indicates whether the workflow policy component is active or inactive. Description A picklist of columns from the table that is defined in the Source Table Name field. (Not required for the primary workflow policy component.) A table name from the picklist. (Not required for the primary workflow policy component.) A picklist of columns from the workflow policy component that is defined in the Target Component Name field. (Not required for the primary workflow policy component.) A check mark indicates that this field is inactive and that it is not compiled or accessible. If the component is inactive, then it is not compiled when you compile your SRF and it is not accessible by a policy.
Source Column Name
Target Component Name Target Column Name
Inactive
Comments
Add comments for the workflow policy component.
Descriptive text.
How the Primary Component and Nonprimary Components Are Represented in the Workflow Policy Components OBLE
The Primary property provides a visual indication of which component is the primary component and which components are the nonprimary components.
47 3
For example, in Figure 28 the primary property for the workflow policy component named Account is checked, which defines Account as the primary component. Other components that are listed in the Workflow Policy Components OBLE are nonprimary components of the workflow policy component named Account.
Figure 28. Representation of the Primary and Nonprimary Components in the OBLE
Properties of the Workflow Policy Component Column

The Workflow Policy Component Columns OBLE displays a list of the workflow policy component columns that can be monitored for the parent workflow policy component that is currently chosen in the OBLE.
474
Table 96 describes properties that are displayed in the Workflow Policy Component Columns OBLE.
Table 96. Property
Properties of the Workflow Policy Component Column Usage Define the name of the workflow policy column that is defined in the Policy Component Column view. Define the name of the column as it is displayed in the Conditions Field picklist in the Workflow Policies view. Description A picklist of columns that are defined in the Workflow Policy Column view for the table on which the workflow policy component is based. A descriptive name that includes the following characteristics: Consistent with your overall naming strategy Meaningful to the policy maker Descriptive of how the column is used
Workflow Column Name
Alias
The default is the workflow policy column name. Changed Indicates whether the record was added or edited. A check mark indicates that the record was changed.
Properties of the Workflow Policy Program

Table 97 describes properties that are displayed in the Workflow Policy Programs OBLE.
Table 97. Property Name Changed Project
Properties of the Workflow Policy Program Required Yes No No Usage Define the name of the action to perform. This name is exposed in the Actions view in the Siebel client. Indicates recent modifications. Define the Name of the project as defined in the project picklist.
47 5
Table 97. Property Type
Properties of the Workflow Policy Program Required Yes Usage You can choose the following types from the picklist: DB Operation. Insert or update a database table based on arguments. For more information, see DB Operation Type on page 476. External Program. Execute an external program in Windows. Send Message. Compose and send an automatic email message. Send Page. Send a page to a pager. Send Broadcast Message. Send a broadcast message to a group of users.
Workflow object Inactive Comments No No No
Limits use of this program to policies that are associated with this workflow policy object. Checked if the workflow policy program is not active. Add text to describe the workflow policy program.
DB Operation Type
Often, if some data changes, then other data must be changed in accordance. This data dependency is frequently implemented at the Object Manager layer through business components and run-time events. Database operations by workflow policies provide an alternative that works at the database record level. NOTE: It is recommended that DB Operation be used only when the data dependency that is involved is centered around database records rather than around business components. For example, if one database record must be updated when another database record is inserted, then use DB Operation, regardless of which business components the two database records belong to, or whether the two database records belong to a business component at all.
Properties of the Workflow Policy Program Argument

A workflow policy program argument defines recipients, database actions, and available substitutions. Each workflow policy program typically contains several program arguments. The fields that display in this view depend on the type of workflow policy program you choose. A workflow policy program argument is a child of a workflow policy program. CAUTION: Certain text is not allowed in the Default Value workflow policy program argument. Do not use trailing spaces, [newline], or escape characters. Using this text can cause problems, such as failure of Workflow Monitor Agent at run time.
476
Table 98 describes properties that are displayed in the Workflow Policy Program Arguments OBLE.
Table 98. Property Applet
Properties of the Workflow Policy Program Argument Required Optional Optional Usage Define the Picklist applet. Define the text value of a type that depends on the Name of the program argument, an SQL statement, the text of a message, the email address of a recipient, and so forth. The maximum length is 2000 characters. If setting this property, then be sure to note the caution information described in this topic.
Default Value
Name
Required
Define the parameter from a predefined set of values. For a description of values, see Values for the Name Property of the Workflow Policy Program Argument on page 478. The value is entered manually. You do not choose from a picklist.
Picklist Required Source Field Visible Inactive
Optional Boolean Optional Boolean Not applicable
Define the Picklist object. Define whether or not data entry is required. Value is TRUE or FALSE. Define the Picklist Source field. Define whether the data that is supplied by this argument displays. Value is TRUE or FALSE. Checked if the program is not active.
Date Format with a Workflow Policy Program

You must use the following formats when setting a Default Value for time and date fields: Date Column format: 2001-03-16 Time Column format: 19:26:26 Date Time Column format: 2001-04-05 21:25:00
A workflow policy program is executed by the Siebel Server that connects to Oracle through ODBC. As part of this process, the required data is retrieved from the database through this connection. The format of a date in an email is the format that is returned by the ODBC driver, which might be different from that used by Oracle.
47 7
Values for the Name Property of the Workflow Policy Program Argument
You can add functionality to a workflow policy program by defining a new workflow policy program argument. A workflow policy program argument determines how the workflow policy program performs, including what substitutions are available for a workflow policy program and how the recipients are defined. TIP: To familiarize yourself with how a workflow policy program argument is used, examine some of the predefined arguments. For example, in the Workflow Policy Programs OBLE, query the Name property for Run External Program. This object references some of the common workflow policy program arguments that are described in Table 99. Next, query the Name property for Send Email. This workflow policy program references several workflow policy program arguments that are specific to sending a message, as described in Table 100. Table 99 describes values for workflow policy program arguments that are common to a workflow policy program.
Table 99.
Arguments in the Name Property of the Workflow Policy Program Arguments OBLE Usage The row ID of the violating row on which the workflow policy program is acting. Define the base table to which the action is applied. The base table can be unrelated to the record of the primary ID. For example, the violating row is in a child table and you must insert or update a record in the parent table. Tables can also be updated that are not related to the primary ID table. For example, generate a broadcast message when a certain monitored value in the opportunity is true. Allowable Default Value Empty. Tables defined within the Siebel business object repository, as compared to the workflow business object. Workflow business objects are used for monitoring values but are not used to code action programs.
Argument Primary Id Primary Table
Update Row ID
Define the row ID of a table other than the primary table of the workflow policy object. You can associate a workflow policy action with a workflow policy that updates a table. This value is used only when the Operation Type is set to update.
The row ID you must update.
Operation Type
Define the operation to perform: update or insert.
Two possible values for DB Operation: Update or Insert.
478
Table 99.
Arguments in the Name Property of the Workflow Policy Program Arguments OBLE Usage Define the Name of the column in the base table to which the operation is performed. This is one of two field column pairs. Allowable Default Value Allowable values: Text, Variable, Function.
Argument Field Name
New Row ID
For insert operations, this argument is automatically populated with the row ID of the row about to be inserted. Define the Field Name, which must be identical to the Field Name of the first column pair and (Column) appended to the name. This is the second of two column pairs.
Empty.
Field Name (Column)
Actual field name in the base table. The value can not contain leading spaces. Valid SQL query statement for the RDBMS that is used: Oracle, MS SQL, Informix, or Sybase. Not applicable Variable Name.
Sql Statement
Used as a way to identify more data from the database that are used as substitutions when the action is performed. Define the Name of the column in the base table on which the operation is performed. Use as a placeholder for the values that are chosen in the SQL Statement argument.
Sql Statement Inputs Sql Statement Outputs
Items to consider include: The value is entered manually into the Name property of the Workflow Policy Program Arguments OBLE. If you run a database operation with Insert as the Operation Type, then you can choose a Default Value, New Row ID, as described previously, which provides the value for the ROW_Id field for the inserted row.
Passing Multiple Variables to SQL Program Arguments

Multiple variables can be passed into SQL program arguments.
To pass multiple variables to SQL program arguments 1 2

In the Workflow Policy Program Arguments OBLE, choose Sql Statement Inputs. Enter the variable names into the Default Value property. Use the following format: [variable1], [variable2], [variable n]
47 9
Arguments for a Workflow Policy Program that Sends a Message

Table 100 describes program arguments that are specific to some workflow policy programs that send a message.
Table 100. Properties of the Send Message Program Argument Value in Name Property Email Message Email Message Repeated Email Subject Send to Contact Send to Position Send to Employee Usage Define the body of the email message. Define the text that is repeated when the Consolidate feature is used. Define the text in the subject line of the email message. Define the contacts who are available in Siebel CRM. Define the list of the positions that are available in Siebel CRM. Define the list of employees who are available in Siebel CRM. Value Text with available substitutions. Text with available substitutions. Text. Not applicable Not applicable Not applicable
Arguments for a Workflow Policy Program that Sends a Page

Table 101 describes program arguments that are specific to some workflow policy programs that send a page.
Table 101. Properties of the Send Page Program Argument Value in Name Property Send to Contact Send to Employee Send to Position Send to Relative Usage Define the contacts who are available in Siebel CRM. Define the list of employees wo are available in Siebel CRM. Define the list of the positions that are available in Siebel CRM. Define to send to an individual or group of individuals who are related to the Siebel Workflow object. Value Picklist of contacts. Picklist of employees. Picklist of positions. Not applicable
480
Table 101. Properties of the Send Page Program Argument Value in Name Property Alpha Numeric Page Message Numeric Page Message Usage Define the body of the text message. Define the body of the numeric message. Value Text with available substitutions. Text with available substitutions.
Arguments for a Workflow Policy Program that Runs an External Program

Table 102 describes program arguments that are specific to some workflow policy programs that run an external program.
Table 102. Properties of the Run External Program Argument Value in Name Property Command Line Executable Name Executable Type Usage Define the parameters to pass to the executable. Define the full path to the executable to execute. Define the mode in which the Workflow Action Agent executes the external program. Value Not applicable Not applicable Possible values include: Wait No wait
48 1
Reference Materials for Siebel Workflow Predefined Business Services
Predefined Business Services

This topic describes some of the predefined business services that can be used in a workflow process. It includes the following topics: Server Requests Business Service on page 482. Workflow User Event Service Business Service on page 486. Workflow Utilities Business Service on page 487. Workflow Admin Service Business Service on page 489. Other Business Services That Are Used with a Workflow Process on page 491
For more information about predefined business services, see Business Processes and Rules: Siebel Enterprise Application Integration.
Server Requests Business Service

This topic describes the predefined Server Requests business services. It includes the following topics: Synchronous and Asynchronous Modes on page 482 Parameters of the Server Request Broker on page 483 Methods for the Server Requests Business Service on page 483
For more information, see Examples of Using the Server Requests Business Service on page 305. You can use the predefined Server Requests business service to send a generic request to the Server Request Broker. The following processing modes in which the Server Requests business service can send a request are included: Asynchronous Synchronous Schedule
Synchronous and Asynchronous Modes

When in synchronous mode, the Server Requests business service sends a request to the Server Request Broker, then waits for a response. Otherwise, it sends the request but does not wait for a response. It is recommended that you use the Server Requests business service in most cases, rather than the Workflow Process Manager (Server Request) business service. It is more efficient to make an asynchronous call to a workflow process. If a synchronous call is made to a workflow, then the workflow runs in the Object Manager, causing the user to wait for the process to end.
482
Parameters of the Server Request Broker

If calling the Server Requests business service to submit a component request, then you must define parameters for the Server Request Broker in the input property set and parameters that are specific to a component in the child property set. Items to consider include: If calling the Server Requests business service in order to call a server component, then the names of the component parameters must be referenced by the Alias Name for the parameter. The Alias Name usually does not contain spaces. Failure to use the correct format results in an error message. Table 103 describes correct and incorrect formats.
Table 103. Format of the Component Parameter for Calling the Server Requests Business Service Correct Format ObjReq.SetProperty "BCName", "Account" Incorrect Format ObjReq.SetProperty "Buscomp Name", "Account"
Parameters for components must be defined with the Alias Name in the child property set. There is no validation of the Alias Name. These arguments do not appear in the picklist in the Administration-Business Process views.
Passing Parameters to Server Components If you must pass parameters that are not listed as available arguments, then you can define a custom business service that contains the necessary parameters. Alternatively, you can define a component job that includes the parameters that are defined as part of the job definition. For more information on component jobs, see Siebel System Administration Guide.
Methods for the Server Requests Business Service

Methods that are available for the Server Requests Business Service include: Submit Request. Use this method to submit a request to the Server Request Broker. Cancel Request. Use this method to cancel a server request that is currently waiting to run.
48 3
Arguments of the Submit Request Method Table 104 describes arguments for the Submit Request method.
Table 104. Arguments of the Submit Request Method of the Server Requests Business Service Argument Component Description Required if Component Job is not entered. Enter the name of the server component to run. Component Job Required if Component is not entered. Enter the name of the component job to run. Delete After Delete After Units Optional. Number of iterations before deleting the request. Works with Delete After Units. The default value is 0 (zero). Optional. The units to measure the iterations for the Delete After argument. The default value is NoReq for synchronous where the request is not saved to the database, and Eon for asynchronous where the request is never deleted. Other possible values include: Description Enterprise Server Hold Flag Maximum Execution Time Method ASAP SECONDS MINUTES HOURS DAYS WEEKS MONTHS YEARS
Optional. A description of the server request. Not applicable Optional. For an asynchronous request only. Flag to indicate whether or not to hold the request. For future use. Optional. Only applicable for a service based server component. For example, Workflow Process Manager or Communications Manager. Define the business service method to call.
484
Table 104. Arguments of the Submit Request Method of the Server Requests Business Service Argument Mode of Server Request Description Required. Instructs the Server Request Broker how to handle the server request. While in Auto mode, the Server Request Broker sets the mode to Synchronous or Schedule, depending on whether the Siebel client is connected or mobile. Possible values include: DirectDB: Asynchronous request, written directly to the S_SRM_REQUEST table NOTE: It is recommended that you use this argument in order to call an asynchronous request. If DirectDB mode is used, then the data in the S_SRM_REQUEST table is not lost. If you use Async when the Workflow Process Manager reaches MaxTasks, then it cannot process every SRM request. Number of Retries Request ID Needed Async: Asynchronous Sync: Synchronous Schedule: Schedule Auto: Automatic configuration
Maximum number of times the request is retried in case of error. Optional. Only applicable to asynchronous and schedule mode. If this argument is set to false, then these two server requests return more quickly. Amount of units of time to repeat. Optional. The interval for repeating a request. Optional. Possible values are Scheduled Start, Actual Start, and End. Optional. Unit of intervals for a repeating request. Optional. The number of repetitions for a repeating request. Used for resubmitting the request, if the request errors out. Default setting is FALSE.
Repeat Amount Repeat Interval Repeat From Repeat Interval Units Repeat Number Retry On Error
Repeat Unit Request ID Server Name Start Date Storage Amount Storage Units
Unit of time to repeat. Used for request key based routing. Optional. Enter the specific server from which this request is run. Optional. Start date and time. Optional. Enter the amount of time that the server request is stored in the database in the event that the server is down. Optional. Enter the units to measure the iterations for the Storage Amount argument. The units are the same as Delete After Units.
48 5
Arguments of the Cancel Request Method Table 105 describes arguments for the Cancel Request method of the Server Requests Business Service.
Table 105. Arguments of the Cancel Request Method of the Server Requests Business Service Argument Request ID Repeat Number Description Required. The ID of the server request to be cancelled. Optional. The number of repetitions of the repeating server requests that are to be cancelled.
Workflow User Event Service Business Service

The Workflow User Event Service business service is used for one way communication from the Siebel client to the server component for the Workflow Process Manager in order to send notification that a user event occurred. A User event can be generated in the Siebel enterprise where a Siebel business service is used by calling the Workflow User Event Service business service. To start a long-running workflow to be run in Workflow Process Manager, you must send a notification. For more information, see About the User Event on page 161.
486
This service contains one method, GenerateEvent. Table 106 describes arguments for the GenerateEvent method.
Table 106. Arguments of the GenerateEvent Method of the Workflow User Event Service Business Service Argument UserEventName Description The name of a user event is an agreement between the creator, which is an external entity, and the recipient, which is the workflow process. It includes no special significance, except that the incoming event name and the workflow instance definition must define exactly the same user event name in order to successfully communicate with each other. A user event name must be unique. It is recommended to name the event so that it reflects the business purpose it serves. For example, Event Transferring Send Order Confirmation from Vitira To Siebel V2. CorrelationValue Used to match an incoming message with an instance of a workflow process by using business data, such as an order number. If a workflow communicates with an external entity, then the external entity might not be aware it is communicating with a workflow process. In such cases, it is difficult for the external entity to use a Siebel identifier, such as the instance Id for the workflow process, to identify the recipient. It is more convenient to use business data, such as an order number, to identify the recipient. The correlator serves this purpose. Correlation applies to a user event that reaches a long-running workflow, which can define a process property as a correlator. NOTE: Only one process property can be used as a correlator. <Value> (Payload) If the user event is generated, then the user can define data as payload. This data is delivered to the instance of a workflow process that receives the event. If the workflow is defined to wait for a user event, then the definition can define a process property to receive this payload data. The payload is a single value. Only one payload can be passed. NOTE: If your situation requires you to send complex or structured data, then it is recommended you use the XML converter to convert the data into an XML document, then pass the resulting XML string as the payload of the event. The receiving workflow process can then call the XML converter again to recover the original data structure.
Workflow Utilities Business Service

The Workflow Utilities business service contains generic utilities that are used most typically in a test environment. For an example that uses the Workflow Utilities business service, see Example of Defining a Workflow Process That Traverses a Record Set to Close Service Requests That Are Obsolete on page 264.
48 7
Echo Method of the Workflow Utilities Business Service

The Echo method of the Workflow Utilities business service returns a mirror image of the input arguments. Echo copies the echo inputs to the echo outputs. For example, Echo can be used to build or format the body of a mail message before calling the SendMessage method of the Outbound Communications Manager. Table 107 describes arguments for the Echo method of the Workflow Utilities business service.
Table 107. Arguments for the Echo Method of the Workflow Utilities Business Service Argument Input Arguments Output Arguments Description This method accepts input arguments. An exact copy of the input arguments.
The Echo method was known as the Return Property Values method in Siebel CRM version 6.x. In Siebel version 7.0.3, the display name Return Property Values was omitted from Siebel Tools.
Output Parameter Usage with the Echo Method

When using the Echo Method of the Workflow Utilities business service, you define the output parameters that are populated with values from the active record of the business component that is currently manipulated by the workflow process. For example, assume you must acquire the value in the Price List Id field from the active record in the Account business component. You can use the Echo method with no input argument defined and one output argument defined. Table 108 describes an example output parameter that is defined on the Workflow Utilities business service.
Table 108. Example of Output Argument That Are Used with the Echo Method to Acquire a Value Property Property Name Type Business Component Name Business Component Field Value Echo Variable Business Component Account Price List Id
In this example, as a result of running the workflow process, the Echo Variable process property is populated with the value in the Price List Id field of the active record for the Account business component.
488
Table 109 describes methods of the Workflow Utilities business service.
Table 109. Methods on the Workflow Utilities Business Service Method Name Sleep PropSetToText TextToPropSet DynamicDispatch Echo Description Sleeps for the number of seconds defined by [value]. Converts a hierarchical input property set into a single string. Converts a single string into a hierarchical output property set. Calls a service. Sends inputs to outputs.
Workflow Admin Service Business Service

The Workflow Admin Service business service allows a workflow process to perform administrative work on multiple workflow processes that are defined by a search specification. Example administrative work includes deploy, activate, export and import. This topic includes the following topics: Methods of the Workflow Admin Service Business Service on page 489 Calling the Workflow Admin Service Business Service on page 491
For usage instructions, see Import and Export when Using Certain Features of Siebel Tools on page 222.
Methods of the Workflow Admin Service Business Service

Each method of the Workflow Admin Service business service is defined by a search specification. The following methods are included: Export. Exports workflow processes into a defined directory. Each workflow is exported to a separate .XML file with a file name that is the concatenation of the name of the workflow and the version number. Import. Imports the export files for a workflow process into a defined directory. Deploy. Deploys workflow processes. Activate. Activates workflow processes. DeleteDeploy. Deletes workflow deployment records.
48 9
Table 110 describes arguments for the methods on the Workflow Admin Service business service.
Table 110. Arguments of the Workflow Admin Service Business Service Method Name Argument Type Input Argument Name ExportDir FlowSearchSpec Description The directory to which the export files are written. For example, D:\workflows. The search specification that is used to identify the workflow processes to be exported. For example, [Process Name] like 'User Reg*' The repository from which workflow processes are exported. The default value is Siebel Repository. The number of workflow processes that are exported by the service. The directory where the workflow export files are located. The search specification that is used to identify the export files for workflow processes that are to be imported. For example, User*.xml The repository into which workflow processes are imported. The Tools project into which workflow processes are imported. The project must be locked in order for the import to succeed. The number of workflow processes that are imported by the service. The search specification that is used to identify the workflow processes that are to be deployed. A default search specification, [Status] = "In Progress", is automatically added to FlowSearchSpec. It is not necessary to explicitly define the search specification. Output NumFlowDeployed The number of workflow processes that are deployed by the service.
Export
Repository
Output Import Input
NumFlowExported ImportDir FileSearchSpec
Repository ProjectName
Output Deploy Input
NumFlowImported FlowSearchSpec
490
Table 110. Arguments of the Workflow Admin Service Business Service Method Name Activate Argument Type Input Argument Name FlowSearchSpec Description The search specification that is used to identify the workflow processes to be activated. A default search specification, [Status] = "COMPLETED", is automatically added to FlowSearchSpec. It is not necessary to explicitly define the search specification. Output DeleteDeploy Input Output NumFlowActivated FlowSearchSpec NumFlowDeleted The number of workflow processes that are activated by the service. The search specification that is used to identify the workflow deployment records to be deleted. The number of workflow deployment records that are deleted by the service.
Calling the Workflow Admin Service Business Service

It is recommended to call the Workflow Admin Service business service through the Business Service Simulator when you must activate or deploy a large number of workflow processes in bulk. This way, you can supply the search specification for each set of workflows. It is not recommended to run the Workflow Admin Service business service from within a workflow because you must change the input search specification inside the workflow for each set of workflows that are involved, resulting in the requirement to revise the workflow each time it calls the Workflow Admin Service business service.
Other Business Services That Are Used with a Workflow Process

This topic describes other business services that are sometimes used with a workflow process.
Synchronous Assignment Manager Requests Business Service

The Synchronous Assignment Manager Requests business service is used to assign an object by using Assignment Manager rules. This service includes one method, named Assign. The Assign method sends a request to the assignment manager server component. For more information, see Siebel Assignment Manager Administration Guide.
49 1
Assign Arguments for the Synchronous Assignment Manager Requests Business Service Table 111 describes arguments for the Assign method of the Synchronous Assignment Manager Requests Business Service.
Table 111. Arguments for the Assign Method of the Synchronous Assignment Manager Requests Business Service Argument Assignment Object Name Object Row ID Description Required. The object that you must assign. Required. The row ID for the object you must assign. To assign the work item for the workflow process, set this to the Object Id process property. An output argument of this method.
Reply
Errors Due to Locked Records The Synchronous Assignment Manager Requests business service attempts to assign records that meet the appropriate criteria, even if they are locked. To prevent an error in your workflow process that is caused by a locked record, set up a condition in your workflow process or workflow policy that skips a record that does not meet the following condition: ASGN_USR_EXCLD_FLG = N.
Outbound Communications Manager Business Service

For more information, see Examples of Using the Outbound Communications Manager Business Service on page 309.
Report Business Service

The Report business service automates the work that is required to send, schedule, print, save, or email a report. It also automates administrative jobs, such as synchronizing a new user. For more information, see Siebel Reports Administration Guide.
FINS Data Transfer Utilities Business Service

The FINS Data Transfer Utilities business service allows you to transfer data from a source business component to a destination business component without using a script. For more information, see Siebel Finance Guide.
FINS Validator Business Service

The FINS Validator business service allows you to validate data based on a predefined rule. It is developed through Application Administration, not through a script. The Validator business service supports custom messages. For more information, including calling the FINS Validator Service from a workflow, see Siebel Finance Guide.
492
Dynamic UI Business Service

The Dynamic UI business service and associated administration views allow you to define and render a view that contains a single, read only applet in the Siebel Financial Services application. For more information, see Siebel Finance Guide.
49 3
494
Glossary
This appendix describes terms used with a workflow process. It includes the following topics: Siebel Workflow Glossary on page 495
Siebel Workflow Glossary

This topic describes terms that are used with a workflow process. It includes the following topics: Terms That Are Used with a Workflow Process on page 495 Terms That Are Used with a Workflow Policy on page 499
Terms That Are Used with a Workflow Process

Table 112 describes common terms that are used with Oracles Siebel Workflow.
Table 112. Terms That Are Used with a Workflow Process Term 7.0 Flow Definition A workflow process that provides backward compatibility for a workflow that is defined prior to version 7.7. Data that is passed to or received from a workflow process or a step within a workflow process. A possible outcome of a step within a workflow process. Description Set in the Workflow Mode property on the workflow process.
Arguments
Not applicable
Branch
A branch is followed by a step in the workflow process. If the conditions for the branch are met, then the work item proceeds to the step that follows the branch. Conditional logic is implemented on the branch connector. A business object represents an entity in the Siebel application that you must monitor. A workflow process is based on only one business object. Business objects are defined in Siebel Tools.
Branch Connector Business Object
A connector that emanates from a Start step, decision point, Wait step, or User Interact step. A group of one or more business components.
49 5
Glossary Siebel Workflow Glossary
Table 112. Terms That Are Used with a Workflow Process Term Business Process Definition A process that is associated with operational objectives and business relationships. A type of step in a workflow process in which an automated call is made to a service, such as the Outbound Communications service that handles inbound and outbound messaging. A definition of the relationship between two workflow process steps. The principles that are used to evaluate the logical flow that must be taken on a branch in a workflow process. A type of step in a workflow process in which the work item branches off to different steps, depending on a set of conditions. Description A business process is a set of one or more linked procedures, which collectively realize a business objective. An example of a business process is managing a new service request. A workflow process can include one or more business service steps.
Business Service
Connector
Not applicable
Decision Condition
Typically, a decision condition is defined on a connector that emanates from a decision point. A Decision Point consists of possible branches for that point in the business process. Each branch consists of one or more conditions that must be met in order for a work item to follow that branch. A workflow process can include one or more Decision Points. Not applicable
Decision Point
End Step
A type of step in a workflow process that specifies when a process instance is finished. A type of step in a workflow process that executes in response to a deviation from normal processing. The name of the business component to evaluate an expression that is used as part of a search spec input argument. The name of the business component to provide the group of records on which a search is performed in response to a Siebel Operation step. A mechanism for providing data and configuration information as input to a step in a workflow process.
Error Exception Expression Business Component Filter Business Component
An error exception can be an error that is generated by the system or is generated by an end user. Not applicable
The Filter Business Component is part of the search spec input argument.
Input Argument
Not applicable
496
Table 112. Terms That Are Used with a Workflow Process Term Interactive Workflow Process LongRunning Workflow Process Output Argument Process Property Definition A workflow process that assists the end user in navigating across Siebel views. A persistent workflow process that can last for hours, days, or months. Description Set in the Workflow Mode property on the workflow process. Set in the Workflow Mode property on the workflow process.
A mechanism for providing data and configuration information as output from the step of a workflow process. A storage field in a workflow process that is used to contain values for use in steps as input and output arguments or for performing evaluations. A graphical flowchart interface that is used to debug a workflow process. A type of input argument that allows you to restrict the records that are considered when a Siebel Operation step is executed. A workflow process that executes a set of operations upon the calling of an event. A type of step in a workflow process that performs database operations on a business component record or field. Example operations include insert, query, or update. A type of step in a workflow process that defines the conditions to initiate an instance of a workflow process. When the conditions are met, an instance of the process is initiated. A workflow object that provides capabilities for branching logic within a workflow process.
Not applicable
Not applicable
Process Simulator Search Spec Input Argument Service workflow process Siebel Operation
Not applicable
Not applicable
Set in the Workflow Mode property on the workflow process. Not applicable
Start Step
A workflow process includes only one start step.
Step Branch
Not applicable
49 7
Table 112. Terms That Are Used with a Workflow Process Term Step Instance Definition The instance of a step in a workflow process that is initiated. Description A start step is initiated when conditions defined for the start step are met. A Decision Point is initiated when conditions for a branch connector are met. Other steps are initiated when the previous step finishes. Not applicable Not applicable
Step Recipient Stop Step
The intended recipient of a sub process step. A type of step in a workflow process that specifies the conditions that cause an instance a process to terminate prior to completion. A workflow process that is called from another workflow process.
Sub Process
A sub process includes a separate workflow process object definition. A Sub Process is a type of step. There can be one or more Sub Process steps in a workflow process. A Task step is similar to a Sub Process step in that the task step represents a container for a further set of steps below the level of the steps in the workflow in which the task step is defined. A workflow process that contains one or more User Interact steps that guide a user through a defined flow of Siebel views based on user action, or executes a defined set of actions. Not applicable
Task
A type of step in a workflow process step that calls a Task from within a business process.
User Interact Step Wait Step
A type of step in a workflow process that is used to control the flow of Siebel views within an application. A type of step in a workflow process that specifies when the instance of the process pauses execution and the duration of the pause. A Window in Siebel Tools that dynamically displays record values of a business component and process property values of a workflow process. The representation of the work that is processed in the context of a step within the instance of a workflow process .
Watch Window
These values are associated with and are manipulated by the workflow process being simulated.
Work Item
A work item is an instance of a business object.
498
Table 112. Terms That Are Used with a Workflow Process Term Workflow Mode Definition A property of the workflow process that is used to characterize runtime behavior for a workflow as a Service Flow, Interactive Flow, Long Running Flow, or 7.0 Flow. The representation of a business process. Description Not applicable
Workflow Process
A workflow process comprises one or more steps that indicate when a business process starts and ends and includes information about individual work that is performed within the business process. An instance of a workflow process is initiated when the input conditions for the workflow are met. An instance consists of one or more step instances and contains one or more work items. Not applicable
Workflow Process Instance
An instance of a workflow process that is initiated.
Workflow Step
An activity within a workflow process. Steps are logically linked together in order to define a process.
Terms That Are Used with a Workflow Policy

Table 113 describes common terms for Workflow Policies.
Table 113. Terms That Are Used with Workflow Policies Term Business Object Definition A group of one or more business components. Additional Description A business object represents an entity in Siebel that you must monitor. A workflow policy object is based on only one business object. Business objects are defined in Siebel Tools. Not applicable
Business Rule
The definition of how an organization must carry out a process in operations for the organization. An entity in Siebel Tools that is displayed as a node on the Object Explorer.
Object Type
For example, workflow policy objects, workflow policy components, workflow policy columns, and policy programs are object types.
49 9
Table 113. Terms That Are Used with Workflow Policies Term Policy Action Definition An event that Siebel executes when policy conditions are true and properties of the workflow policy are satisfied. A systematic expression of a business rule. Additional Description A policy action is based on programs. A policy action is defined in the Action applet of the Workflow Policies view. After you define a policy action, it can be used in a workflow policy. A workflow policy contains one or more policy conditions and one or more policy actions. If the policy conditions for a workflow policy are true, then the policy action occurs. A workflow policy is contained by one workflow policy group and is related to one workflow policy object. A workflow policy contains more properties that govern behavior for the policy. Workflow policies are defined in the Workflow Policies view. You use a workflow policy column when defining a workflow policy condition for a workflow policy. A workflow policy column must be associated with a workflow policy component in order for it to be used in a workflow policy. A workflow policy column that is associated with a workflow policy component is known as a workflow policy component column. Workflow policy columns are defined in Siebel Tools. A workflow policy component contains workflow policy columns. A workflow policy component is defined in Siebel Tools.
Workflow Policy
Workflow Policy Column
A column in a table in the Siebel database that you must monitor.
Workflow Policy Component
A component that defines the Siebel database tables that you must monitor. A workflow policy component also defines the relationship between tables. A workflow policy column that is associated with a workflow policy component.
Workflow Policy Component Column Workflow Policy Condition
A workflow policy component column defines the database column that can be used in a workflow policy condition of a workflow policy. A workflow policy component column is defined in Siebel Tools. The result of the comparison is true or false. A workflow policy condition is defined in the Workflow Policies view. A workflow policy condition is defined by defining a workflow policy column, defining a comparison operator, then entering or choosing a value, if appropriate.
An expression that is compared against data in the Siebel database.
500
Table 113. Terms That Are Used with Workflow Policies Term Workflow Policy Group Definition A group of one or more workflow policies. Additional Description A workflow policy group allows you to group workflow policies that share common required behavior. Siebel Server processes monitor workflow policy groups. For example, workflow policies that must be monitored hourly are different in a workflow policy group from those that are monitored weekly. A workflow policy group is defined in the Policy Groups view. A workflow policy object represents an entity in the Siebel application that you must monitor. A workflow policy is based on only one workflow policy object. A workflow policy object is defined in Siebel Tools. Types of events include Send Email, Send Page, Database Operation, Send Broadcast Message, and Run External Program. Different properties are associated with a program based on the event type. Some of the properties that can be defined for a program include the fields that can be substituted into a message, the possible recipients of a message, and the database columns that you must update. A workflow program is defined in Oracles Siebel Tools.
Workflow Policy Object
A group of one or more workflow policy components.
Workflow Program
The definition of an event.
50 1
502
Index
A
a workflow step deleting 121 action parameters, definition of 328 ActionAgent parameter 423 ActionInterval parameter 423 actions creating for workflow policy 342 working with for workflow policies 341 Actions applet field descriptions, Actions view 341 applet fields WF Process Props applet 52 WF Step Recipients applet 468 WF Steps applet 68 architecture of workflow components 22 arguments action parameters for policies 328 Create Email Activity program 394 creating SQL statements for workflow policy program 369 Database Operation program 386 definition of 495 name property values for workflow policy programs 478 Run External program 387 Send Email program 384 Send Message Broadcast program 385 Send Page program 383 Workflow Policy Program Arguments properties 476 workflow policy program, example of creating 368 Assign Non-Respondents policy, creating 399 Assign to Campaign Email action 395 Assign to Campaign program 394 Assignment Request, Workflow Policy program 329 asynchronous server request 482
batch mode BatchMode parameter 423 running a workflow process 172 branch connector, definition of 495 branch, definition of 495 branches Decision step, defining 92 User Interact next step branches, defining 86 business analyst, role of 114 business object defining primary business components for 83 definition of 495, 499 business process definition of 496 gathering information on 99 business rule, definition of 499 business service definition of 496 using in a workflow process 70 Business Service step about 70 defining 70 business service, predefined asynchronous server request 482 Outbound Communications Manager 491 synchronous server request 482 Workflow Utilities, arguments 487 business service, workflow policy action, executing from, note 344
C
calculated fields, updating 78 campaigns Create Email Activity program 394 marketing campaigns, scenario with Workflow policies 394 CheckLogCacheSz parameter 424 Comparison 145 comparison operations condition criteria 189 comparison values entering date calculations 375 specialized 371 standard 370 using in the Conditions applet 370
B
Batch feature usage example 351 Batch field for workflow policies 429 batch manager usage with primary and non-primary business components 173
50 3
Index D
Compose Condition Criteria dialog box field descriptions 95 condition criteria, definition of 496 Conditions applet using comparison values 370 using specialized comparisons 371 using standard comparisons 370 connector defining for Decision branch 92 defining for User Interact next step branches 86 definition of 496 diagramming a workflow process 122 point in connector, removing or adding 123 Create Email Activity about and arguments 394 creating 396
D
database Siebel database, described 22 specialized comparisons 373 triggers, creating 403 Workflow Policies database tables 417 Database Operation, Workflow Policy program about 329 date calculations, comparison values 375 Decision step about working with 72 branches, defining 92 decision step definition of 496 default SQL statements 392 defining a workflow process example of 256 DeleteSize parameter 424 deleting a workflow process 121 a workflow process step 121 workflow process instance 231 deploying a workflow process 211 example of 263 on a regional node 214 to a mobile client 213
E
email consolidating for recipient, about using batch mode 429 creating Workflow policy for 358 example of consolidating for recipient 351 Email for CD-ROM Campaign policy, creating 398
Email Manager setting up on Siebel Server 410 troubleshooting 414 End step about 90 defining 91 end step definition of 496 Error Code default process property 54 error exception, definition of 496 error handling about 164 assigning an error-workflow process to a subprocess 169 defining an error-workflow process 168 passing properties and property sets to an error-workflow process 58 using exceptions 164 Error Message default process property 54 errors assigning an error-workflow process to a subprocess 169 defining an error exception to handle errors 164 defining an error-workflow process 168 handling 164 passing properties and property sets to an error-workflow process 58 errors, correcting a process and resuming 251 events configuring a long-running workflow to wait for user events 162 generating user events 161 handling 157 using run-time events 157 using user events 161 Workflow User Event business service 486 events handling 157 suspended interactive workflow 139 user logout event 139 events, tracing and logging 236 Example 264 example defining a workflow process 256 deploying a workflow process 263 examples testing a workflow process 262 expression business component, definition of 496 External Program, Workflow Policy program about 329
504
Index F
F
FDR See Siebel Flight Data Recorder files field descriptions Compose Condition Criteria dialog box 95 input arguments for Business Service steps, Subprocess steps, and Wait steps 49 output arguments for Business Service steps, Subprocess steps, and Siebel Operation steps 50 WF Process Props applet 52 WF Step Recipients applet 468 WF Steps applet 68 field name modifications 364 filter business component, definition of 496
G
Generate Trigger (GenTrig) functions of 403 tips for running 404 Generic Request Server, Workflow Policy program 329 GenReqRetry parameter 424 global implementation of Workflow 175 GroupName parameter 424 groups creating for workflow policy 340 planning policy groups 332, 333, 340 working with for workflow policies 340 guidelines automation solutions, comparing 102, 103 batch mode, running in 172 branching, defining 209 Business Integration Manager, using 156 conditions and actions, configuring 327, 428 DB operations, using 476 debugging, setting monitoring levels for 235 declarative or scripting techniques, choosing between 94 email consolidation, using Monitor Agent with 428 errors, setting Ignore Errors to handle 425 externalizing parameters, requirements for 317 long-running workflows, using a stateful business service with 450 migrating workflows, avoiding incremental deployment when 221 non-persistent workflows, setting visibility for 460 parameters, hard coding 120 policies, monitoring 341 Process Mode property, configuring the 88
recovery, techniques for 250 run-time events, configuring 145, 157 S_ESCL_REQ, using database tools with 419 sending complex or structured data, converting data to XML for 487 SQL, using 369 state management, specifying 447 Stop step, using the 89 subprocess, passing the Object Id to 74 synchronous and asynchronous processing, configuring 214, 482, 485 triggers, generating 406 Type property, configuring the 57 User Event business service, configuring the 161 user events, configuring 162 workflow policy program, defining 367 workflow processes, activating 217
I
IgnoreError parameter 425 input argument, definition of 496 input arguments defining for Subprocess step 74 field descriptions for Business Service steps, Subprocess steps, and Wait steps 49 installation verifying workflow policies 401 interactive workflow process building 130 forward and backward navigation 131 Object Id 55 suspending and resuming, about 137 suspension, events handling 139 suspension, in-memory cache 139 suspension, user logout event 139 synthetic event, creating 131 synthetic event, creating Next and Back synthetic events 133 synthetic event, creating ResumeLastIntFlow synthetic event 136 synthetic event, creating SaveWorkflow synthetic event 134
K
KeepLogDays parameter 425
L
LastUsrCacheSz parameter 425 license key validation 402 logging events, table of 236 long-running workflow process assigning subprocess to end user 140
50 5
Index M
building 139 Object Id 55
M
MailServer parameter 425 MailTo parameter 426 marketing campaigns, scenario with Workflow policies 394 Message Broadcast Arguments applet, about and arguments and values 384 migrating policies, suggested strategies for 336 production environment, workflow policies to 443 workflow processes 218 multilingual environments configuring a workflow process 175 defining expressions for a workflow process 176 multiple records, executing actions in a workflow process for 172 multi-value group updating a field based on a 78 MVG updating a field based on a 78
output arguments definition of 497 field descriptions for Business Service steps, Subprocess steps, and Siebel Operation steps 50
P
Page Manager parameters for 413 setting up 411 troubleshooting 414 palette items in Process Designer 65 parallel processing, Workflow processes, supported by 94 persistence about and using 141 enabling, setting 142 planning workflow policies, determining what to monitor 334 workflow policies, planning policies and conditions 334 workflow policy groups 332, 333, 340 policies creating actions for 342 creating groups for 340 monitoring 334 planning policies and conditions 334 Policies applet described, Workflow Policies Groups view 340 policy action See programs creating 342 definition of 500 working with 341 policy condition definition of 500 role in workflow policies 328 Policy Frequency or Trend Analysis chart, viewing 438 policy groups creating 340 planning, about and reasons for using 332, 333, 340 predefined programs assigning manager as owner 390 close date, changing 388 owner, changing 389 Run External Program 354, 386 Send Email, using and arguments 383 Send Quote Page 392 table of 381
N
name, modifying workflow policy component column and policy field names 364 naming conventions for a workflow process 44, 120 for process properties 44, 120 NumRetries parameter 426
O
Object Explorer workflow policy object, defining 363 Object Id default process property 54 in long-running, interactive, and service workflow processes 55 Object Manager running a workflow process 152 object properties described 40 object type definition in relation to Siebel Tools 40 definition of 499 program types, table of 475 workflow policy objects, modifying 378 Outbound Communications Manager available methods, described 491
506
Index R
workflow action, using a predefined program to create 329 workflow policy programs 388 Process Designer design functions 45 diagramming a process 122 palette items 65 Process Instance Id default process property 55 process properties 47 comparing with property sets 48 concatenating 59 defining 124 naming conventions 44, 120 passing field values to example 153 workflow processes, about passing to 48 process property, definition of 497 Process Simulator running 204 testing a workflow process 197, 198 testing a workflow process, caution 204 workflow process, using to start 198 process simulator definition of 497 process steps Business Service step, about 70 Business Service step, defining 70 Decision step, about working with 72 deleting 121 End step, about 90 End step, defining 91 Siebel Operation step, about 75 Siebel Operation step, defining 76 Siebel Operation step, defining search specification, examples 77 Siebel Operation step, defining search specifications 77 Start step, about 69 Stop step, about 88 Stop step, defining 89 Subprocess step, about 73 Subprocess step, defining 73 Subprocess step, defining input arguments 74 testing with Process Simulator, about 198 User Interact step, about 85 User Interact step, defining 86 Wait step, about 87 Wait step, defining 87 production environment, migrating to 443 program property descriptions, workflow policies 475 programs workflow policy action types 329
properties Run External Program Argument 481 Send Message Argument 480 tasks 115 Workflow Policy Program Argument properties, table of 477 workflow policy programs 475 property sets comparing with process properties 48 passing to a workflow process 48
R
recipient types, table of 343 recovery workflow process, about 250 workflow process, automatic 250 workflow process, manual 251 reference workflow step and connector properties 450, 462 ReloadPolicy parameter 426 repository setting, verifying 402 Requests parameter 427 Run External Program Argument properties, table of 481 workflow policy program, creating action 354 workflow policy program. about and example and arguments 386 Run Workflow Process, about using to define a policy 143 run-time events 157
S
S_ESCL_ACTION table 417, 418 S_ESCL_ACTN_REQ table 418 S_ESCL_LOG table 417, 418 S_ESCL_REQ table 417, 418 S_ESCL_STATE table 417, 418 SARM See Siebel Application Response Management scripts, starting workflow processes, examples 152 search specification search spec input argument, definition of 497 seeded workflow processes 111 Send Campaign Email, using 393 Send Email creating for Workflow policy 358 Message Arguments applet 383 using and arguments 383 Send Message
50 7
Index T
Workflow Policy program 329 Send Message Argument, properties, table of 480 Send Page Send Page Program Type, about and arguments 382 Workflow Policy program about 329 Send Quote Page, using and SQL statement examples 392 Send to Relative recipient type, about sending email or page 345 server requests, submit request arguments 484 service requests assigning manager as owner 390 close date, changing to todays date 388 owner, changing to todays date 389 service workflow process Object Id 55 Siebel administrators correcting a process and resuming 251 deleting a workflow process instance 231 stopping workflow processes 229 Siebel Application Response Management 238 Siebel ARM See Siebel Application Response Management 238 Siebel Client description 22 Siebel database, described 22 Siebel eScript, examples of calling from a workflow process 152 Siebel FDR files See Siebel Flight Data Recorder files 239 Siebel Flight Data Recorder files 239 Siebel Operation Object Id default process property 55 Siebel Operation step about 75 defining 76 defining search specification, examples 77 defining search specifications 77 definition of 497 updating fields based on multi-value groups 78 Siebel Server description of 22 Email Manager, setting up 410 setting up for Page Manager 411 task trace file, created for listed processes 436 Siebel Tools customizing Workflow Policies 331
description 22 Workflow Processes and 39 Siebel VB, examples of calling from a workflow process 152 Sleep Time parameter 427 specialized comparisons, descriptions 373 SQL SQL script file 406 statements, created for workflow policy program arguments 369 statements, types of 392 Start step about 69 defining a start step 69 definition of 497 starting a workflow process about 143 as a configured business service 147 from a script 152 starting of a workflow process from a run-time event 144 from a Workflow policy 143 step branch, definition of 497 step instance, definition of 498 step recipient, definition of 498 Stop step about 88 defining 89 definition of 498 Subprocess step about 73 assigning to end user for a long-running workflow process 140 defining 73 defining input arguments 74 definition of 498 synchronous server request 482 synthetic event creating 131 creating Next and Back events 133 creating ResumeLastIntFlow event 136 creating SaveWorkflow event 134
T
task, definition of 498 tasks properties 115 testing a workflow process, example of 262 workflow process, Process Simulator 198 testing workflow policies 440 trace file Siebel Server task trace file, created for listed
508
Index U
processes 436 tracing and logging events 236 workflow process, increasing tracing levels 236 workflow process, log levels 236 Traversing a record set technique definition of 79 example 264 trigger database triggers, creating 403 Generate Trigger (Gen Trig), functions 403 Generate Trigger (Gen Trig), tips of running 404 invalid trigger, avoiding in production environment 443 troubleshooting Email and Page Manager 414 notes on 442
W
Wait step about 87 defining 87 definition of 498 global time calculations 176 watch window definition of 498 example usage 59, 266, 275 WF Process Props applet field descriptions 52 WF Step Recipients applet field descriptions 468 WF Steps applet field descriptions 68 wildcards, using in standard comparisons 371 work item, definition of 498 Workflow associated job roles 21, 114 definition 16 deployment architecture 30 development architecture 26, 30 general principles 15 global implementation 175 global implementation, configuring a workflow process in a multilingual environment 175 global implementation, defining expressions for a workflow process 176 global implementation, Wait steps and global time calculations 176 interaction with other Siebel components 36 processing modes, 7.0 Flow 129 processing modes, about 127 processing modes, Interactive Flow 128 processing modes, Long Running Flow 129 processing modes, Service Flow 128 requirements 100 run-time architecture 31 Siebel Tools and 39 simulation architecture 28 starting mechanisms 105 upgrading 253 Workflow Action Agent functions of 415 to run processes of 416 Workflow Action Arguments applets, described 341 Workflow Actions creating Assign to Campaign Email 395 creating Create Email Activity 396 creating Send Campaign Email 395
U
Upsert Operation, definition of 82 Usage 173 user events configuring a long-running workflow to wait 162 using 161 Workflow User Event business service 486 User Interact step about 85 branches, defining 86 creating substitute view names 86 defining 86 User Interact step, definition of 498 user, workflow role described 114
V
Validate Tool using for a workflow process 197 values arguments for the name property of a workflow policy program 478 described 41 Message Broadcast program type 385 Recipients applet fields 343 Run External program type 387 Send Email program type 384 Send Message Broadcast program type, table of 385 VerCheckTime parameter, setting 64 view names creating substitutes using process properties 86
50 9
Index W
creating Send Email Message Program type 383 creating Send Page Program type 382 using Database Operation program type 386 Workflow Administrator, role of 114 Workflow components architecture 22 relationship between component and primary 379 relationship between Workflow object and 325 Workflow Conditions applet using specialized comparisons in 371 Workflow End User, workflow role, described 114 workflow groups defining a workflow policy group 397 planning 332 Workflow Groups applet about using 340 workflow job roles business analyst 114 end user 114 workflow configurator 114 Workflow Manager See Workflow Policies workflow mode, definition of 499 Workflow Monitor Agent parameters 423 starting 417, 419 testing workflow policies 441 Workflow objects relationship between Workflow policy components and 325 workflow persistence about 141 enabling, setting 142 Workflow Policies Assign Non-Respondents policy, creating 399 conditions, table of specialized comparisons 373 created for Send Email 358 creating 346 creating a policy action 342 creating a workflow policy group 340 definition of 328 Email for CD-ROM Campaign policy, creating 398 license key validation 402 migration 336 moving from one group to another, note 431 overview 323 planning policies and conditions 334
planning, determining what to monitor 334 policy condition, about 328 production environment, migrating to 443 program types, list of 329 repository setting, viewing 402 required components 401 requirements, compared with a run-time event 145 Siebel Operation step, using different object layers, described 83 structure, about rule structure (diagram) 327 testing 336, 440 tracing 443 using specialized comparisons 371 using standard comparisons 370 verifying installation of 401 views, administered by and example 401 workflow policy action, parts of (diagram) 328 workflow policy group, about 330 Workflow Policies Actions view applet, field descriptions 341 Message Broadcast Arguments applet 384 Workflow Policies Groups view Policies applet, described 340 Workflow Groups applet 340 Workflow Policies Report, about 438 Workflow Policies view working with 346 workflow policy definition of 500 Workflow Policy Action Agent 332 creating 342 definition 328, 329 working with 341 Workflow Policy Columns definition of 500 properties, values of 470 Workflow Policy Component Column adding 362 adding to Workflow policy objects 364 associating workflow policy component column with 366 definition of 500 functions of 325 Workflow Policy Components associating with Workflow policy column 366 defining 364 definition of 500 described 324 function of 472 OBLE, function of 474
510
Index W
Workflow Policy Condition, description of 328 Workflow Policy Duration, description of 327 Workflow Policy Groups creating 340 definition 332 definition of 501 description 332 planning 332, 333, 340 Workflow Policy Log 441 Workflow Policy Monitor Agent 332 Workflow Policy Object adding new 363 adding workflow policy component columns to 364 defined using Object Explorer 363 definition of 501 modifying 378 Workflow Policy Program Arguments about 476 creating or modifying 368 properties, table of 477 Workflow Policy Programs creating or modifying 366 described 329 predefined, table of 381 property descriptions 475 workflow process administering 227 business services, enabling 71 defining a new workflow process 120 defining parameters 117 defining process properties 124 defining step details 126 defining steps 117 definition of 499 deleting 121 deploying as a Web service 215 deploying, about 211 deploying, on a regional node 214 deploying, to a mobile client 213 migration from development to production 218 process properties 47 process properties and property sets 48 publishing and activating 211 running in batch mode 172 running in the application object manager 152 running in the Workflow Process Manager server component 150 running on Object Manager 152 starting, about 143
starting, as a configured business service 147 starting, from a run-time event 144 starting, from a script 152 starting, from a script, examples 152 starting, from a Workflow policy 143 workflow process instance, definition of 499 Workflow Process Manager about running a workflow process in batch mode 172 server component, running a workflow process 150 workflow process parameters about defining 117 workflow process steps about defining 117 workflow process, designing definitions, working with 117 workflow process, general information and planning considerations for planning 83 described 22 diagramming steps 122 gathering information for 99 modifying existing definitions 118 naming conventions 44, 120 overview 22 overview of developing 27 planning tips 83 process steps, about diagramming 122, 124, 126 requirements 109 reviewing existing definitions 117 Siebel Tools and 39 types, 7.0 Flow 129 types, about 127 types, Interactive Flow 128 types, Long Running Flow 129 types, Service Flow 128 workflow process, monitoring about 233 correcting a process and resuming 251 deleting a workflow process instance 231 levels 233 stopping 229 tracing and logging events, table of 236 workflow process, testing and troubleshooting purging workflow process instances from the log 231 recovery 250 stopping an instance 229 testing 197, 198
51 1
Index W
testing caution 204 testing workflows involving server components 198 testing, running the Process Simulator 204 testing, Validate Tool 197 troubleshooting Siebel Flight Data Recorder files 239 troubleshooting, increasing tracing levels 236 troubleshooting, Siebel Application Response Management 238 troubleshooting, tracing and event log levels 236
Workflow Programs Assign to Campaign 394 configuring predefined 388 Create Email Activity 394 definition of 501 Send Campaign Email, using 393 workflow recovery manager, definition of 246 workflow step, definition of 499 Workflow User Event business service generating user events 161 Workflow Utilities, arguments 487
512

BPFWorkflow

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BPFWorkflow

Uploaded by

Copyright:

Available Formats

Siebel Business Process Framework: Workflow Guide

Version 8.1, Rev A July 2009

Siebel Business Process Framework: Workflow Guide 1

Whats New in This Release Overview of Siebel Workflow

About Siebel Workflow

Overview of How a Workflow Process Is Developed

Architecture of a Workflow Process

About the Architecture of a Workflow Process

How a Workflow Process Interacts with Other Siebel Components

Environment for Developing a Workflow Process

About the Object Hierarchy of a Workflow Process

About the Process Designer About the Process Property

About the WF/Task Editor Toolbar

Siebel Business Process Framework: Workflow Guide Version 8.1, Rev A

Steps and Connectors of a Workflow Process

Overview of Workflow Process Steps

Types of Steps of a Workflow Process

Defining a Decision Condition

Defining a Branch Connector 92 Defining a Decision Condition on a Branch Connector

Developing a Workflow Process

Roadmap for Developing a Workflow Process Process of Analyzing Business Requirements

Process of Planning a Workflow Process

Job Roles That Are Involved in Developing a Workflow Process

Siebel Business Process Framework: Workflow Guide Version 8.1, Rev A

Process of Building a Workflow Process

Diagramming a Workflow Process

Defining a Process Property for a Workflow Process

Defining a Property for the Step of a Workflow Process

Options for Developing a Workflow Process

About the Workflow Mode Property

Starting a Workflow Process

Run-Time Event 157 About the User Event 161

Siebel Business Process Framework: Workflow Guide Version 8.1, Rev A

Using Batch Processing

Defining a Workflow Process for a Multilingual Environment

Decision Conditions for a Workflow Process

Chapter 10: Testing a Workflow Process

Process of Testing a Workflow

Troubleshooting Validation and Simulation Problems

Siebel Business Process Framework: Workflow Guide Version 8.1, Rev A

Chapter 11: Administering a Workflow Process

Process of Migrating a Workflow Process

Process of Administering a Workflow Process

Monitoring a Workflow Process

Diagnosing a Workflow Process That Has Failed

About Upgrading a Workflow Process

Chapter 12: Examples of Defining a Workflow Process

Chapter 13: Examples of Using a Business Service with a Workflow Process

Examples of Using the Outbound Communications Manager Business Service

Example of Externalizing Properties when Using a Business Service

Chapter 14: Defining a Custom Workflow Policy

Process of Planning a Workflow Policy

Process of Defining a Workflow Policy

Examples of Defining Workflow Policy Configurations

Siebel Business Process Framework: Workflow Guide Version 8.1, Rev A

Customizing Workflow Policy Objects

Conditions for a Workflow Policy

Chapter 15: Using a Predefined Workflow Policy

Types of Workflow Policy Programs That Are Predefined

381 388 393

Examples of Workflow Policy Programs That Are Predefined

Workflow Policy Programs that Are Predefined for Siebel Marketing

Example of Developing a Workflow Policy That Manages a Marketing Campaign