Defining a Runtime Event in a One-to-Many Relationship
The example in this topic defines a runtime event in a one-to-many relationship. If you define a runtime event to start a Workflow Process in reply to a change that a user makes to a child record in a one-to-many relationship, 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:
-
Siebel CRM starts the Workflow Process if the user changes data in the form applet for the service request.
-
Siebel CRM does not start the Workflow Process if the user changes data in the activities list applet.
To define a runtime event in a one-to-many relationship
-
(Optional) For educational purposes, examine a one-to-many relationship:
-
In the Siebel client, navigate to the Service Request screen, then the Service Request List view.
-
Create a new service request.
-
Click the SR# field.
-
Use the Activities list to create two new activities.
-
In the Activities list view, the Service Request form shows fields for the parent service request and the Activities list shows multiple activities for the parent.
-
-
In the Workflow Processes list, create a new Workflow Process with the values shown in the following table.
Property
Value
Process Name
Update Service Request
Business Object
Service Request
Workflow Mode
Interactive Flow
This Workflow Process references the Service Request business object. The runtime 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.
-
Open the Workflow Process you created in step 2 and then add the following steps and connectors until your Workflow Process resembles the flow shown in the following figure:
-
A Start step
-
A Get Activity Id step
-
An End step
-
The following Connectors:
-
A Id Triggered connector between step (a) and (b).
-
A connector between step (b) and (c).
-
For more information, see Adding Workflow Process Steps and Diagramming a Workflow Process.
-
-
Click the Id Triggered connector and in the Properties pane, define values shown in the following table.
Property
Value
Event Object Type
BusComp
Event
WriteRecord
Event Object
Action
-
Click the canvas, making sure not to select any Workflow Process step or connector.
-
In the Multi Value Property Window (MVPW) pane, add a new process property with the values shown in 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.
-
Click the Get Activity Id step and go to the Output Arguments tab in the MVPW pane.
-
Create a New Record with the values shown in 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.
-
Validate and then simulate the Workflow Process.
For more information, see Process of Testing a Workflow Process.
-
Implement this configuration in your production Workspace.
This example demonstrates how you can start a Workflow Process according to changes that Siebel CRM makes to a child in a one-to-many 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 runtime event on the connector that emanates from step 4.