11Options for Configuring a Workflow Process

Options for Configuring a Workflow Process

This chapter describes options for configuring a workflow process. It includes the following topics:

• Setting the Workflow Mode Property

• Starting a Workflow Process

• Handling Errors

• Configuring Events

• Configuring Batch Processing

• Configuring a Workflow Process for a Multilingual Environment

Setting the Workflow Mode Property

This topic includes the following topics:

• Types of Workflow Process Modes

• Options for the Workflow Mode Property

• Options for an Interactive Workflow Process

• Options for a Long-Running Workflow Process

• Enabling Workflow Persistence

Types of Workflow Process Modes

This topic includes the following topics:

• About the Service Workflow Process

• About the Interactive Workflow Process

• About the Long-Running Workflow Process

• About the 7.0 Workflow Process

To determine the run-time behavior of a workflow process, you can set the Workflow Mode property of a workflow process to use one of the following values:

• Service Flow. A workflow process that runs a set of operations.

• Interactive Flow. A workflow process that helps the user to navigate Siebel views.

• Long-Running Flow. A workflow process that can last for hours, days, or months.

• 7.0 Flow. A workflow process that is compatible with Siebel CRM version 7.7 or earlier.

About the Service Workflow Process

A service workflow process is a type of workflow process that runs a set of operations to complete a work unit from beginning to end. A service workflow process is a transient workflow process, which is a type of workflow process that runs to completion in a short amount of time without stopping or pausing for an event or activity. A service workflow includes no special behavior. Siebel CRM can call it as a subprocess from another service workflow, an interactive workflow, or a long-running workflow, but not from a 7.0 workflow. A service workflow process includes the following limitations:

• Cannot wait for a run-time event or pause for time.

• Cannot include 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 Defining a Workflow Process That Creates an Activity for a Sales Representative.

About the Interactive Workflow Process

An interactive workflow process is a type of workflow process that assists and controls navigation for a user across Siebel views and screens. It includes one or more user interact steps and it typically includes a run-time event.

For an example, see Defining a Workflow Process That Creates a Service Request and Navigates the User.

For more information, see Options for an Interactive Workflow Process.

Interactive Workflow Process in a UI Context

An interactive workflow process can run only in a user session context. It cannot run in the Workflow Process Manager server component. It cannot run in a server component that does not include a user session context, such as the Business Integration Manager server component. To run in a user session context means the workflow process must run in an Application Object Manager that contains a user session context, such as one of the following Siebel CRM applications:

• Siebel Call Center

• Siebel Service

• Siebel eSales

• Siebel Service Portal

These applications support view navigation, view display, and so on, which is necessary when using an interactive workflow because they display views through the user interact step and they require interaction with a user who clicks buttons and links.

About the Long-Running Workflow Process

A long-running workflow process is a type of workflow process that is persistent. It can last for hours, days, or months. The Send Order to External workflow process is an example of a long-running workflow process. It sends an order to a system that is external to Siebel CRM, and then waits for a reply. You can use a long running workflow process to define a single workflow process that handles an entire business process transaction that coordinates between multiple subprocesses. The Quote to Cash business process is an example where a long-running workflow is useful.

To create a collaborative long-running workflow process, you can assign a subprocess to a user. The Workflow User Event Service business service creates 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.

You cannot use a user interact step in a long-running workflow process, but you can add an interactive workflow process as a sub process step in a long-running workflow process. You cannot use the Process Simulator to simulate a long-running workflow.

If you create a long-running workflow process, then you must use a user event and not a run-time event to start or resume the workflow process.

For more information, see Options for a Long-Running Workflow Process and Defining a Sub Process that Assigns a Long-Running Workflow Process.

About the 7.0 Workflow Process

A 7.0 workflow process is a type of workflow process that provides backward compatibility for an existing workflow process that was defined in a Siebel release earlier than Siebel CRM version 7.7. If a workflow process was defined earlier than version 7.7, and if you upgrade to version 7.7, then the existing workflow process becomes a 7.0 Flow workflow process, by default.

If you must upgrade a workflow process that was defined earlier than Siebel CRM version 7.7 to version 8.0, then you must first define the workflow process as a 7.0 workflow process. You must upgrade a pre 7.7 workflow process to version 7.7 before you can upgrade it to version 8.0.

7.0 Flow Usage

If you create a new workflow process, then it is strongly recommended that you do not use the 7.0 Flow workflow mode. If you do not define a workflow mode for a workflow process in a release that occurs prior to Siebel CRM version 8.1, then Siebel CRM assumes the mode is 7.0 Flow. If you create a new workflow process, then make sure you do not set the Workflow Mode property to 7.0 Flow so that Siebel CRM does not assume the mode is 7.0 Flow. Starting with Siebel version 8.1, if you create a new workflow process, then Siebel Tools sets the Workflow Mode property to Service Flow, by default.

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

If a workflow process includes a user interact step, then you must set the mode property of this workflow process to Interactive Flow. This workflow process can contain a wait step that waits for an event. In some situations, a wait is not required. For example, you can use a wait step that only assigns a value to a process property.

A workflow process that includes a wait step is a long-running workflow process only if the wait step waits for an amount of time. The Workflow Process Manager must resume the workflow process after the wait finishes. If a wait step waits for a run-time event in a user session, then the workflow process is not a long-running workflow process. This type of workflow process can include a user interact step, which makes it an interactive workflow.

Workflow Mode Usage with the Sub Process Step

A workflow process can call multiple sub processes, but the workflow mode of the calling workflow process must be consistent with the workflow mode for the sub process.

The table below describes the workflow modes that Siebel CRM allows between the calling workflow process and the sub process.

Table Workflow Modes That Siebel CRM Allows Between the Calling Workflow Process and the Sub Process

Mode of the Calling Workflow Process	Mode of the Sub Process
Service Flow	Service Flow
Interactive Flow	You can use any of the following modes: Service Flow Interactive Flow
Long Running Flow	You can use any of the following modes: 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

• Pausing and Resuming an Interactive Workflow Process

For examples of an interactive workflow processes, see the following topics:

• Defining a Workflow Process That Attaches an Activity Plan to an Opportunity.

• Defining a Workflow Process That Creates a Service Request and Navigates the User.

About the Synthetic Event

A synthetic event is a run-time event that controls navigation for a workflow process. Examples of synthetic events include Suspend, Resume, Next, and Back. To control navigation, the Workflow Engine interprets these synthetic events to navigate the user backward or forward through a workflow process, or to pause or resume a workflow process. For example, assume the Siebel client includes an Account Note view that includes an Account Entry Applet, and that this applet includes Back, Next, and Save synthetic events. These buttons allow the user to move forward or backward from the Account Note view, or to pause an interactive workflow process, and then return to it later to resume the workflow process.

You can define buttons, and then associate methods in the interactive workflow process to these buttons. For example, to configure the Next synthetic event, you associate a method with an outgoing connector on a user interact step. You set the method name of the synthetic event in the MethodInvoked property of the button control.

Comparison of a Synthetic Event to a User Event

A synthetic event differs from a user event:

• A user event is internal to Siebel Workflow. Siebel CRM uses it only to resume a workflow process from the Workflow Process Manager server component. It uses a user event only in a long-running workflow process.

• A synthetic event is a run-time event that Siebel CRM uses to resume a workflow process from the Application Object Manager where it creates the synthetic events. Siebel CRM can use a synthetic event only with an interactive workflow process or with a 7.0 workflow process.

Forward and Backward Navigation Between Views

To define navigation in an interactive workflow process, you can use a synthetic event. If the user clicks Next or Back, then Siebel CRM navigates the user to the next or to the previous view without losing the context of the workflow process instance.

Siebel CRM uses a synthetic event to allow the user to navigate backward through views. It uses a run-time event to allow forward navigation but not backward navigation.

To navigate back and forth, the following requirements must be met:

• The resumed workflow process must be an interactive workflow process or a 7.0 workflow process.

• The calling event must be a navigation event of a workflow process. For example, the calling event must include a name such as InvokeMethod, and a sub event with a name such as FrameEventMethodWFBFevent_name or EventMethodWFBFevent_name, where event_name is the name of the event, such as Next.

The following table describes backward and forward navigation that is available for workflow process modes.

Table Backward and Forward Navigation with Workflow Modes

Workflow Mode Supported	Workflow Mode Not Supported
Siebel CRM supports the following modes with backward and forward navigation: Interactive Flow 7.0 Flow	Siebel CRM does not support the following modes with backward and forward navigation: Service Flow Long Running Flow

Guidelines for Configuring Backward Navigation

If you configure Siebel CRM to use backward navigation, then it is recommended that you use the following guidelines:

• Make sure that any workflow process steps that Siebel CRM repeats as a result of using backward navigation do not result in Siebel CRM performing duplicative actions on data.

• Note that backward navigation does not undo changes that the workflow process makes. It only modifies the current step counter to reference a previous step.

Synthetic Event Methods

The following table describes synthetic event methods.

Table Synthetic Event Methods

Synthetic Event Method	Description
FrameEventMethodWFNext	Uses an applet to move the user forward in an interactive workflow process. To use a synthetic event that resumes a workflow process from a step that is different from the current step on which the workflow process is waiting, you can use a prefix of BF in the method name. For example, FrameEventMethodWFBFevent_name. Use this optional BF prefix to define backward and forward behavior for the synthetic event.
EventMethodWFNext	Operates the same as FrameEventMethodWFNext except navigation occurs through the business component.
FrameEventMethodWFBack EventMethodWFBack	Moves the user backward in the interactive workflow process.
SaveWorkflow	Pauses and saves the interactive workflow process and makes it appear in the user Inbox.
ResumeLastIntFlow	Resumes the interactive workflow process that Siebel CRM most recently ran. ResumeLastIntFlow is not specific to a particular workflow process. Siebel CRM can call it from elsewhere in a Siebel CRM application. The button that corresponds to this event can reside in an applet. It is recommended that you place this button in the task bar where Siebel CRM locates the Site Map icon.

Configuring a Synthetic Event Button for Next and Back Events

This topic describes how to configure a synthetic event button for next and back events.

To configure a synthetic event button for next and back events

1. In Siebel Tools, identify a view to which a user interact step must navigate the user.

2. Define a Next button or a Back button on an applet where the event is called.

   Siebel CRM must display the button in an applet that references the primary business component. For example, if the workflow process references the Service Request business object, and if the view displays activities that are associated with a service request, then Siebel CRM must display the button in the applet that references the Service Request business component. In this example, if Siebel CRM displays the button in an applet that references the Activities business component, then the synthetic event button does not work. For more information, see Defining the Primary Business Component and Using Siebel Tools.

3. Define the MethodInvoked property of the button control as the name of the associated event.

   For example, FrameEventMethodWFBack for backward navigation.

4. 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	Value
   Event Type	Applet
   Event Obj	AppletName
   Event	InvokeMethod
   Sub Event	[Method Name] For example, FrameEventMethodWFBack.

Tip: It is not necessary for you to manually define buttons for each applet. You can use the Applet Comparison feature in Siebel Tools to copy a button to other applets. If you add the applet button controls to the HTML Model Controls applet, then you can choose the method buttons that are related to a workflow process when you use the New Applet Wizard to create a new applet.

Configuring a Synthetic Event Button for the Save Workflow Event

This topic describes how to configure a synthetic event button for the save workflow event.

To configure a synthetic event button for the save workflow event

1. In Siebel Tools, identify a view to which a user interact step must navigate the user.

2. Define a Save button on an applet where Siebel CRM calls the event.

   For more information, see Using Siebel Tools.

3. Set the MethodInvoked property of the button control to reference the SaveWorkflow event.

4. Use the following script to call the event handler that Siebel Workflow uses to handle the button click event. The script also sends the contextual information for the event to the Siebel Workflow event handler, 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)
   { 
   // 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);
        
   var workflowSvc = TheApplication().GetService("Workflow Process Manager");
   workflowSvc.InvokeMethod("_HandleSpecialEvent", Inputs, Outputs);
   return (CancelOperation);
   }
   return (ContinueOperation);
   }
   

Configuring a Synthetic Event Button for the Resume Last Flow Event

This topic describes how to configure a synthetic event button for the resume last flow event.

To configure a synthetic event button for the resume last flow event

1. In Siebel Tools, identify a view where the user interact step must navigate the user.

2. Define a Resume button on the applet where Siebel CRM must call the event.

   For more information, see Using Siebel Tools.

3. Set the MethodInvoked property of the button control to reference the ResumeLastIntFlow event.

4. Use the following script to call the event that Siebel Workflow uses to handle the button click. This script passes the contextual information for the event to the Siebel Workflow event handler. This handler is the name of the view where the event occurs. It is not necessary for you to define this event in the workflow process:

   function WebApplet_InvokeMethod (MethodName)
   {
   return (ContinueOperation);
   }
        
   function WebApplet_PreCanInvokeMethod (MethodName, &CanInvoke)
   { 
        
   if (MethodName == "ResumeLastIntFlow") 
   {
   CanInvoke = "TRUE"; 
   return (CancelOperation); 
   }
   return (ContinueOperation);
   }
        
   function WebApplet_PreInvokeMethod (MethodName)
   {
   // Call Workflow Process Manager to resume the last-run 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);
   

Pausing and Resuming an Interactive Workflow Process

Siebel CRM can resume an interactive workflow process that the user pauses. The user can navigate out of this workflow process, and then navigate back to it and continue where the user paused it.

For example, assume the user is an insurance agent, and this user pauses an interactive workflow process because the user cannot finish a transaction. Some required information is missing, such as the social security number for a spouse. When the user eventually gets the social security number, the user can resume the workflow process from the Inbox, and then enter the social security number. The Workflow Engine removes the workflow process from the Inbox after it finishes.

If the user pauses an interactive workflow process, then Siebel CRM places this workflow process in the user Inbox. It does this to allow the workflow process owner to track and resume the workflow process.

The following table describes work that Siebel CRM performs if the user pauses a workflow process. If an interactive workflow process that is paused finishes, and then terminates, then Siebel CRM removes it from the user Inbox. To realize this behavior, the Auto Persist property for the paused workflow process must contain a check mark.

Table Work That Siebel CRM Performs if the User Pauses a Workflow Process

Pause	Description	Result
Explicit pause.	The user clicks Suspend.	Siebel CRM saves the workflow process to the Siebel database and places it in the user Inbox.
Implicit pause	The user leaves a view that is part of the workflow process.	If the cache is full, or if the user logs out of the Siebel CRM application, then Siebel CRM must remove the workflow process from the cache. Siebel CRM saves the workflow process to the Siebel database and places it in the user Inbox.

Persisting a Workflow Process

If Siebel CRM pauses a workflow process, and if the Auto Persist property for this workflow process is set to TRUE, then the workflow can be persistent. If Siebel CRM does an implicit pause, and if the user leaves a view that the workflow process displays, then Siebel CRM saves the workflow process instance to the cache but it does not create an Inbox item. If the user logs out, and if the Auto Persist property is TRUE, then Siebel CRM creates an Inbox item in the cache. Siebel CRM displays the Inbox item only if the user logs out, and then logs back in to the Siebel application.

How Siebel CRM Uses the Cache of an Interactive Workflow Process That Is Paused

If a user navigates out of an interactive workflow process, then it remains in memory so that Siebel CRM can resume it later in the same user session. The cache can contain no more than eight instances of an interactive workflow process that is paused. This limit applies to an individual user session. The limit is eight instances for interactive workflow processes that Siebel CRM starts in the user session, not eight instances for each interactive workflow process. You cannot modify this eight instance limit.

The user session is one connection on the Application Object Manager server component, regardless if Siebel CRM logs this thread as a single user. If Siebel CRM reaches the eight instance limit, then it does not prevent a new interactive workflow process from running. If the user starts an interactive workflow process, and if Siebel CRM already cached eight instances in memory, and if the AutoPersist property for the workflow process is set to TRUE, then Siebel CRM replaces the oldest instance with this ninth instance. Siebel CRM replaces the oldest instance only if the cache reaches the cache limit.

Event Handling with an Interactive Workflow Process That Is Paused

Siebel Workflow handles events in the following sequence:

1. To examine the cache, it uses the matching criteria that the event defines. It does this to determine if workflow process instances exist in the cache that can receive an event.

2. Examines the Siebel database to determine if persistent instances of the workflow process exist that can receive an event.

3. Resumes instances it finds in the steps above.

How Siebel CRM Handles an Interactive Workflow Process That it Cached

If the user logs out, then Siebel CRM examines the interactive workflow processes that it paused in the cache. It creates an Inbox item for each workflow process that contains a check mark in the Auto Persist property. It deletes any other workflow processes.

Options for a Long-Running Workflow Process

This topic includes the following topics:

• Defining a Sub Process that Assigns a Long-Running Workflow Process

• Defining a Long-Running Workflow Process That Assigns a Task UI to a User

Defining a Sub Process that Assigns a Long-Running Workflow Process

You can define a workflow process that assigns an interactive subprocess to the user of a collaborative workflow process. An example of a collaborative workflow process is a workflow process that includes a requirement for approvals. It includes a logical path that runs across multiple users who work in collaboration to finish the work that the workflow process requires.

To define a collaborative workflow process, you use the Recipients properties on a subprocess step. The login name determines assignment. The Position or User Id does not determine assignment. This login name can be one of the following items:

• A literal value

• Reside in a process property

• Reside in a business component field

• The result of an expression

The Process Designer does not validate this login name.

To define a sub process that assigns a long-running workflow process

1. Define a sub process step.

   For more information, see Adding a Sub Process Step.

2. In the Recipients tab of the MVPW, set the Recipient Name field to the login name of the user who Siebel CRM assigned to the sub process.

   For more information, see Using Process Properties, and Recipient Argument Fields of a Process Property.

Defining a Long-Running Workflow Process That Assigns a Task UI to a User

You can use a long-running workflow process that assigns a task UI to a user, and then creates an item for the task UI in the user Inbox. To create a new instance of this task UI and run it, the user can click the inbox item. For example, the following work occurs in the Expense Report Approval long-running workflow process:

• An employee sends an expense report.

• Siebel CRM creates a new task UI named Review Expense Report.

• Siebel CRM assigns the Review Expense Report task UI to the employee’s manager.

This situation requires a one-to-one assignment. To make this assignment, Siebel CRM can look up the Id for the manager from the business component that stores data about the user. Siebel CRM gets the manager Id, and then creates a new item in the manager Inbox. This item references the Review Expense Report task UI.

To define a long-running workflow process that assigns a task UI to a user

1. Use the Process Designer to open the long-running workflow process.

2. At the point where Siebel CRM must call the task UI, determine the Id of the user to whom it must assign the new task UI instance.

   Siebel CRM can use a business service that accesses Siebel Assignment Manager to apply an assignment rule. The input to this business service varies depending on the context that the assignment requires. The output from this business service is the Id of the user to whom Siebel CRM assigns the task UI.

   This logic depends on your business requirements. If the Id:

   • Already exists in a business component, then you can use a Siebel operation.

   • Does not exist, then you can use a business service to get it.

3. In the Owner Id input argument, identify the task step that creates a new item in the user Inbox.

4. Add a task step to the workflow process.

   If you add a task step to a workflow process, then it creates a new instance of the task UI and assigns it to the user. For more information, see Adding a Task Step.

Enabling Workflow Persistence

Workflow persistence is a feature that allows Siebel CRM to store the state and values that reside in the process properties of a workflow process instance. It supports transactions that are long lived in a single workflow process. Workflow persistence allows you to create an end-to-end workflow process that can include a wait step, a sub process step, or other interruptions. It can maintain the active state of the workflow process over a long time period while work occurs in different parts of your enterprise. It can save or restore data when the workflow process resumes. If persistence is enabled on a workflow process, then a user can pause it, and then Siebel CRM adds an item for it in the user Inbox. The user can take a work break, and then resume the workflow process at a later time.

Workflow persistence can resume a workflow process if any of the following occurs:

• Pause

• Server failure

• Session time out

• The user logs out of a web session

Siebel CRM saves the workflow process state and process properties in the S_WFA_INSTANCE table and the S_WFA_INST_PROP table. It removes a persistent workflow process from memory after it finishes running.

How Workflow Persistence Works with Different Workflow Process Modes

Siebel CRM uses workflow persistence with the following types of workflow processes:

• Interactive workflow process or 7.0 flow workflow process. You set the Auto Persist property of the workflow process in the Workflow Processes list in Siebel Tools.

• Long-running workflow process. The Siebel Server sets persistence for a long-running workflow process at run time.

• Service workflow process. Siebel CRM cannot use workflow persistence with a service workflow process.

Process Monitoring with Workflow Persistence

Some releases that occur earlier than Siebel CRM version 8.0 use workflow persistence to monitor a workflow process. To control workflow persistence, Siebel CRM adjusted the frequency and level settings on individual workflow process steps. Starting with Siebel CRM version 8.0, process monitoring is separate from workflow persistence and it is not necessary to set persistence for a long-running workflow process. If workflow persistence is enabled for a 7.0 flow workflow process, then Siebel CRM enables workflow persistence for it during an upgrade or import.

Enabling Persistence for a Workflow Process

You can enable workflow persistence for an interactive workflow process or for a 7.0 flow workflow process. The Siebel Server sets persistence for a long-running workflow process at run time.

Caution: Defining Workflow Persistence for a large number of workflow processes can result in Siebel CRM creating a large number of records in the S_WF_PROP_VAL table. For more information, see Avoiding Excessive Records in the S_WF_PROP_VALTable.

To define persistence for a workflow process

1. Locate the workflow process you must modify.

   For more information, see Locating a Workflow Process in the Workflow Processes List.

2. Set the Auto Persist property to YES.

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

• Starting a Workflow Process from a Run-Time Event

• Starting a Workflow Process from a Business Service

• Starting a Workflow Process from Another Workflow Process

• Starting a Workflow Process from the Workflow Process Manager

• Starting a Workflow Process from the Application Object Manager

• Starting a Workflow Process from a Script

• Starting a Workflow Process from a Custom Toolbar

• Other Configurations That Start a Workflow Process

For more information, see Determining How to Start a Workflow Process.

For information about starting a workflow process from a server component, see Overview: Siebel Enterprise Application Integration and Siebel Email Administration Guide.

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. To define a custom workflow policy program, you can also copy Run Workflow Process, and then add program arguments that correspond to workflow process properties. This configuration allows you to use the policy program to pass data to the process properties. For more information, see Defining Custom Workflow Policies.

To start a workflow process from a workflow policy

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

2. In the Actions list, click New.

3. In the Program field, choose the Run Workflow Process program.

4. In the Arguments list, click New.

5. In the Argument field, choose ProcessName.

6. In the Value property, enter the name of the workflow process you must start.

7. Navigate to the Administration-Business Process screen, and then the Policy Groups view.

8. In the Policy Groups list, click New to create a new group, and then name it.

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

10. In the list for the Policies List, click New.

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.

12. In the Actions list, click New to create a new action, and 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 Creating Database Triggers.

14. If you use 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 Running a Workflow Policy with Workflow Monitor Agent.

16. Meet the conditions of the policy.

    Meeting these conditions 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 Configuring Run-Time Events.

How a Run-Time Event Starts a Workflow Process

This topic describes the process that Siebel CRM uses to start a workflow process from a run-time event. For this example, assume the PreWriteRecord event starts the workflow process:

1. Components in the Application Object Manager detect the PreWriteRecord run-time event.

2. The PreWriteRecord run-time event is defined on the connector that emanates out of the start step and the workflow process starts.

3. The Object Manager calls the Workflow Engine. Siebel CRM passes the business object that caused the run-time event to the Workflow Engine.

4. The Workflow Engine uses the active rows on the business object for data operations.

5. If the rows are not already active, then the Workflow Engine sets up the rows, which is necessary for an Object Manager that creates run-time events.

6. Siebel Workflow runs with the local thread. If SWE is present, then Siebel CRM allows user interacts. It uses the following parameters:

7. Context, which is a comma-separated string that Siebel Workflow registers internally

8. The business component that causes the run-time event

Choosing Between a Run-Time Event and a Workflow Policy

If Siebel CRM must detect a database event, then you must use a workflow policy and not use a run-time event. For example, if your configuration uses:

• The Siebel client, then you can configure Siebel CRM to use a run-time event to start a workflow process.

• The Siebel EAI Adapter or the EAI UI Data Adapter, then use a workflow policy. These adapters perform numerous WriteRecord events.

For more information, see Starting a Workflow Process from a Workflow Policy.

Comparison of Using a Run-Time Event to a Using a Workflow Policy

The following table describes two different requirements for using a run-time event compared to a workflow policy.

Table Examples of Requirements for Using a Run-Time Event Compared to a Workflow Policy

Requirement	Recommended Configuration
If the user creates a new service request, then set the priority to ASAP and send a notification email.	Use a workflow policy. It is the appropriate way to detect a Siebel database event.
If the user views an entry in an applet, then create a text file that contains some information.	Use a run-time event. Define a workflow process that includes the InvokeMethod run-time event defined on the start step. This event detects if the user views the Entry Applet. Use a business service step to create the text file.

Defining a Button That Starts a Workflow Process

You can use Siebel Tools to define a button on an applet that starts a workflow process.

To define a button that starts a workflow process

1. Open Siebel Tools, and then define a minibutton on an applet:

   1. Set the Method Invoked property to a meaningful value, such as SendEmail.

   2. Define an applet user property that calls the method. Use values from the following table.

      Property	Value
      Name	Named Method n
      Value	'INVOKESVC', 'Workflow Process Manager', 'RunProcess', '"ProcessName"','"eAuction XML Bulk Upload 1"', '"RowId"', '[Id]'

   For example, the following code calls the eAuction XML Bulk Upload 1 workflow process and sends a pointer to the current record:

   'INVOKESVC', 'Workflow Process Manager', 'RunProcess', '"ProcessName"', 
   '"eAuction XML Bulk Upload 1"', '"RowId"', '[Id]'
   

   For more information, see the topic about the Named Method n applet user property in Siebel Developer's Reference.

2. Define a workflow process.

3. Optional. Use a runtime event to start this workflow process:

   1. Define a run-time event on the connector that emanates from the start step of the workflow process. Use values from the following table.

      Property	Value
      Event Object Type	Applet
      Event Object	Choose the applet where the button is defined.
      Subevent	Enter the same value that appears in the MethodInvoked property of the minibutton.
      Event Cancel Flag	TRUE

      If you use this configuration to call a workflow process, then it is not necessary to add the Named Method n applet user property.

   2. If you write a script for PreInvokeMethod to run on the applet or the business component, then do the following:

      • Set the event cancel flag to FALSE.

      • Write a script in the WebApplet_PreInvokeMethod event of the applet that returns CancelOperation.

      • Use the BusComp_PreInvokeMethod event of the business component that the applet references to return the CancelOperation.

4. Optional. To resume this workflow process if the user pauses it, you can define the run-time event on the connector that emanates from a user interact step or from a wait step. This event is a synthetic event. For more information, see About the Synthetic Event.

5. Define the run-time event using values from the following table.

   Property	Value
   Event	PreInvokeMethod
   Event Cancel Flag	True. If this flag is not checked, then an error results when the workflow process runs.
   Event Object	Name of the business component that the applet references. This applet contains the button.
   Event Object Type	BusComp
   Sub Event	Name of the method you set. The Sub Event name must be unique.
   Type	(Required) Condition

6. Activate the workflow process.

   For more information, see Publishing a Workflow Process.

7. In the Siebel client, navigate to the Administration-Runtime Events screen, and then the Events view.

8. Click Menu on the Events applet, and then choose Reload Runtime Events.

   You must reload personalization after you activate a workflow process that registers a run-time event.

Avoiding the Cannot Resume Workflow Process Error

If the user clicks a button that starts a workflow process, and if all of the following situations exist, then an error occurs:

• The workflow process is an interactive flow.

• The workflow process starts at least one time in the current user session.

• An event occurs but there is no workflow process instance available to handle this event.

Siebel CRM discards the event and displays an error message in the client.

To avoid the cannot resume workflow process error

• Require the user to run a workflow process to access this view.

For example, you can define a workflow process that includes the user interact step. To handle the error, you can create an error exception connector or error process.

Identifying a Predefined Workflow Process Thata Run-Time Event Starts

You can use the Siebel client to identify a predefined workflow process that a run-time event starts.

To identify a predefined workflow process that a run-time event starts

1. In the Siebel client, navigate to the Administration-Runtime Events screen, and then the Events view.

2. Note the value of the row ID in the Action Set Name field.

   For example, if Siebel CRM displays Workflow_1-2APXH in the Action Set Name field, then 1-2APXH is the Row Id of the workflow process.

3. Navigate to the Administration-Business Process screen, and then the Workflow Processes view.

4. 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

In this topic, you configure Siebel CRM to start a workflow process from a business service.

To start a workflow process from a business service

1. In Siebel Tools, in the Object Explorer, click Business Service.

2. In the Business Services list, add a new business service using values from the following table.

   Property	Value
   Name	Enter a name that you can reference in scripting.
   Class	CSSSrmService
   Display Name	Enter a name that Siebel CRM displays in workflow views.

3. In the Object Explorer, expand the Business Service tree, and then click Business Service User Prop.

4. In the Business Service User Props list, add two new objects using values from the following table.

   Property	Value
   Component	Enter the short name of the server component. For example, WfProcMgr.
   Mode	Enter the mode of the Siebel Server request. For example, Async.

5. Optional. Enter more user properties for the Server Request Broker.

   For more information, see Server Request Broker Server Component.

6. In the Object Explorer, click Business Service Method.

7. In the Business Service Methods list, add a new object using values from the following table.

   Property	Value
   Name	Enter a name that you can reference in scripting.
   Display Name	Enter a name that Siebel CRM displays see in workflow views.

8. In the Object Explorer, expand the Business Service Method tree, and then click Business Service Method Arg.

9. In the Business Service Method Arguments list, add records that are specific to the component that Siebel CRM calls.

   For example, ProcessName for WfProcMgr. This name is the short name of the Siebel Server component parameter.

Guidelines for Starting a Workflow Process from a Business Service

If you configure Siebel CRM to start a workflow process from a business service, then it is recommended that you use the following guidelines:

• If Siebel CRM uses a business service to start a workflow process, then it is not necessary for you to define parameters for the Server Request Broker (SRBroker). For example, if Siebel CRM uses the Workflow Process Manager (Server Request) business service.

• If Siebel CRM calls the Siebel Server requests directly, then you must define parameters for the Server Request Broker.

• Server Request Broker and Server Request Processor (SRProc) are required to run a business service that calls a server component.

• To use Workflow Process Manager (Server Request), the 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.

Starting a Workflow Process from Another Workflow Process

You can define a workflow process so that it asynchronously starts another workflow process. You configure Siebel CRM to start a workflow process that calls a custom business service. This business service uses the Asynchronous Server Requests business service to start another workflow process.

To start a workflow process from another workflow process

1. In Siebel Tools, in the Process Designer, add a business service step to your workflow process.

2. Make sure the new business service step is chosen.

3. Use the properties window to set values described in the following table.

   Property	Value
   Business Service	Asynchronous Server Requests
   Method	SubmitRequest

4. In the MVPW, click the Input Arguments tab, and then add three new input arguments using values from the following table.

   Input Argument	Type	Value	Property Name
   Component	Literal	WfProcMgr	Leave this field empty.
   WfProcMgr.ProcessName	Literal	AG Simple Test	Leave this field empty.
   WfProcMgr.RowId	Process Property	(Leave this field empty.)	Siebel Operation Object Id

   For more information, see Arguments That You Can Define for a Process Property.

5. To set server component parameters, such as Workflow Process Name, define the Input Argument Name using the following format:

   [ComponentAlias].[argument_name_for_the_business_service_method]
   

   If you run the workflow process in the Process Simulator, then Siebel Tools inserts a request in the S_SRM_REQUEST table and starts a Workflow Process Manager task on the Siebel Server.

Starting a Workflow Process from the Workflow Process Manager

A workflow process can run in the Workflow Process Manager server component. It can start on the Siebel Server in the following ways:

• From a workflow policy that runs on the Siebel Server. For more information, see Starting a Workflow Process from a Workflow Policy.

• From a script that specifies the Server Request parameter. For more information, see Starting a Workflow Process from a Script.

• 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.

The siebel.cfg file is the default configuration file for Workflow Process Manager server components.

Siebel CRM runs a workflow process that starts from a script in synchronous mode.

Siebel CRM does not support a workflow process that runs on the Siebel Server and that uses a business service to call a user interface element, including navigation functionality, such as the user interact step.

For more information, see Workflow Process Manager Server Component.

Remote Synchronous Processing

If a user starts a workflow process that runs on the Siebel Server in the Workflow Process Manager server component, then this workflow process runs only if the user is connected to the Siebel Server. If the user is not connected, then Siebel CRM queues the request and runs the workflow process when the user synchronizes or when the Siebel Server is available. For more information, see Server Requests Business Service.

User Key Routing with Workflow Process Manager

A server key map is a map that defines the rule groups that Siebel CRM loads and processes for each server. You can configure a Siebel Server to load multiple rule groups. A server key map divides rules among different servers. To define a server key map, you use the Server Key Map view in the Assignment Administration screen.

You can use key routing to do the following:

• Routing. To control how Siebel CRM routes Workflow Process Manager requests, you can set up the RequestKey parameter on the Workflow Process Manager so that Siebel Workflow registers this key when Siebel Workflow starts.

• Recovery. To target the ping messages, each Workflow Process Manager registers a unique key. The Workflow Recovery Manager uses these keys to keep track of which Workflow Process Manager is alive and what information the Workflow Process Manager is processing.

To send an assignment request, you define the AsgnKey parameter, where the AsgnKey parameter is the Row Id of the assignment rule group that is associated with the rules that Siebel CRM must evaluate. If you use AsgnSrvr, then the AsgnKey parameter must contain the Row Id of one of the rule groups that you define for the Siebel Server in the Server Key Mappings view. The Assignment Server (AsgnSrvr) looks for entries in the Siebel Server key map for a specific server, and then loads rules for only the rule groups that are associated with that server key map. Assignment Manager uses key routing to route the request to a particular Assignment Manager instance where the rules are loaded for that rule group.

To load the same rule group, you can define multiple servers. Assignment Manager routes requests to one of the Siebel Servers where that rule group references load balancing metrics.

The following environments support server key mapping:

• An interactive and dynamic assignment exists

• A script or workflow process calls a business service

If Workflow Recovery Manager is activated, then the Key Based Enabled parameter for Workflow Process Manager must be set to true.

For more information, see Siebel Assignment Manager Administration Guide.

Controlling How Siebel CRM Handles the User Id

If the Workflow Process Manager inserts a record, then, by default, Siebel CRM sets the CREATED_BY field to 0-1, which is the ROW_ID for employee SADMIN. In some situations, 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 if a user performs an action in the Siebel client. The Asynchronous Server Requests business service starts this workflow process and the Workflow Process Manager runs it on the Siebel Server. It sets CREATED_BY to SADMIN but the business requirement is to set CREATED_BY to the user who caused the workflow process to start.

To control how Siebel CRM handles the user Id

• Instead of using Workflow Process Manager on the Siebel Server to start the workflow process, you can configure Siebel CRM to start the workflow process so that it runs locally. If the workflow process runs locally, then the user session creates the record and Siebel CRM sets CREATED_BY to the user Id. This workflow process runs synchronously.

• If the business requirement is to record the user who caused Siebel CRM to insert a record, then you can configure Siebel CRM to pass the Login Id or Login Name of the user to the workflow process on the Siebel Server, and then write it to an extension field in the business component. To get the Login Id or Login Name for the user, you can use the LoginId or LoginName function in a script. For information about how to pass data to a custom process property of a workflow process when Siebel CRM sends a server request, see Server Requests Business Service.

Starting a Workflow Process from the Application Object Manager

Running a workflow process in the Application Object Manager can be useful if Siebel CRM must use a business process with a mobile user or if you must define a business process that includes user navigation.

To start a workflow process from the Application Object Manager

• Start the workflow process in one of the following ways:

  • From the Process Simulator

  • From a script that you define 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 from a Script

You can use Siebel VB or Siebel eScript to start a workflow process from a script. A script can start a workflow process from most locations in a Siebel CRM application or from a program that is external to Siebel CRM. If a workflow process starts from a script, then you can define it to run on the Siebel Server or in the Object Manager. A workflow process that starts from a script runs in Synchronous mode. Note the following:

• To run a workflow process on the Siebel Server, you configure Siebel CRM to call the Workflow Process Manager (Server Request) service.

• To run a workflow process in the Application Object Manager, you configure Siebel CRM to call the Workflow Process Manager service.

Starting a Workflow Process from a Script in the Object Manager

The following example script starts a workflow process named My Account Process that starts 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);
}

Starting a Workflow Process from a Script That Sends Field Values to Process Properties

The following example script starts a workflow process named My Opportunity Process that starts in the Object Manager. Siebel CRM passes field values to the process properties that are defined in the workflow process:

//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);

Using the Server Requests Business Service to Start a Workflow Process from a Script

You can use the Server Requests business service to asynchronously start a workflow process from a script. For more information, see Using the Server Requests Business Service to Start a Workflow Process from a Script.

Starting a Workflow Process from a Custom Toolbar

The example in this topic starts a workflow process from a custom toolbar.

To start a workflow process from a custom toolbar

1. If necessary, display the Command object type and the Toolbars object type in the Object Explorer.

   For more information, see Displaying Object Types You Use to Develop a Workflow Process.

2. In Siebel Tools, navigate to the Business Services list, and then create a new business service using values from the following table.

   Property	Value
   Name	TestTBItem
   Server Enabled	TRUE

3. Navigate to the Commands list, and then create a new command using values from the following table.

   Property	Value
   Name	TestTBItem
   Business Service	TestTBItem
   Method	TestTBItem
   Target	Server

4. In the Object Explorer, click Toolbar, and then query the Name property in the Toolbars list for the following value:

   HIMain
   

5. In the Object Explorer, expand the Toolbar tree, and then click Toolbar Item.

6. In the Toolbar Items list, add a new record using values from the following table.

   Property	Value
   Name	TestTBItem
   Command	TestTBItem
   DisplayName	TestTB Item
   Type	Button
   HTML Type	Button
   Position	20

7. In the Siebel client, define a workflow process and make sure it can run successfully from the process simulator.

   For more information, see Preparing to Use the Process Simulator.

8. Add the following server script to the business service that you defined in the step 2. You must use the name of the workflow process that you use in step 7:

   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" );
   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);
   }
   

9. Compile and test your changes in the Siebel client.

   Make sure Siebel CRM displays you new custom button in the custom toolbar. Click it to make sure the correct workflow process starts.

Other Configurations That Start a Workflow Process

For information about other ways to start a workflow process, see the following topics:

• To start from a synthetic event, see About the Synthetic Event.

• To start from a user event, see Configuring a User Event.

• To start from the Process Simulator, see About the Testing Tools.

• To start from a server component, see Overview: Siebel Enterprise Application Integration and Siebel Email Administration Guide.

You can use these configurations 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 process on the Siebel Server. You can also use these configurations to start a workflow process in your production environment.

Using the Business Integration Manager to Start a Workflow Process

It is recommended that you do not use Business Integration Manager or Business Integration Batch Manager:

• If your configuration uses the Business Integration Manager, then you must replace it with the Workflow Process Manager.

• If your configuration uses the Business Integration Batch Manager, then you must replace it with the Workflow Process Batch Manager.

Handling Errors

This topic includes the following topics:

• Using an Error Exception Connector to Handle Errors

• Using a Stop Step to Handle Errors

• Using an Error Workflow Process to Handle Errors

• Recovering a Failed Workflow Process

An error is a deviation from the normal or expected flow of a workflow process. You can use error handling to notify the user that an error occurred and to terminate the workflow process.

For information about using a process property when handling errors, see Passing Data Through a Process Property to an Error-Workflow Process.

Using an Error Exception Connector to Handle Errors

An error exception connector is a type of connector that can handle the following types of errors:

• Siebel CRM error. A failure that occurs while Siebel CRM sends an email notification.

• User error. A user who attempts to submit an order that is not complete.

You can use an error exception connector to change the flow in a workflow process. If an error occurs, then Siebel CRM enters the error code and error message in the Error Code and Error Message process properties. An error exception connector allows you to use values in these properties to define a decision condition.

The Process Designer displays an error exception connector as a red connector between two steps. If you click it, then the Properties window displays the WF Step Branch properties for the connector.

Siebel CRM evaluates exception logic for a step after the step finishes. If you must evaluate an exception before the step runs, then you must attach the error exception connector to an upstream step in the workflow process.

Example of Error Exception Handling

The following figure illustrates an example of error exception handling. If the Get Organization ID step cannot get data, then the workflow process continues to the Lookup Sender by Org step. If this step fails, then the workflow process runs the red exception connector, and then uses the Send Lookup Error Email step to send an email.

Table Example of a Workflow That Uses Error Exception Connectors to Programmatically Handle Exceptions

Defining an Error Exception Connector

You define an error exception connector in the Process Designer.

To define an error exception connector

1. Locate the workflow process you must modify.

   For more information, see Locating a Workflow Process in the Workflow Processes List.

2. Right-click the workflow process, and then choose Edit Workflow Process.

3. In the Process Designer, drag, and then drop an error exception connector from the palette to the canvas, attaching one end of the connector to an existing step where Siebel CRM must detect errors.

   The business service step and the Siebel operation step are typical step types where Siebel CRM can detect an error.

4. Make sure that you correctly attach the end of the connector to the step.

5. Drag, and then drop a stop step from the palette to the canvas.

6. Attach the unconnected end of the error exception connector to the stop step.

7. Make sure the error exception connector is chosen in the Process Designer.

8. Enter a value in the Name property in the Properties window.

9. In the Type property, choose Error Exception or User Defined Exception.

10. In the Process Designer, double click the error exception connector to access the Compose Condition Criteria dialog box.

11. Define decision conditions that apply for the exception.

    For more information, see Creating a Decision Condition on a Branch Connector.

Defining an Error Exception Connector to Handle an Update Conflict

The example in this topic defines an error exception connector to handle an update conflict that occurs if Siebel CRM attempts to make multiple writes to the same record at the same time. If the Workflow Monitor Agent (WMA) starts a workflow process, and if this agent updates a record, then the WMA can fail if another workflow process attempts to update this record, if another user attempts to update this record, or if another WMA task attempts to update this record since the workflow process first gets this record. In this situation, Siebel CRM display an error message that is similar to the following:

The selected record has been modified by another user since it was retrieved. 

To prevent the WMA task from failing, you can define an error exception connector that handles the update conflict that occurs while the workflow process runs.

To define an error exception connector to handle an update conflict

1. In Siebel Tools, create a new workflow process using values from the following table.

   Property	Value
   Process Name	Error Exception Example
   Workflow Mode	Service Flow
   Business Object	Opportunity

   For an example, see Creating the Workflow Process.

2. Add steps and connectors until your workflow process resembles the workflow illustrated in the following figure.

   

   For more information, see Overview of Workflow Process Steps, and Diagramming a Workflow Process.

3. Click the Update Opportunity business service step, and then use the Properties window to define properties described in the following table.

   Property	Value
   Business Service Name	ABC Update Opty
   Business Service Method	Update Opty

4. Make sure the Update Opportunity business service step is still chosen in the Process Designer.

5. Define an input argument in the MVPW using values from the following table.

   Field	Value
   Input Argument	Opportunity Id
   Type	Process Property
   Property Name	Object Id
   Property Data Type	String

   For more information, see Arguments That You Can Define for a Process Property.

6. Define a decision condition on the error exception connector named Interim Write Error using values from the following table.

   Property	Value
   Compare to	Process Property
   Operation	One Must Match (Ignore Case)
   Object	Error Code
   Values	0x8137 -- 0x6f74

   Siebel CRM returns the 0x8137 -- 0x6f74 error code with the following error message:

   The selected record has been modified by another user since it was retrieved
   

   For more information, see Creating a Decision Condition on a Branch Connector.

7. Define the Update Opportunity Again business service step, using the same values you used in step 3 and 4. For the Name property, use Update Opportunity Again.

8. Validate, and then simulate the workflow process.

   For more information, see Process of Testing a Workflow.

9. Implement this configuration in your production workflow process.

The Update Opportunity Again step allows Siebel CRM to write to the opportunity again if the first attempt to update the opportunity fails due to the update conflict error. This example uses a business service step that updates opportunities. You can use the same configuration with other step types that update a record, such as a Siebel operation step 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 can display an error message while a workflow process runs. It can include an exception handler that displays a customizable error message that can include an expression. For example, to handle real-time processing for credit card authorization or for order validation. For more information, see Adding a Stop Step.

Using an Error Workflow Process to Handle Errors

An error workflow process is a type of workflow process that runs if another workflow process reaches an error state. If this calling workflow process reaches an error state, then Siebel CRM stops the calling workflow process, passes system defined process properties to the error workflow process, and then runs the error workflow process.

A sub process can call an error workflow process. An error workflow process cannot contain a sub process.

Using an error workflow process to handle errors

1. In the Workflow Processes list, locate the workflow process that must call the error workflow process.

   For more information, see Locating a Workflow Process in the Workflow Processes List.

2. In the Workflow Processes list, in the Error Process Name property, choose a workflow process.

   Siebel CRM uses the workflow process that you define in the Error Process Name property as the error workflow process.

3. If the error workflow process must change the state of the calling workflow process, then you can add an error exception connector to the calling workflow process.

   An error workflow process does not return values back to the calling workflow process.

Benefits of Using an Error-Workflow Process

A universal exception handler is an error workflow process that Siebel CRM can use to handle an error that occurs across multiple steps in a workflow process or across multiple workflow processes. You can use it to reduce clutter in a workflow process diagram. You can reuse a single error workflow process that handles the same error for multiple calling workflow processes.

How Siebel CRM Handles Errors

This topic describes how Siebel CRM handles errors for a workflow process and for a sub process.

How Siebel CRM Handles Errors for a Workflow Process

If an error occurs in a workflow process, and if the Error Process Name property for this workflow process:

• Does not contain a value. This workflow process remains in the In Error state and Siebel CRM returns an error code to the object that called this workflow process.

• Contains a value. Siebel CRM runs the error workflow process. The following table describes the possible outcomes.

Table How Siebel CRM Handles Errors in an Error Workflow Process

Situation	Error State	Error Code	Result
The error workflow process handles the error successfully.	Completed	Siebel CRM does not return an error code to the object that called the error workflow process.	If the error workflow process encounters an end step, then error handling is successful and the error workflow process terminates immediately with a Completed state.
The error workflow process tries to handle the error but fails with a different error.	Error	Siebel CRM returns an error code to the object that called the error workflow process. You define this error code on the stop step of the error workflow process.	If the error workflow process encounters a stop step, then the error workflow process terminates immediately with In Error state.
The error workflow process cannot handle the error.	Error	Siebel CRM returns the original error code to the object that called the error workflow process.	If no start decision condition is met, then the error workflow process terminates immediately with In Error state.

How Siebel CRM Handles Errors for a Sub Process

If a subprocess encounters an error, and if an error workflow process is defined in the Error Process Name property for this subprocess, then the error workflow process finishes with one of the outcomes described in the following table.

Table How Siebel CRM Handles Errors for a Sub Process

Situation	Error State	Error Code	Result
The error workflow process handles the error successfully.	Completed	Not applicable	If the error workflow process encounters an end step, then error handling is successful and the subprocess terminates with a Completed state. Siebel CRM returns control to the calling workflow process. This calling workflow process continues to run from the next step.
The error workflow process attempts to handle the error but fails with a different error.	In Error	Siebel CRM returns an error code to the subprocess. You define this error code on the stop step of the error workflow process.	If the error workflow process encounters a stop step, then error handling failed. Siebel CRM terminates the error workflow process and the calling workflow process with the In Error state.

Recovering a Failed Workflow Process

For information about how to recover a failed workflow process, see Recovering a Workflow Process.

Configuring Events

This topic describes how to configure run-time events and user events that Siebel CRM can use with a workflow process. It includes the following topics:

• Configuring Run-Time Events

• Configuring a User Event

Configuring Run-Time Events

A workflow process can use run-time events to do the following:

• Allow real time monitoring of events

• Minimizes scripting and calling for a workflow policy

A workflow process can use the following types of events:

• Application event

• Business component event

• Applet event

A run-time event allows Siebel CRM to reply in real time to a user interaction. To start or resume a workflow process, you can define a run-time event on a connector that emanates from a start step, wait step, or user interact step. To define a run-time event, you can use the following properties of the WF Step Branch:

• Event Object Type

• Event Object

• Event

• Sub Event

• Event Cancel Flag

For more information, see Starting a Workflow Process, and Siebel Personalization Administration Guide.

Using Run-Time Events with a Long-Running Workflow Process

It is recommended that you do not configure Siebel CRM to use a run-time event to start a long-running workflow process because a run-time event is specifically related to a single user and a single session. It originates from Personalization functionality. Instead, it is recommended that you use an interactive workflow process or a service workflow process to handle a run-time event. After this workflow process finishes, Siebel CRM can create a user event that notifies a long-running workflow process.

Using Run-Time Events with a User Interact Step

If the Immediate Post Changes property of a business component field is TRUE, then Siebel CRM supports using the SetFieldValue event with a user interact step. If the field value changes, and if Immediate Post Changes is TRUE, then Siebel CRM does an immediate roundtrip to the Siebel Server, and then immediately recalculates the field or refreshes the view. It bypasses the PreSetFieldValue event in the browser script.

Siebel CRM does not support the following events with a user interact step:

• The DisplayRecord event.

• The DisplayApplet event.

• The Login event. You can use the WebSessionStart event instead.

For more information, see Configuring Siebel Business Applications.

Using Run-Time Events in a Business Object Context

Siebel CRM starts a workflow process that references a run-time event only if it detects the run-time event in the same business object context that the workflow process references. For example, assume the WriteRecord event starts a workflow process, and that the Business Object property for this workflow process is set to Service Request. To update the record, the user clicks the Service Requests List screen tab, updates the Status field, and then steps off the record. Siebel CRM writes the record in the context of the Service Request business object, and then starts the run-time event that is defined on the workflow process.

If the user updates the Status field in a context other than the service request business object context, then Siebel CRM does not start the run-time event. For example, assume the user drills down on a Contact, clicks the Service Requests view tab, updates the Status field, and then steps off the record. In this situation, Siebel CRM writes the service request record in the context of the Contact business object and it does not start the run-time event.

Defining a Run-Time Event in a Many-to-One Relationship

The example in this topic defines a run-time event in a many-to-one relationship. If you define a run-time event to start a workflow process in reply to a change that a user makes in a record that contains a many-to-one relationship with a parent, then you must configure Siebel CRM to start the workflow process according to the child ROW_ID. For example, assume you require Siebel CRM to start a workflow process if the user updates a field in the activity of a service request. A service request can contain one or many activities, so Siebel CRM must start the workflow process according to the activity ROW_ID and not according to the service request. If you start the workflow process according to the service request ROW_ID, then the following occurs:

• If the user changes data in the form applet for the service request, then Siebel CRM starts the workflow process.

• If the user changes data in the activities list applet, then Siebel CRM does not start the workflow process.

To define a run-time event in a many-to-one relationship

1. Optional. For educational purposes, you can examine a one to many relationship:

   1. In the Siebel client, navigate to the Service Request screen, and then the Service Request List view.

   2. Create a new service request.

   3. Click the SR# field.

   4. Use the Activities list to create two new activities.

   5. 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.

2. In Siebel Tools, in the Workflow Processes list, create a new workflow process using values in the following table.

   Property	Value
   Process Name	Update Service Request
   Business Object	Service Request
   Workflow Mode	Interactive Flow

   The workflow process references the Service Request business object. The run-time event that this workflow process uses occurs on the start step. It references the Action business component, which is a child of the Service Request business object. It includes a wait step for testing purposes. A wait step requires an Interactive Flow. For more information, see Adding a Wait Step. For an example, see Creating the Workflow Process.

3. Open the Process Designer for the workflow process you defined and then define a workflow that resembles the workflow in the following figure.

   

   For more information, see Overview of Workflow Process Steps, and Diagramming a Workflow Process.

4. Click the Id Triggered connector, and then use the Properties window to define values described in the following table.

   Property	Value
   Event Object Type	BusComp
   Event	WriteRecord
   Event Object	Action

5. Click the canvas, making sure no workflow process step or connector is chosen.

6. In the MVPW, right-click, and then add a new process property using values from the following table.

   Field	Value
   Name	ActionBCRowId%
   In/Out	In/Out
   Business Object	Service Request

   For more information, see Using Process Properties.

   To capture the activity ROW_ID, you define a process property, and then use a wait step that reads a field from the child business component into the process property in the output argument for the wait step. It does not modify the underlying data.

7. Click the Get Activity Id step, and then click the Output Arguments tab in the MVPW.

8. Right-click, choose New Record, and then create a new record using values from the following table.

   Field	Value
   Property Name	ActionBCRowId%
   Type	Expression
   Value	Id
   Business Component Name	Action

   For testing purposes, this step reads the activity ROW_ID, which is the Id field, into the ActionBCRowId% process property. You do not need to define input arguments for the wait step.

9. Validate, and then simulate the workflow process.

   For more information, see Process of Testing a Workflow.

10. Implement this configuration in your production workflow.

    This example demonstrates how you can start a workflow process according to changes that Siebel CRM makes to a child in a many-to-one relationship. It includes steps that test the configuration. In a production environment, if it is not necessary to capture the child ROW_ID, then you can define the trigger for the run-time event on the connector that emanates from step 4.

Using a Run-Time Event with the Updated By Field

If a workflow process step includes a run-time event that uses a processing mode that runs locally to start or resume a workflow process, then the value in the Updated By field identifies the user who is currently logged into Siebel CRM.

Run-Time Events That You Cannot Use to Start a Workflow Process

To start a workflow process, Siebel CRM cannot use a run-time event that might not return a result. It can start a workflow process only in the record context of a business component. If business component record context does not exist, then Siebel CRM cannot start the workflow process and attempting to use the BusComp Query event to start it will fail.

Using a Run-Time Event More Than One Time

You cannot use the same run-time event more than one time in a given workflow process.

Configuring a User Event

A user event is a unique event that is internal to Siebel Workflow. It starts or resumes a long-running workflow process from the Workflow Process Manager. It belongs to one of the following object types:

• Application

• Applet

• Business Component

Siebel CRM can use a user event to do the following:

• Start or resume a long-running workflow process that runs in the Workflow Process Manager (WFProcMgr) server component.

• Start a workflow process if the user event is attached to a start step.

• Resume a workflow process instance that is paused. You configure the user event on a workflow process step that can receive an input argument.

• Be used in a long-running workflow process that spans multiple users.

A long-running workflow process must use only a user event, and not a run-time event.

Using the Workflow User Event Service Business Service to Create a User Event

To create a user event, Siebel CRM calls the Workflow User Event Service business service. Siebel CRM can use it only in a long-running workflow process.You cannot modify Siebel CRM to cause a long-running workflow to resume on a custom workflow process server component.

The Workflow User Event Service business service must communicate with the Workflow Process Manager to use a user event. Siebel CRM can call the Workflow User Event Service business service from a business service step, a script, a COM interface, or a Java interface. For example, assume a 7.0 Flow workflow process or a service workflow process starts a user event. A business service step calls the Workflow User Event Service business service to communicate with a long-running workflow process that runs in the background.

Most types of workflow processes or business services can create a user event. It is recommended that you define only a long-running workflow process to receive a user event.

For more information, see Workflow User Event Service Business Service.

Starting the Workflow User Event Service Business Service

This topic describes how to call the Workflow User Event Service business service to create a user event.

To start the Workflow User Event Service business service

1. Add a business service step to a workflow process.

2. Click the business service step you added above and use the Properties window to define values described in the following table.

   Property	Value
   Business Service Name	Workflow User Event Service
   Business Service Method	GenerateEvent

3. In the MVPW, create a new input argument for the step.

   For more information, see Arguments That You Can Define for a Process Property.

4. In the Input Argument field, choose Payload, and then define the other fields, as appropriate.

5. Repeat the last two steps and choose Correlator Value and then User Event Name respectively.

Configuring a Long-Running Workflow Process to Wait for a User Event

A long-running workflow process is the only type of workflow process that can wait for a user event. Other types of workflow processes can create a user event but not wait for a user event.

To configure a long-running workflow process to wait for a user event

1. Open the Process Designer for the workflow process where you must define a user event.

2. In the Multi-Value Property Window, set the Correlator Flag field for one of the process properties for the workflow process to TRUE.

   For more information, see Using Process Properties.

3. 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	Value
   Type	Condition If you set Type to Default rather than to Condition, then Siebel CRM does not call the user event.
   User Event Name	Enter the name of the workflow process that you defined for the Value property in Starting the Workflow User Event Service Business Service.
   User Event Timeout	Choose the name of the process property that holds the payload that Siebel CRM passes from the user event.
   User Event Storage	Enter the timeout period for the user event. The User Event Timeout works in a way that is similar to the timeout for a run-time event. If Siebel CRM does not receive a user event during the timeout period, then it resumes the workflow process after the timeout period expires.

Siebel CRM does not queue a user event. If no recipient is waiting to accept the user event with the defined correlator, then Siebel CRM discards the event.

Configuring Batch Processing

If Siebel CRM must run a workflow process for every record of a business component, then you can configure the Workflow Process Batch Manager (WfProcBatchMgr) server component. It can run a workflow process one time for each record that the primary business component contains. For more information, see Defining the Primary Business Component.

It is recommended that Siebel CRM only run a service workflow process or a 7.0 flow workflow process in batch mode.

For more information about running a workflow process in batch, see Siebel System Administration Guide.

To configure batch processing

1. In the Siebel client, navigate to the Administration-Server Configuration screen, Enterprises, and then the Component Definitions view.

2. In the Component Request form, click New.

3. In the Component/Job field, click the selection button.

   The Component/Jobs dialog box displays.

4. Choose Workflow Process Batch Manager.

5. In the Component Request Parameters form, click New.

6. In the Name field, click the selection button, and then choose Workflow Process Name from the dialog box.

   For more information, see Parameters of the Workflow Process Batch Manager.

7. In the Value field, type in the name of the workflow process to run.

8. Click New to add another parameter.

9. In the Name field, click the selection button.

10. Choose Search Specification.

11. In the Value field, provide a search specification.

Parameters of the Workflow Process Batch Manager

The following figure describes parameters of the Workflow Process Batch Manager server component.

Table Parameters of the Workflow Process Batch Manager

Display Name	Description
Workflow Process Name	Required. Name of the workflow process that Siebel CRM runs.
Search Specification	Search specification that identifies the work items to process. Siebel CRM uses the Search Specification parameter only with the Workflow Process Batch Manager server component. If you define this parameter for any other server component, such as the Workflow Management server component, then Siebel CRM does not use it.

Configuring Batch Processing with a Search Specification

To limit the number of records that Siebel CRM evaluates when it runs a workflow process in batch, you can define a search specification. Siebel CRM uses the Search Specification parameter on the Workflow Process Batch Manager to run the search specification on the primary business component. For each record it finds, the Workflow Process Batch Manager starts the workflow process and sets the Object Id process property to the current active row. For more information, see Defining the Primary Business Component.

If you do not define a search specification, then the Workflow Process Batch Manager runs the workflow process for each record of a particular type. For example, if 100 service requests exist, then it runs the workflow process 100 times, one time for each service request.

Configuring Batch Processing to Run Repeatedly at a Specific Interval

To configure Siebel CRM to run a batch at a specific interval, you can use the Repeating Component Request feature. For example, you can configure a workflow process to run at 7 A.M. every Monday. For an example workflow process that uses a repeating component request, see Defining a Workflow Process That Traverses a Record Set to Close Service Requests. For more information, see Siebel System Administration Guide.

Configuring Batch Processing with Linked Fields

If Siebel CRM runs the Workflow Process Batch Manager, and if the Link Specification property is TRUE on a field of the primary business component, then Siebel CRM might return more records than expected. This situation can affect performance.

If the primary business component contains a link relationship with one or more nonprimary business components, as created through a Link on the current business object, then Siebel CRM passes the value that the field contains to a field in the nonprimary business component through this link. If Siebel CRM runs Workflow Process Batch Manager in batch mode, or if a custom business service queries business component records, then it is important to monitor performance and modify the configuration, if necessary. For more information, see Defining the Primary Business Component.

Configuring Batch Processing with a Custom Business Service

If a custom business service that you define includes a loop that processes every business component record, and if it runs business service code on each of these records, then you must consider how this configuration uses the server component. The following table compares how the two server components work in this situation.

Table Comparison of Using Workflow Process Manager to Workflow Process Batch Manager

Server Component	Description
Workflow Process Manager	The business service and the loop handle every record at one time. It is recommended that you use this configuration to run this business service and the workflow process.
Workflow Process Batch Manager	The business service for the workflow process already contains a loop. Using Workflow Process Batch Manager causes the business service loop to run for every record in the primary business component. This configuration can result in undesirable duplicate and repeated execution.

Configuring 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:

• Using Literal Values in a Multilingual Environment

• Using Expressions in a Multilingual Environment

• Using Wait Steps with Global Time Calculations

• Using the Locale Code Parameter

To configure a workflow process to work correctly in a language other than the base language, you must make sure the database that your configuration uses can handle Multilingual Lists Of Values (MLOV) for the type of language that the production environment uses. For example, if you must modify a workflow to use FRA, and if the base language is ENU, then make sure that List of Values entries exist for the FRA language type.

For more information, see Siebel Global Deployment Guide.

To configure a workflow process for a multilingual environment

1. In the Siebel client, navigate to the Administration-Data screen, and then the List of Values view.

2. Run the following query:

   Type = "WF_*"
   

3. Run the MLOV upgrade utility to make sure the Siebel database is capable of handling a multilingual list of values.

   For more information, see Configuring Siebel Business Applications.

4. In the List of Values list, make sure the Active property is set.

Using Literal Values in a Multilingual Environment

A literal value is language dependent. A literal value in a dynamic drop-down list might contain content that a user creates at run-time. A workflow process cannot interpret these values in a predictable way. A workflow process that references a literal value is language dependent and cannot run in a multilingual environment. For more information, see Siebel Global Deployment Guide.

Using Expressions in a Multilingual Environment

A workflow process uses the Display value to get records from tables. Siebel CRM stores data in these tables in Language Independent Code (LIC) to support a multilingual environment. To run a workflow process in a multilingual environment, you can use the LookupValue function that gets the language independent code according to the Display value.

Decision Point Example

Assume a decision point compares Account Status to Active. The Account Status drop-down list bounds the Account Status field. 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

To send an email to an expense approver, assume a business service step calls the Outbound Communications Manager. The Comm Recipient Group drop-down list bounds the Recipient Group argument. 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 about globalization, see Siebel Global Deployment Guide. For more information about defining Siebel Workflow to use MLOV capable fields, see Configuring Siebel Business Applications.

Using Wait Steps with Global Time Calculations

Siebel CRM can use the following types of wait steps:

• Absolute Wait. A wait period that the duration controls. For example, an absolute wait that you set for 30 minutes waits 30 minutes from the time that the wait step starts the wait.

• Service Calendar Wait. Not absolute. For example, assume a service calendar wait begins at 6:00 P.M. but the service hours for the organization are 9:00 A.M. to 6:00 P.M.In this situation, the wait does not start until 9:00 A.M. the next morning. It runs from 9:00 A.M. to 9:30 A.M. instead of from 6:00 P.M.to 6:30 P.M.

Using a Time Zone Setting with a Wait Step

If a workflow process runs as a server task, then you must shut down, and then restart the Workflow Process Manager after you make any changes to the Time Zone user preference for the SADMIN user. Siebel CRM uses these changes only after it restarts the Workflow Process Manager, which is important if you your deployment uses UTC because it might be necessary for you to set the Time Zone user preference.

Time zone settings do not affect an absolute wait, including server or user time zone preferences. You can use UTC with the server that contains the database that your Siebel CRM deployment uses. For more information, see Siebel Global Deployment Guide.

A service calendar wait step requires a time zone for delay computations. In this situation, Siebel CRM uses the time zone for the current user.

Using the Locale Code Parameter

The Locale Code parameter for the Workflow Process Manager (WfProcMgr) server component includes formats for data, such as dates, times, numbers, and currency. Note the following:

• If a workflow process runs in the Workflow Process Manager, then the Workflow Process Manager formats data according to the format that you define in the Locale Code parameter.

• If a workflow process communicates with an application that is external to Siebel CRM or that writes data to a file, then it passes date, time, number, and currency data according to the format that you define in the Locale Code parameter.