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

  1. (Optional) For educational purposes, examine a one-to-many relationship:

    1. In the Siebel client, navigate to the Service Request screen, 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 Service Request form shows fields for the parent service request and the Activities list shows multiple activities for the parent.

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

  3. 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:

    1. A Start step

    2. A Get Activity Id step

    3. An End step

    4. The following Connectors:

      • A Id Triggered connector between step (a) and (b).

      • A connector between step (b) and (c).

    Workflow defining process Designer: This image is described in the surrounding text.

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

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

  5. Click the canvas, making sure not to select any Workflow Process step or connector.

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

  7. Click the Get Activity Id step and go to the Output Arguments tab in the MVPW pane.

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

  9. Validate and then simulate the Workflow Process.

    For more information, see Process of Testing a Workflow Process.

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