7Adding Workflow Process Steps
Adding Workflow Process Steps
This chapter describes how to add steps to a workflow process. It includes the following topics:
Overview of Workflow Process Steps
This topic describes an overview of steps that you can use in a workflow process. It includes the following topics:
Adding a Step to a Workflow Process
You use the Process Designer to add a step to a workflow process. You can use the Properties window to define properties for the step. Siebel Tools displays a record for the new step in the WF Steps list after you save the workflow process. In some situations, you can modify these properties in the WF Steps list.
To add a step to a workflow process
Locate the workflow process you must modify.
For more information, see Locating a Workflow Process in the Workflow Processes List.
If the status of the workflow process is Completed or Not In Use, then click Revise in the WF/Task Editor toolbar.
For more information, see Using Process Properties.
Right-click the workflow process in the Workflow Processes list, and then click Edit Workflow Process.
Siebel Tools opens the Process Designer, Workflow Designer Palette, and the Properties windows. The workflow is editable. If the palette is not visible, then choose the View menu, Windows, and then click Palette.
Drag, and then drop the step type that you must add from the Workflow Designer Palette to the canvas.
In the Properties window, enter or modify the Name property.
If you step out of the property, then Siebel Tools updates the step name in the canvas. For more information, see Naming a Workflow Process Step or a Process Property.
Optional. In the Properties window, enter a value in the Description property that describes the purpose of the step.
Define other properties for the workflow process step, as necessary.
For more information, see the topic about the Workflow Process Step object type in Siebel Object Types Reference.
Naming a Workflow Process Step or a Process Property
The name that you use for a workflow process step or process property must be unique in the workflow process. You cannot use some symbols, such as the period (.), in the name of a process property.
If you add a new step, then Siebel Tools populates the Name property of the step with a name and number combination that you can change. The step or connector type determines this name. For example:
Business Service 0 for a business service step
Siebel Operation 0 for a Siebel operation step
The number differentiates instances of the same type of step or connector that the workflow process contains. For example, Business Service 0 and Business Service 1. You can change this name.
Siebel Workflow uses the following name for this number and stores it as part of the name:
sequence
How Siebel Tools Assigns Sequence Numbers to Workflow Process Steps
If you add a new step to a workflow process, and if this workflow process already contains an instances of this step type, and if:
No gap exists between the sequence numbers for the step type, then Siebel Tools uses the next number in the sequence.
A gap does exist, then Siebel Tools uses the first sequence number that is available to fill the gap. If you delete a step, then a gap results.
For example, assume a workflow process includes the following business service steps:
Business Service 0
Business Service 1
Business Service 2
Business Service 3
Business Service 4
If you delete Business Service 1 and Business Service 2, and if you then add a business service step, then Siebel Tools names this new step Business Service 1. Siebel Tools uses the same numbering configuration for connectors.
Configuring the Properties of a Workflow Process Step
You can use the following tools to define the properties of a workflow process step:
Process Designer. You can define properties in the Properties window.
Object List Editor. You can define properties in the WF Steps list.
For more information, see the topics about the Workflow Step and Workflow Branch object types in Siebel Object Types Reference.
Deleting a Workflow Process Step or Connector
When you delete a Workflow Step or a Connector from the Canvas Editor,
It is deleted from the canvas and from the WF Step List Applet for a new workflow.
It is deleted from the canvas and becomes inactive in the WF Step List Applet for an existing workflow.
Adding Steps and Connectors
This topic describes how to add steps and connectors to a workflow process. It includes the following topics:
For information about defining a decision condition and adding a branch connector, see Configuring a Decision Condition.
For more information, see Overview of Workflow Process Steps.
Overview of Step Types
The following image includes the Workflow Designer Palette. It displays an icon for each step type.

Adding a Start Step
A start step is a type of workflow process step that indicates the starting point of the workflow process. A workflow process can contain only one start step. You can define a decision condition and a run-time event on the connector that emanates from the start step, but not on the start step itself. You can define the connector that emanates from a start step to do the following work:
Define the decision conditions that must be met to start the workflow process. For example, to handle an open service request, you can define a condition of Status equals Open on the connector. For more information, see Configuring a Decision Condition.
Define a run-time event that starts the workflow process. For example, to create an activity if the revenue for an opportunity is greater than $10,000, you can define a WriteRecord run-time event, and then define a workflow that inserts the activity if the user saves an opportunity that meets the decision condition. For more information, see Starting a Workflow Process from a Run-Time Event. For an example that uses a run-time event, see Defining a Workflow Process That Creates an Activity for a Sales Representative.
For more information, see Starting a Workflow Process.
To add a start step
Add a start step to a workflow process.
For more information, see Adding a Step to a Workflow Process.
Optional. To configure a run-time event to start the workflow process, you attach a connector to the start step, and then define the run-time event on this connector.
Adding a Business Service Step
A business service step is a type of workflow process step that allows you to run a predefined or custom action in a workflow. The following items are examples of predefined business services:
Notification. Siebel CRM can use the Outbound Communication Server business service to send a notification to an employee or a contact.
Assignment. Assignment Manager can call the Synchronous Assignment Manager Request business service to assign an object in a workflow process.
Server task. You can use the Asynchronous Server Requests or the Synchronous Server Requests business service to run a server component task.
For a list of some of the more commonly used predefined business services, see Predefined Business Services.
To define your own custom business service, you can use Siebel Tools or the Administration-business service view in the Siebel client. You can use Siebel VB or Siebel eScript to define your own custom business service that you call from a workflow process.
To add a business service step
Add a business service step to a workflow process.
For more information, see Adding a Step to a Workflow Process.
Make sure the step you added is still chosen in the Process Designer.
In the Business Service Name property, choose the name of the business service that this workflow process must call.
This drop-down list contains the business services that are defined in Siebel Tools or the Siebel client. For more information about defining a custom business service, see Integration Platform Technologies: Siebel Enterprise Application Integration.
Caution: A business service that Siebel CRM calls from a workflow process must not include a browser script. A business service only works with a server script. If Siebel CRM runs a business service, and if this business service includes a browser script, and if a workflow process calls this business service on the Siebel Server, then the business service might fail.In the Business Service Method property, choose the method that calls the business service. The choices available for this property depend on the business service you defined.
Make sure the business service step is chosen.
Use the MVPW to define input arguments and output arguments.
For more information, see Defining a Step Argument in the MVPW.
Making a Business Service Visible to a Workflow Process
A business service includes the business service, business service method, and business service method argument. Each of these objects include a Display Name property and a Hidden property. To display each object in various drop-down lists in Siebel Tools, the Hidden property of the object must be set to FALSE. For example, Siebel Tools displays the methods and arguments that you define in a business service in the drop-down lists in the Arguments list. Siebel CRM does not hide a business service that you define in the Siebel client, by default.
To make a business service visible to a workflow process
In Siebel Tools, in the Object Explorer, click Business Service
In the Business Services list, locate the business service you must modify.
In the Properties window, change the Hidden property to FALSE.
In the Object Explorer, expand the Business Service tree, and then click Business Service Method.
In the Business Service Methods list, locate the method you must modify, and then change the Hidden property to FALSE in the properties window.
Repeat the last step for each method, if necessary.
In the Object Explorer, expand the Business Service Method tree, and then click Business Service Method Arg.
In the Business Service Method Arguments list, click the argument you must modify.
In the Properties window, change the Hidden property to FALSE.
Repeat the last step for each method argument, if necessary.
Using the Pass By Reference Feature with a Business Service
You can use the PassByRef user property on a predefined business service. For more information, see Using the Pass By Reference Feature with a Sub Process.
To use the Pass By Reference feature with a business service

In the Object Explorer, click Business Service.
In the Business Services list, locate the predefined business service you must modify.
You cannot use the Pass By Reference feature with a custom business service. You can use it only with a predefined business service.
In the Object Explorer, expand the Business Service tree, and then click Business Service User Prop.
In the Business Service User Prop list, add a user property using values from the following table.
User Property Value PassByRef
True
Make sure the Pass By Reference check box for the business service step contains a check mark.
If you do not do this, then the Workflow Engine returns an error.
How a Business Service Calls a UNIX Shell Script
A Siebel process that runs on UNIX runs as the user process that starts Siebel Services. If a workflow process calls a business service that calls a UNIX shell script, then this shell script runs as the Siebel Service Owner account.
Adding a Decision Point
A decision point is a type of workflow process step that evaluates one or more decision conditions to determine the next step that the workflow process runs. A decision point evaluates the user data of a business component when the workflow process. For example, assume a workflow policy starts the workflow process, and that multiple violations of a workflow policy condition occur during the action interval of the Workflow Monitor Agent. When this workflow process runs, the decision point determines the branch to pursue according to the current value of the business component field.
To add a decision point
Add a decision point to a workflow process.
For more information, see Adding a Step to a Workflow Process.
Define a decision condition for the decision point.
For more information, see Creating a Decision Condition on a Branch Connector.
Moving Branch Logic from a Workflow Process to a Workflow Policy
If you move the logic of a branch connector from the workflow process to the workflow policy, then the workflow policy creates unique events in the defined action interval, and a violation of the workflow policy starts the workflow process. For more information, see Configuring Expressions in the Expression Builder.
Adding a Sub Process Step
A sub process step is a type of workflow process step that allows you to start a separate workflow process from a workflow process. A workflow process can contain one or more sub process steps. You can also define a sub process step that supports Pass By Reference. For more information, see the following:
Passing a Process Property In and Out of a Workflow Process Step.
See the topic about the Workflow Process object type in Siebel Object Types Reference.
To add a sub process step
Make sure the workflow process that the sub process step calls exists.
An object definition for the workflow process that the sub process step calls must exist before you can add a sub process step. If it does not exist, then you must define it now. For more information, see Creating the Workflow Process Object Definition.
Add a sub process step to a workflow process.
For more information, see Adding a Step to a Workflow Process.
Make sure the step you added in step 1 is still chosen in the Process Designer.
In the Properties window, in the Subprocess Name property, choose the workflow process that the sub process step calls.
In the MVPW, add new input arguments and output arguments.
For more information, see Defining a Step Argument in the MVPW and Adding an Input Argument on a Sub Process Step.
Define recipient arguments in the MVPW.
For more information, see Recipient Argument Fields of a Process Property.
To edit the workflow process that the sub process references, you can do the following:
Right-click the sub process step, and then click Edit Sub Process.
Double-click the sub process step.
Using a Sub Process Step with the Process Simulator
If you must use the Process Simulator, and if the workflow process you must simulate includes a sub process step, then you must publish and activate the workflow process that the sub process calls before you do the simulation. For more information, see Using the Process Simulator.
Adding an Input Argument on a Sub Process Step
You can add an input argument to a sub process step. This input argument allows you to populate a process property in the sub process step. For example, Siebel CRM passes the Object Id from the main workflow process to the sub process through an input argument. If the sub process references a different business object, then you must send the relevant row ID of the target object as the Object Id process property of the sub process.
If the sub process creates a child object, then the Object Id that Siebel CRM passes to a sub process must not contain the Object Id of the parent process. If a sub process creates a child object, then it is recommended that the Object Id that Siebel CRM passes to a sub process be null.
To add an input argument on a sub process step
Add an input argument to a sub process step.
For more information, see Defining a Step Argument in the MVPW.
Copying a Value from a Parent Workflow Process to a Sub Process
To copy a value to a record that a sub process updates or inserts, you can define a process property in the sub process, and then use an Input Argument on the sub process step to assign a value to this process property. A Siebel operation step in the sub process can then use this process property. The example in this topic copies the Order Name for an order into the Name field of a newly created opportunity.
To copy a value from a parent process to a sub process
Add a process property to the Opportunity Name sub process.
For more information, see Defining a Custom Process Property.
Click the Order Parent Product Name sub process step.
In the Properties window, set the Subprocess Name property to Opportunity Name.
Assign Opportunity Name to the Name field of the opportunity that Siebel CRM creates in the Siebel operation step.
Using the Pass By Reference Feature with a Sub Process
If a sub process modifies a large amount of data, then it must also copy a large amount of data. This configuration can result in a negative impact on performance and scalability. You can use the Pass By Reference feature so that Siebel CRM passes a pointer to the data instead of copying the data.
The following figure includes an example workflow process that passes a large property set from the Create Siebel Message step to the 11i Process Order step.

If you configure a sub process step to support Pass By Reference, then it is not necessary to map the output argument in the sub process step for the hierarchical properties that Siebel CRM passes. The sub process step overwrites the passed input hierarchical argument. Optionally, you can define the sub process step to modify the passed input hierarchical argument.
To use the pass by reference feature with a sub process
In the Workflow Processes list, choose a workflow process that another workflow process references as a sub process.
In the Properties window, set the Pass By Ref Hierarchy Argument process property to TRUE.
In the Worfklow Processes list, Siebel Tools now includes a check mark for the Pass by Ref Hierarchy property of the workflow process that is the sub process.
Adding a Siebel Operation Step
This topic describes how to add the Siebel operation step. It includes the following topics:
Using a Siebel Operation Step to Update a Field That Referencesa Multi-Value Group
How Siebel Operations and Workflow Policy Programs Use Different Object Layers
The Siebel operation step is a type of workflow process step that does an operation on a business component, such as insert, update, or query. You define a Siebel operation step for the business component that a business object references. The workflow process references this business object. If you configure Siebel CRM to update a business component that this business object does not reference, then you can use Siebel Tools to start a sub process or to associate the business component with the business object. For more information, see Defining the Primary Business Component.
To add a Siebel operation step
Add a Siebel operation step to a workflow process.
For more information, see Adding a Step to a Workflow Process.
Make sure the step you added is still chosen in the Process Designer.
In the Properties window, in the Operation property, choose an operation.
For more information, see Configuring the Operation Property.
In the Business Component property, choose the business component that contains the data that the Siebel operation modifies.
Optional. In the MVPW, add new input arguments and output arguments.
If you choose Insert or Upsert in step 3, then make sure you add the required arguments in the MVPW. For example:In the Field Name field, make sure you define the name of the field that Siebel CRM must update.
In the Type field, choose an input argument type, and then define other fields, depending on the type.
For more information, see Arguments That You Can Define for a Process Property.
Optional. Define a search specification in the MVPW:
- In the Type field, choose a search specification type, as described in the following table.
Type Description Literal
A static string where the run-time value is the same as the value that you define in the Process Designer.
Expression
A Siebel expression that references a run-time variable. Siebel CRM can evaluate the expression only at run-time.
In the Search Specification field, enter a search specification.
If the search specification Type is Expression, then choose a business component.
For more information, see Using a Siebel Operation Step with a Search Specification.
- In the Type field, choose a search specification type, as described in the following table.
Using a Siebel Operation Step to Update a Process Property
You can define a test workflow process that uses a Siebel operation to update a process property. For example, you can use the sum of two business component integer fields that provide input to a decision that resides downstream in the workflow process. Siebel CRM uses the sum of the two required fields to update a process property in the Siebel operation step. You can then use this property on a subsequent branch connector.
The example in this topic references the Action business object.
To use a Siebel operation step to update a process property
In Siebel Tools, add a new workflow process using values from the following table.
Property
Value
Process Name
Updating a Process Property
Business Object
Action
Workflow Mode
Service Flow
For an example, see Creating the Workflow Process.
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.
Click the canvas, making sure no workflow process step or connector is chosen.
In the MVPW, right-click, and then add a new process property using values from the following table.
Field
Value
Name
Custom Process Property
Display Name
Custom Process Property
In/Out
In/Out
Business Object
Action
For more information, see Using Process Properties.
Click the Update Process Property step, and then click the Search Spec Input Arguments tab in the MVPW.
Right-click, click New Record, and then create a new record using values from the following table.
Field
Value
Expression Business Component
List of Values
Filter Business Component
Query
Search Specification
[Name] = 'Personal' AND [Type] = 'TODO_TYPE'
Type
Literal
Make sure the Update Process Property step is chosen in the Process Designer.
Click the Output Arguments tab in the MVPW.
Right-click, click New Record, and then create a new record using values from the following table.
Field
Value
Property Name
Custom Process Property
Type
Expression
Value
[Class Code]
Business Component Name
List Of Values
Validate, and then simulate the workflow process.
For more information, see Process of Testing a Workflow.
Implement this configuration in your production workflow process.
Using a Siebel Operation Step with the Object Id Process Property
When Siebel CRM finishes an Insert or Upsert operation, it stores the row ID of the record that it created. It stores this ID in the Siebel Operation Object Id process property. It passes the Object Id of the workflow process to the Siebel operation step. It is not necessary to define a search specification unless Siebel CRM must update child records. For example, if a workflow process:
References the Service Request business object, then it must update the service request but it is not necessary to define a search specification.
Must update activity records for the service request, then you can enter a search specification that queries for the activity that Siebel CRM must update. If you do not do this, then the update step updates every activity that Siebel CRM associates with the service request.
If Siebel CRM runs a Siebel operation, then the Object Id cannot be null unless it inserts this Object Id into the primary Object Id. If the workflow process does not contain an Object Id, then the Siebel operation step returns an error.
The Siebel Operation Object Id process property returns the following values if a query operation modifies child records:
The row ID if one record matches.
Null or no value if no records match.
An asterisk (*) if multiple records match. It provides this result to distinguish from a value that returns a unique record or no record. Typically, a unique record matches or no records match. In most situations, multiple records do not match and Siebel CRM returns an asterisk.
The following option returns the row ID of a matching row:
only
The Insert, Update, and Upsert operations update the Siebel Operation Object Id process property of the row ID for the record.
Using a Siebel Operation Step with the Upsert Operation
The Upsert Operation can do an update or insert operation depending on if a record or records exist in the Siebel database. Hence the name, Upsert. Assume a search specification on a Siebel operation step queries the Siebel database and returns one of the following results:
Returns one or more records. Upsert updates these records according to the workflow process configuration.
Returns no records. Upsert insert a record according to the workflow process configuration.
For example, assume the following occurs:
Siebel CRM navigates a user to a view where the user can click a check box to create a new contact.
The Yes default for the check box causes Siebel CRM to create a new contact.
The user enters the contact information.
The user navigates away from the view, and then returns to the view.
When the user returns there is the potential that Siebel CRM will create another contact. Siebel CRM must determine if the contact already exists. If a contact exists, then it must update this contact. If the contact does not exist, then it must create a new contact.
For another example, assume a workflow process runs in the background at midnight, processing orders that an external system sends to Siebel CRM:
If an order does not exist, then Upsert creates a new record.
If an order already exists but must be updated, then Upsert updates the record.
Configuring the Operation Property
If you configure this step to update or insert a field that contains a dependency, then you must make sure the field is valid. For example, if a service request process and a workflow process update the area and sub area fields, then you must make sure the values chosen for the subarea field are valid for this area.
If your configuration uses a DB2 for z/OS database, and if you must use a Siebel operation step to query this database, then it is recommended that you set the Operation property to QueryBiDirectional and not to Query. Using QueryBiDirectional avoids leaving an open thread on DB2 for z/OS.
Using a Siebel Operation Step with a Search Specification
You can use a search specification to filter the business component records that a Siebel operation modifies. For example, if a workflow process for the Account object must only update opportunities that possess a lead quality of Poor, then you can define a search specification that only returns these opportunities.
For information about using a search specification in an example workflow process, see Creating the Workflow Process.
Adding a Literal Search Specification
If the search specification is of type Literal, then Siebel CRM interprets it literally. For example, [Status] LIKE '*Open*'. A search specification of type Expression allows you to create a search specification dynamically. For example, consider the following search specification:
"[Contact ID] = ' " + [&New ID] + " ' "
If the New ID process property is 1-ABC at run time, then Siebel CRM interprets this search specification to the following value:
[Contact ID] = '1-ABC
Referencing a Business Component Field in a Search Specification
Each side of an expression can reference a business component field:
The Filter Business Component defines the business component on the left side.
The Expression Business Component defines the business component on the right side.
The following table describes an example of this configuration.
Table Example of Referencing Business Component Fields in a Search Specification
Field | Value |
---|---|
Filter Business Component |
Account |
Expression Business Component |
Contact |
Expression |
"[Id] = [Account Id]" |
Siebel CRM uses the following format to evaluate this expression:
"[Account.Id] = [Contact.Account Id]"
Using Compound Expressions and Substitutions in a Search Specification
You can use compound expressions and substitutions in a search expression. For example, consider the following generic format:
"([Field1] > '" + [&Process Property Name] + "') OR ([Field2] IS NULL) OR ([Field3] IS NULL)"
Siebel CRM translates this format to the following value:
([Field1] > 'value') OR ([Field2] IS NULL) OR ([Field3] IS NULL)
An expression can include a literal representation of a business component field. For example:
-
"([Open] > '" + [&dFromDate] + "') OR ([Open] IS NULL)"
-
"([Open] > '" + [&dFromDate] + "') AND ([Status] IS NULL)"
where:
dFromDate is a custom process property
For more information about using a process property as a substitution variable, see Referencing a Process Property.
Using a Siebel Operation Step to Update a Field That Referencesa Multi-Value Group
A Siebel operation step can indirectly update a field that references a multi-value group. For example, assume Siebel CRM must update the Account Team business component field. This field references a multi-value group, so you cannot use a Siebel operation step to update it. You can define a business component named Account Team, and then associate it with the Account business object. You can then choose Account Team as the business component that the Siebel operation step updates. For more information about multi-value groups, see Configuring Siebel Business Applications.
Using a Siebel Operation Step with a Calculated Field
A Siebel operation step cannot update a calculated field because, typically, the calculated field requires values from the fields of another business component. Instead, you can use an expression to perform calculations.
Using a Siebel Operation Step to Traverse a Record Set
To traverse a record set, you can use the NextRecord, PrevRecord, and QueryBiDirectional operations on the Siebel operation step in conjunction with the Update, Query, and Insert operations. You can use the following operations to traverse the records of a child business component of the business object that the workflow process references:
NextRecord. Changes the active row of the business component to the next record.
PrevRecord. Changes the active row to the previous record.
You must configure Siebel CRM to perform a query on the business component before it uses another Next Record or Previous Record operation. If the workflow process traverses active records or if it uses the PreviousRecord operation, then use the QueryBiDirectional operation. Otherwise, use the Query operation.
You cannot use NextRecord, PrevRecord, and QueryBiDirectional to traverse records of the primary business component. These operations traverse records only for a child business component.
For a detailed example that traverses a record set, see Defining a Workflow Process That Traverses a Record Set to Close Service Requests.
Stopping a Traverse a Record Set Operation
You set the NoMoreRecords output argument in the Siebel operation to TRUE. Siebel CRM uses this argument when the Siebel operation attempts to read the next record but finds that no more records exist in the record set to traverse. You set NoMoreRecords to TRUE:
In the forward direction for Next Record
In the backward direction for Previous Record
You can assign NoMoreRecords to a process property. You can use it in conjunction with a decision point to exit the loop after navigating through every record in the record set. To support this output argument, the Process Designer displays an Output Argument column in the Output Arguments tab of the Siebel operation step.
Counting the Number of Records Siebel CRM Gets or Updates
You can use the NumAffRows (Number of Affected Rows) output argument with the following operations:
Query. NumAffRows returns the number of rows that Siebel CRM gets as a result of the query.
Update or Upsert. NumAffRows returns the number of rows that Siebel CRM updated.
How Siebel Operations and Workflow Policy Programs Use Different Object Layers
The Siebel operation step uses a different object layer than a workflow policy program to update data. For example:
Assume a workflow policy calls a workflow policy program that updates a service request. This configuration proceeds through the data layer where the state model does not apply.
Assume a workflow policy calls a workflow process that includes a Siebel operation step that updates a service request. This configuration proceeds through the object layer, where the state model does apply.
When determining to user a Siebel operation or workflow policy program, you must consider how these operations interact with the various object layers.
Adding a Task Step
A task step is a type of workflow process step that starts a task UI from a workflow process. If a workflow process calls a task UI, then Siebel CRM does the following:
Adds this task UI to the user Inbox.
Sets the workflow process state to waiting until the user finishes this task UI.
When the task UI finishes, Siebel CRM resumes the workflow process at the next step that is immediately downstream of the task UI step.
To add a task step
Make sure the task UI that this workflow process must call is already defined.
For information about defining a task UI, see Siebel Business Process Framework: Task UI Guide.
In the Object Explorer, click Workflow Process.
In the Workflow Processes list, locate the workflow process you must modify, and then set the Workflow Mode property to Long Running Flow.
Right-click the workflow process you modified in the step above, and then click Edit Workflow Process.
Add a task step to the workflow process.
For more information, see Adding a Step to a Workflow Process.
Make sure the step you added above is still chosen in the Process Designer.
In the Properties window, In the Task Name property, choose the task UI that this workflow process must run.
After you define a task step in the Process Designer and set the Task Name property, you can double-click the task step to open the Task Editor.
Make sure the Inactive property is set to FALSE.
In the MVPW, add new input, output, and recipient arguments.
For more information, see Using Process Properties, and Siebel Business Process Framework: Task UI Guide.
Adding a User Interact Step
The user interact step is a type of workflow process step that allows you to control the flow of Siebel views that Siebel CRM displays in the client. It can guide the user through a flow of Siebel views according to user interactions or according to a defined set of actions. Siebel CRM can modify this flow as the business environment changes.
The user interact step can use a process property as an input argument. It can use this argument to dynamically set view names in an interactive workflow process.
To add a user interact step
Add a user interact step to a workflow process.
For more information, see Adding a Step to a Workflow Process.
Make sure the step you added above is still chosen in the Process Designer.
In the Properties window, set the User Interact View property.
At run-time, Siebel CRM displays the view you set in the User Interact View property in the client.
If the user interact step requires conditional logic, then define a decision condition.
You can define a decision condition on one or more connectors that emanate from the user interact step. For more information, see Configuring a Decision Condition.
If the workflow process is interactive, then make sure the branch that emanates from the user interact step is associated with a run-time event.
For more information, see Defining a Run-Time Event for a User Interact Step.
Behaviors of the User Interact Step
A user interact step does the following:
Sends a request to the Siebel Web Engine to create the view, and then display this view in the client. The Siebel Web Engine can create only one view at a time. You cannot combine a user interact step with another action, such as displaying a message box or simultaneously creating another view. You cannot simultaneously use a UserInteract step and start a task UI.
Waits in the user session memory for a run-time event to resume processing. If a run-time event is not defined, then the workflow process resumes.
If the user manually navigates out of the view that the user interact step displays, then the workflow process remains in the user session memory. Siebel CRM deletes this workflow process instance from memory when it terminates the user session or if it starts another workflow process in the same user session.
If not already in the run state, then the user interact step queries the primary business component of the business object that the workflow process references. This query searches for a record where the row ID matches the value that the Object Id property contains.
If the user interact step includes conditional logic, then Siebel CRM resumes the workflow process after the user interact step finishes. It resumes the workflow process only if the record ID of the run-time event that is registered in the decision condition matches the value that the Object Id process property contains.
Restrictions for Using a User Interact Step
The following restrictions apply if you define a user interact step:
A workflow process that runs in the Workflow Process Manager server component must not contain a user interact step. If the workflow runs in background mode or in batch mode, then it cannot include a user interact step.
Siebel CRM supports the user interact step only if a script or a run-time event starts the workflow process, and only if it runs this workflow process locally in the Application Object Manager.
You cannot use the user interact step to display or start the Search Center.
The user interact step or any activity that starts in the background must not interfere with the work that the user is performing.
Defining a Run-Time Event for a User Interact Step
A branch that emanates from a user interact step in an interactive workflow process must be associated with a run-time event. An error occurs during validation if each of the following statements are true:
The Workflow Mode property of the workflow process is set to Interactive Flow.
The workflow process contains a user interact step and a run-time event is not defined on the outgoing branch.
To avoid this error, if your configuration does not require the run-time event in the user interact step, then you can change the Workflow Mode property of the workflow process to 7.0 Flow. For more information, see Setting the Workflow Mode Property.
Configuring a User Interact Step to Set a View Name
You can associate the name of a view with a process property so that Siebel CRM can set this view name dynamically at run time.
To configure a user interact step to set a view name
Enter the following string in the User Interact View property of a user interact step:
[&ProcessPropertyName]
The Workflow Engine recognizes this string and assigns the view name at run time.
Adding a Wait Step
The wait step is a type of workflow process step that pauses a workflow process for a specific amount of time or until an event occurs. You can pause a workflow process instance for seconds, minutes, hours, or days.
If a workflow process includes a wait step, then it is persistent, by default.
You can use the wait step for testing and development. Unlike the Siebel operation step, you can use the wait step without affecting business component data. For an example, see Defining a Run-Time Event in a Many-to-One Relationship.
To add a wait step
Make sure the Workflow Mode property of the workflow process is set to Interactive Flow.
For more information, see Setting the Workflow Mode Property.
Add a wait step to a workflow process.
For more information, see Adding a Step to a Workflow Process.
Make sure the wait step is chosen in the Process Designer.
In the MVPW, define input arguments and output arguments for the wait step.
For more information, see Using Process Properties.
If you define a duration argument that is greater than 60 seconds, then you can use minutes or a larger unit of measure so that Siebel CRM refreshes business component data. If you use minutes or higher, then Siebel CRM resumes the workflow process from the Workflow Process Manager. If you use any duration other than seconds, then Siebel CRM considers the workflow process as persistent.
Resuming a 7.0 Workflow Process
If you set the Workflow Mode property of a workflow process to 7.0 Flow, then you can set the SleepMode input argument to one of the following values to determine how the wait step resumes the workflow process:
Local. Siebel CRM resumes the workflow process in the session that started this workflow process.
Remote. The Workflow Process Manager server component on the Siebel Server resumes the workflow process. Siebel CRM runs a component request for the Workflow Process Manager according to the time that the Duration input argument of the wait step specifies.
If you set the Workflow Mode property of a workflow process to something other than 7.0 Flow, then Siebel CRM ignores the SleepMode input argument. For more information, see Setting the Workflow Mode Property.
Setting the Processing Mode Property of a Wait Step
If you configure Siebel CRM to use SetFieldValue to start a workflow process, then it is recommended that you set the Processing Mode property to Local Synchronous. SetFieldValue can occur without committing data. Setting the Processing Mode to Remote Synchronous or Remote Asynchronous when using SetFieldValue might result in a workflow process that runs out of process, which means that Siebel CRM runs in a completely different thread and probably at a different time. In this situation, the workflow process cannot access data that Siebel CRM has not committed. It cannot access all the current runtime data. For more information, see Server Requests Business Service.
Adding a Stop Step
The stop step is a type of workflow process step that Siebel CRM uses to display an error message in the client, and then terminate a workflow process.
If Siebel CRM uses a stop step in a sub process, then this stop step stops the sub process and it also stops the parent workflow process. It is not necessary to define a stop step in the parent workflow to stop the sub process.
To add a stop step
Add a stop step to a workflow process.
For more information, see Adding a Step to a Workflow Process.
Make sure the step you added in the step above is still chosen in the Process Designer.
In the Properties window, In the Error Code property, choose an error code.
In the Error Message property, enter an error message.
In the MVPW, define input arguments for the step.
The input arguments for a stop step contain the substitution variables that Siebel CRM displays in the error message. A percent sign (%) identifies a substitution variable. To define the substitution value, you enter it in the Name field. For example:
%1
For more information, see Arguments That You Can Define for a Process Property.
If the predefined error messages that the Error Code property of the stop Step displays do not meet your requirements, then you can define a custom error message on the stop step.
For information, see Defining a Custom Error Message on a Stop Step.
How Siebel CRM Handles the Stop Step
The following table describes how Siebel CRM handles the stop step.
Table How Siebel CRM Handles a Stop Step
How Called | Where the Workflow Process Runs | Work That the Workflow Process Manager Performs |
---|---|---|
A workflow policy calls a workflow process that contains a stop step. |
Not applicable |
Exits and writes an error message to the log file. |
A script or a run-time event calls a workflow process that contains a stop step. |
Workflow Process Manager Object Manager |
Writes an error message to the log file. |
Application Object Manager |
Displays an error message in the client. |
Calling a Workflow Process That Includes a Stop Step
It is recommended that you use the stop step only in a workflow process that a script calls. For example, assume a workflow process includes a stop step that displays a custom error message. When Siebel CRM runs this workflow process, the custom error message includes stack information. Siebel CRM cannot suppress this stack information.
Assume a workflow process that a script starts contains an end step that defines the error message in a process property. Assume this workflow process encounters an error, and that the subsequent step is an end step that does not display messages. Siebel CRM returns control to the script. This script examines the value that the process property contains. It then uses the following function to display the message:
RaiseErrorText
The error dialog displays the error text but it does not include workflow process or stack trace information.
Defining a Custom Error Message on a Stop Step
This topic describes how to define a custom error message on a stop step.
To define a custom error message on a stop step
Add a stop step to your workflow process.
Click the stop step, and then use the Properties window to set the Error Code property to the following value:
WF_ERR_CUSTOM_1
Siebel Tools sets the Error Message property %1, by default.
In the MVPW, add a new input argument for the stop step.
For more information, see Arguments That You Can Define for a Process Property.
Set the Name field to the substitution variable that Siebel Tools displays in the Error Message property in the Properties window.
In this situation, this value is %1.
Enter the custom text message in the Value field.
At run time, Siebel CRM replaces the %1 substitution variable with the value that you enter in the Value field.
Defining Multiple Custom Error Messages for a Stop Step
You can use multiple customizable codes in the Error Code property of a stop step. These codes use the following format:
WF_ERR_CUSTOM_x
Each WF_ERR_CUSTOM_x code is unique. You can use each of these error codes only one time and for a specific purpose. If you must display multiple custom error messages, then you can use WF_ERR_CUSTOM_2, WF_ERR_CUSTOM_3, and so on, instead of using %1, %2 for the same WF_ERR_CUSTOM_x.
Adding an End Step
An end step is a type of workflow process step that specifies when a workflow process ends. It also provides one last chance to save output arguments to a process property. A workflow process must contain at least one end step.
To add an end step
Add an end step to a workflow process.
For more information, see Adding a Step to a Workflow Process.
Make sure the step you added above is still chosen in the Process Designer.
In the MVPW, define output arguments for the step.
For more information, see Using Process Properties.
Differences Between the End Step and the Stop Step
The stop step sets the state for the workflow process to In Error. The end step sets the state to Completed. It is important to consider this situation if you use the Workflow Monitor Agent to start a workflow process. If the Ignore Errors parameter of the Workflow Monitor Agent is set to False, and if a workflow process includes a:
Stop step. Workflow Monitor Agent exits with error.
End step. Workflow Monitor Agent does not exit with error.
Adding a Workflow Process Connector
To define the properties of connector in a workflow process, you can use the Properties window in the Process Designer. For information about connector properties, see the topic about the Connector object type in Siebel Object Types Reference. For information about defining a run-time event on a connector, see Starting a Workflow Process from a Run-Time Event.
Defining a Property for a Workflow Process Step
The properties of a workflow process step can include input and output arguments, search specifications, operations, and so on. To define some of these properties, you can use the WF Steps list or the Properties window and the Multi-Value Property Window in the Process Designer. You can define each step property for only one workflow process step at a time.
To define a property for a workflow process step
With the Process Designer open, click the step whose properties you must define.
Use the Properties window to define properties for the step.
If Siebel Tools does not display the Properties window, then right-click and choose View Properties Window. For more information, see Overview of Workflow Process Steps.
Use the MVPW to define input arguments, output arguments, and search specifications.
For more information, see Using the Multi Value Property Window.